activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SuoNayi <>
Subject Reply:Reply:Re: Subscriber losing messages (from topic)
Date Fri, 11 Jan 2013 02:03:14 GMT
Sorry for my inaccurate post.
The behavior that the broker discards messages for the slow non-durable subscription 
depends on the maximum pending messages of the subscription.
There is a pending message limit strategy for the subscription called PendingMessageLimitStrategy.
You may post your broker configuration file for more details.

At 2013-01-11 09:40:38,SuoNayi <> wrote:
>Hi, I assume you're using non-durable subscription.
>If so the eviction strategy will be involved when the memory consumption of the 
>broker exceeds the memory limit.In your case the producer is faster than the consumer.
>This cause more and more messages are pending in memory in the broker
>and eventually the broker has to use the eviction strategy to discard messages
>for the slow non-durable subscription.The default strategy is oldestMessageEvictionStrategy

>that will discard the oldest message in memory.You may take a look at
>In this case the behavior you observed is expected.
>At 2013-01-11 04:59:52,"Timothy Bish" <> wrote:
>>On Thu, 2013-01-10 at 21:52 +0100, Karel Gardas wrote: 
>>> Hello,
>>> I'm playing a bit with ActiveMQ 5.7.0 and found that under some
>>> circumstances my subscriber looks like losing messages which are
>>> delivered to him from the broker. Honestly speaking I don't know if to
>>> blame subscriber or broker in this case but while looking into web
>>> console of the broker, the broker claims the messages are delivered, but
>>> I don't see them on subscriber. It took me some time to duplicate this
>>> issue on as simple as possible example, but finally I've been able to a
>>> bit hack activemq's own demo to duplicate it.
>>> If you'd like to see the same effect as I see now, just go to
>>> activemq/example/src and add:
>>You should try to create a unit test to represent what's going on so
>>that we can take closer look.  Seems odd that the sleep would cause
>>something to get lost unless there's a TTL set on the messages. 
>>> try {
>>> Thread.sleep(1);
>>> }
>>> catch (Exception ex) {
>>> ex.printStackTrace();
>>> }
>>> into's onMessage method. This will ensure that
>>> onMessage on consumer will run a little bit slower than producer is able
>>> to send messages and you will see the effect.
>>> Once done, just run consumer with:
>>> ant consumer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>>> and producer with:
>>> ant producer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>>> if everything is working well, then both consumer and producer should
>>> end once delivering 1000000 messages. The problem is that consumer does
>>> not end due to losing some of the messages somewhere. If this does not
>>> happen on your box, please increase number of milliseconds on
>>> Thread.sleep to make onMessage even slower. I'm running this on Solaris
>>> 11/JDK 1.7 on Xeon E5 2.0 GHz here.
>>> Now, I do have following questions:
>>> - am I right assuming the example above should really deliver all the
>>> messages to the consumer onMessage method?
>>> - is this already known issue or shall I report it properly to
>>> ActiveMQ's bug tracking system?
>>> Just to make sure, I've also tried running consumer with ant consumer
>>> -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>>> -Durl="tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=0" -- but
>>> it neither helps. At least I've thought pre-fetching might cause this so
>>> I tried...
>>> BTW: I've seen the same issue but not on demo, but on our own
>>> application also while running subscriber on top of 5.6.0 and 5.5.0
>>> releases. I always used 5.7.0 release for broker and producer though.
>>> I've not seen it on demo as I've not tested this with older releases but
>>> I would guess the issue will be there too.
>>> Thanks a lot for any idea about what's going wrong here.
>>> Karel
>>> PS: resending as my former subscription to the list looks like stuck in 
>>> the middle of the way. Sorry if it went through already.
>>Tim Bish
>>Sr Software Engineer | RedHat Inc.
>> | | 
>>skype: tabish121 | twitter: @tabish121

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message