Bug 495655
| Summary: | cluster does not free up sessions on failover | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Gordon Sim <gsim> | ||||
| Component: | qpid-cpp | Assignee: | messaging-bugs <messaging-bugs> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | MRG Quality Engineering <mrgqe-bugs> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | urgent | ||||||
| Version: | Development | CC: | aconway, jross | ||||
| Target Milestone: | 1.1.1 | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-06-29 14:16:27 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
This was a regression. Fixed in r764783 Does this have test coverage? No automated tests were added by r764783. I'll add one now. Comment 3 is incorrect, there IS an automated regression test added by r764783: qpid/cpp/src/tests/ClusterFailover.cpp Excellent, thanks! Closing. |
Created attachment 339448 [details] test case Description of problem: If you use a session with an application specified name, then on failover to another cluster node try to open a new session with the same name, you get a SessionBusyException. Even retrying after a short wait seems not to avoid this. How reproducible: 100% Steps to Reproduce: 1. start cluster with more than one node 2. have client that creates a session with a given name (and 0 timeout, which is default) and e.g. waits for a message 3. kill the node the client is connected to 4. have client failover to other node and create a new session with the same name as that used previously (which should have been destroyed) The attached case provides such a client. You should be able to run that against a cluster (with a queue called test-queue created), then kill the node connected to. Actual results: Get a SessionBusyException as often as you try. Expected results: New session created with same name as that used previously, which should now have been destroyed. Additional info: If the session declares an exclusive (but not auto-deleted) queue, then it appears that lock on that queue is released as would be expected. However the name of the session is still marked as busy.