Bug 625541
| Summary: | C++ New API: Connection::close() hangs on suspended broker | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Ted Ross <tross> | ||||||
| Component: | qpid-cpp | Assignee: | Gordon Sim <gsim> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | MRG Quality Engineering <mrgqe-bugs> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | Development | CC: | gsim, jross | ||||||
| Target Milestone: | 1.3 | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-12-11 19:09:29 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: |
|
||||||||
|
Description
Ted Ross
2010-08-19 18:58:47 UTC
Impact: This is likely to be a problem in deployments where the broker is running on a virtualized guest. If the guest is force-stopped or suspended, client applications that clean up connections on exit will not be able to exit. Not a bug in my view; enable heartbeats which are there to allow this sort of condition to be detected. I guess we could also support a form of close that was not clean; i.e. abort or detach without attempting to do a clean handshake with the broker. That would not be a 1.3 change however. Further to my comment above, note that that would be only a limited solution. If the application also e.g. cancelled a subscription as part of shutdown then that too would hang. Heartbeats are intended to solve exactly this problem, so that is really my recommendation. More info... This can be solved by turning on heartbeats, turning on reconnect, and setting a reconnect-limit. The blockage will clear after the reconnect limit is reached (typically a long time). There is still a problem if a) reconnect is not desired, or b) reconnect-limit is not desired or is very long. In these cases, there is no clean way to shut down an application/daemon connected to a stopped/suspended broker. A related effect: If reconnect is in use and the broker is shut down (cleanly, no need to suspend), the client application/daemon cannot close the session/connection without waiting for the reconnect-limit (if present) to expire. Turning on reconnect is not required; that is orthogonal to the problem. However my initial assessment was incorrect. Heartbeats *don't* solve this problem. The heartbeat timer is turned off just before the close attempt. Created attachment 439888 [details]
testcase
Created attachment 439895 [details]
Suggested fix
The attached patch fixes the issue by waiting only for the length of the heartbeat interval (if specified) for the broker to respond to the close request.
|