On 27 April 2015 at 17:32, Tim Bain <tb...@alumni.duke.edu> wrote: > On Mon, Apr 27, 2015 at 7:30 AM, James Green <james.mk.gr...@gmail.com> > wrote: > > > > > Surely if a client takes more than the receive time-out to process a > > message, a re-delivery will occur? If not, what does happen? > > > I don't believe the receive timeout relates to processing a message at > all. The receive timeout is the amount of time you'll wait to see if a > message is available to be processed before returning control; it ends when > message processing begins, whereas your description indicates you're > expecting that it starts when message processing begins. > > When a client takes more than the receive timeout to process a message, the > client will continue processing the message, and continue processing the > message, and continue processing the message, until eventually it > finishes. The only way I know of to time out a client is by using the > AbortSlowAckConsumerStrategy (and even then, I'm not sure the consumer will > actually stop processing the current message, it just won't get to process > any more after the current one), but that's a completely different path > (and entirely optional, and not enabled by default). By default, message > processing just takes as long as it takes, which is why we have strategies > available to react to slow consumers. >
So to re-work my understanding, the pre-fetch buffer in the connected client is filled with messages and the broker's queue counters react as if this was not the case (else we'd see 1,000 drop from the pending queue extremely quickly, and slowly get dequeued which we do not see). The client (we're using standard Camel JMS consumer routing) has this buffer and the session polls this buffer for the next message, sending it to the receive() method of the consumer (which is a Spring object by the looks of things). This polling is subject to a receiveTimeout time-out. All accurate or almost so far? What I'm not "getting" is why we we no longer getting the DLQ entries, having only increased the receiveTimeout. It is as if the client process is so busy the pre-fetch buffer cannot react fast enough. James
