activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SuoNayi <suonayi2...@163.com>
Subject Reply:Re: Subscriber losing messages (from topic)
Date Fri, 11 Jan 2013 01:40:38 GMT
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
http://activemq.apache.org/slow-consumer-handling.html
In this case the behavior you observed is expected.





At 2013-01-11 04:59:52,"Timothy Bish" <tabish121@gmail.com> 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 ConsumerTool.java'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.
>tim.bish@redhat.com | www.fusesource.com | www.redhat.com 
>skype: tabish121 | twitter: @tabish121
>blog: http://timbish.blogspot.com/
>

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