[
https://issues.apache.org/jira/browse/QPID-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved QPID-3757.
------------------------------
Resolution: Fixed
Fix Version/s: 0.17
> Difficult recovery on broker death
> ----------------------------------
>
> Key: QPID-3757
> URL: https://issues.apache.org/jira/browse/QPID-3757
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.12
> Environment: RHEL 4.7 and RHEL 6.2
> Reporter: Rob Springer
> Assignee: Gordon Sim
> Priority: Minor
> Fix For: 0.17
>
> Attachments: backtrace, restart_example.cpp
>
>
> When using the old API (which might render this bug as invalid, if the old
> API is completely deprecated), if the broker dies, it's not possible to
> recover Subscription and LocalQueue variables unless you follow a precise
> workaround procedure.
> The problem is:
> If the broker dies and is then respawned, if one attempts to reconnect to
> the new broker and doesn't create a new Session (i.e., use the old one), bad
> things happen (since Session doesn't yet support resume(), I assume that's
> expected behavior).
> If, however, one tries to create new Session, new SubscriptionManager, and
> new Subscription objects, an assertion failure is generated (backtrace
> attached).
> After reading the backtrace, I believe the following is happening:
> 1) In recovery, we attempt to assign a new Subscription to the previous
> Subscription variable (i.e., "sub = subMgr->subscribe()")
> 2) That causes the refcount for the old Subscription to fall to 0, causing it
> to be cleaned up.
> 3) As part of that cleanup, the associated SubscriptionImpl object goes to
> destroy its (std::auto_ptr<ScopedDivert>) demuxRule member.
> 4) That demuxRule member maintains a reference to a Demux object, demuxer,
> which exists inside the Session object. Since the Session object has been
> re-created, that old reference is invalid & results in the assertion.
> Thus, we have a fatal circle - we need to create a new Session object to be
> able to proceed, but when we do so, we render ourselves unable to re-use
> Subscription variables.
> Gordon proposed a workaround which does solve the problem for me, in
> practice, and that is to assign "null" Subscription and LocalQueue objects to
> those variables before re-creating the Session object. Unfortunately, this
> won't be clear to any new users, so if anyone is still using the old API,
> they might be likely to encounter it.
> I'll attach an example showing the problem and the fix as well as snippets
> from my backtrace shortly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
