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 <suonayi2...@163.com> 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 >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" <tabish...@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.b...@redhat.com | www.fusesource.com | www.redhat.com >>skype: tabish121 | twitter: @tabish121 >>blog: http://timbish.blogspot.com/ >>
