activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Luna <>
Subject Re: Durable subscription with subscription recovery policy
Date Wed, 06 May 2009 19:11:28 GMT
----- Original Message ----

> From: Jose Luna <>
> To:
> Sent: Thursday, April 30, 2009 3:04:33 PM
> Subject: Durable subscription with subscription recovery policy
> Hello,
> I haven't received a response after a few days, so I'd like to try again. I'll 
> try to be brief this time:
> Our consumers disconnect/reconnect frequently.  We need durable subscriptions to 
> work with the subscription recovery policy.  Currently (Activemq 5.2), durable 
> subscriptions with the "activemq.retroactive" header (STOMP) will receive all 
> retroactive messages every time the durable subscriber reconnects.
> A bug report can be found at 
> .  The bug is open and assigned, with fixed
> version marked as 5.3 (although no work has been done yet).
> However, in this thread 
>,  Bruce and James 
> seems to say that subscription recovery policy is
> only for non-durable subscriptions.  
> So, are durable subscriptions meant to work with subscription recovery 
> policies?  It used to work this way in 4.x, but I'm not sure if it was an 
> intentional change for 5.x.
> I'm looking for two kinds of advice: 
> 1.) How we might patch this ourselves.  We're a small development team on a 
> tight deadline, but we might be able to take a crack at it.
> 2.) Any advice on how to otherwise circumvent this problem.  The obvious 
> solution is to use the retroactive header only on the very first connection, but 
> how can we know when the last retroactive message is received?
> I hope reposting is ok, I couldn't find any mailing list rules.  Here's the more 
> verbose version that I originally wrote:
> Thanks for your time,
> JLuna

Just in case anyone has a similar problem finds this post, we ended up modifying ActiveMQ
to send an advisory message after all past messages have been recovered for the subscription.
 (The Advisory message goes only to the consumer, not to the topic for all consumers to see.)
 This allows the consumer to know that it has received all past messages and shouldn't use
the retroactive header in future.  This is undoubtedly somewhat "hackish" way to do it, but
it's the quickest thing we could come up with given a short deadline.  The diff is attached.


View raw message