qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rspringer <rsprin...@etinternational.com>
Subject Re: Broker death recovery
Date Wed, 04 Jan 2012 16:18:20 GMT
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:users-subscribe@qpid.apache.org


Mime
View raw message