Gordon, Gordon Sim wrote > > As a workaround, can you first assign a 'null' Subscription to the > subscription variable and only then recreate the Session and > SubscriptionManager, then finally reassign the variable with the real > Subscription? > > For an actual fix, perhaps a destructor in SubscriptionManagerImpl that > calls cancelDiversion() on all its Subscription instances would > suffice(?). > Good call! I had to also assign a "null" to the associated LocalQueue object, but after doing so, it worked swimmingly. Thanks!
Gordon Sim wrote > >> I was wondering if you were aware of this sort of issue, and if so, if >> there were plans to resolve it or ideas on how to resolve it. > > I wasn't aware of this specific issue. We've been encouraging people to > use the newer messaging API instead of this older client API. The > messaging API offers a cleaner, higher level abstraction that makes > migration to newer versions of the protocol simpler and also makes it > simpler to provide richer functionality behind the API (such as > auto-reconnect). > That's a good point - we had experimented with the newer API and, indeed, we didn't observe this or any similar problem. Unfortunately, we weren't able (read as: allowed) to convert our existing codebase to the new API... Thanks again - this has been a thorn in our collective side for a while! -rob -- View this message in context: http://qpid.2158936.n2.nabble.com/Broker-death-recovery-tp7148014p7151005.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
