I can also reproduce this. I believe it is a deficiency in how/when the client handles granting more link credit, and it will show particularly badly in the scenario described where the broker is able to significantly/totally use the existing credit between processing of individual messages and there is a backlog of queued messages to continuously feed the scenario.
To work around the issue and achieve the effect you are looking for, of balancing the backlog between multiple consumers when some come up later than others, you will need to reduce the prefetch setting to 0 or 1. Robbie On 5 May 2017 at 10:07, Keith W <keith.w...@gmail.com> wrote: > Hi Dan > > Thanks for the comprehensive report. I can reproduce what you see and > confirm there appears to be a bug. I'll hope to be able to take a > closer look later today or Monday and get back to you with more > information. > > Keith. > > On 4 May 2017 at 23:39, Dan Langford <danlangf...@gmail.com> wrote: >> So over the past few weeks we have had a huge influx of messages on our >> enterprise message bus (qpid java 6.0.4 serves the AMQP1.0 messaging >> portion) and when one of our clients struggled scaling their application up >> it got us looking at prefetch. we thought it was odd that all 500k messages >> in the queue were prefetched and it was due to the prefetch that when they >> scaled out the new connections could help with those messages they could >> only acquire new messages. >> >> so i started running tests on a local instance of qpid java 6.1.2 and i was >> able to duplicate the behavior which seems odd. >> >> Setup. >> my java code will use the JMS api to create a consumer, receiveNoWait a >> message, acknowledge or commit the message, then Thread.sleep for a bit to >> look at the Qpid Java Brokers web interface for stats around prefetched >> messages. >> >> Test 1. qpid-jms-client 0.22.0 with prefetch of 10 set via jms url >> parameter (jms.prefetchPolicy.all=10) OR set via PreFetchPolicy on the >> ConnectionFactory (jmsDefaultPrefetchPolicy.setAll(10);) >> After the first message came in the web interface showed the queue size >> decrement and 19 messages pre-fetched >> after second message queue size decremented again and 28 messages are >> pre-fetched >> after third message queue size also decremented and 37 messages prefetched >> so on and so forth >> >> Test 2. qpid-client 6.1.2 with prefetch of 10 set via url param >> maxprefetch='10' >> After the first message came in the web interface showed the queue size >> decrement and 10 messages pre-fetched >> after second message queue size decremented again and still 10 messages are >> pre-fetched >> after third message queue size also decremented and still 10 messages >> prefetched >> so on and so forth >> >> could it be a link credit thing? could i not be understanding prefetch? >> maybe jms.prefetchPolicy is not the same as maxprefetch? >> >> Frame logs are here >> https://pastebin.com/4NHGCWEa > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
