On Fri, 29 Nov 2019 at 16:21, Gordon Sim <g...@redhat.com> wrote: > > On 29/11/2019 3:42 pm, VERMEULEN Olivier wrote: > > Hello, > > > > First let me explain the setup. > > We have 1 Broker-J (version 7.1.3) with 1 queue. > > We have 1 Dispatch-Router (version 1.9.0) with 1 waypoint address and 1 out > > auto-link. > > > > The queue contains 10 messages. > > When I create a JMS consumer (with jms.prefetchPolicy.all=1), consume 1 > > message and close the consumer I see the "outbound messages" statistic of > > the Broker-J increasing way more than I would expect, around +30 messages... > > Is this expected ? > > I'm not sure what exactly the 'outbound messages' statistic tracks, but > it is certainly expected that there will be more than 1 transfer between > broker and router, more even than the 10 messages on the queue. > > Credit is not directly propagated from consumer link to the broker link. > The broker will be granted credit based on the prefetch setting on the > connector (250 by default). The router will deliver the first message to > the consumer that gave it one credit. When the consumer closes, all > other messages for the address will be released and drain request will > be issued to any sender links (i.e. the broker). However the broker will > still have credit so it when the messages are released it will > immediately send them back (and they will then be released again). > > In the trace you included it seems there are 19 transfers from broker to > router (the last 9 get resent once before the credit is drained). >
I see 28 transfers from broker to router. 10 initially, 1 of which is actually accepted by the consumer, and then a couple sets of 9 after the consumer detaches. One set presumably happened as result of the router first releasing the 9 remaining messages, and arrive before the draining flow is sent from the router to the broker. The second set arrive after the draining flow is sent, along with releasing the messages a second time. Its possible the second set were partly send in response to to the drain. An improvement would seem to be for the router to drain the link and await that completing before it releases anything, so that those messages cant be resent at all, nevermind twice as seen here. Robbie --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
