You should not create the session and temporary queue for every request. You should create them when you create the client [1] (or at least cache them). These operations are expensive and require remote calls to the broker.
The slowdown of faster clients may be due to Producer Flow Control [2], which is enabled by default. -Andres [1] http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html [2] http://activemq.apache.org/producer-flow-control.html mquestioner wrote: > > Thanks. Will try. > > More detail about the client is that when we send a queue request, we do > > - create a Session > - create a TemporaryQueue > > I wonder if these two will be broadcasting something to the other clients > and cause the backlog. Shouldn't be, but... > > > > rajdavies wrote: >> >> Does this behaviour change if you use the latest snapshot ? >> >> thanks, >> >> Rob >> On 20 Jul 2009, at 03:51, mquestioner wrote: >> >>> >>> Hi, >>> >>> We have a case where a consumer connected through a slow connection >>> would >>> slow down the fast consumer. I have already >>> http://activemq.apache.org/slow-consumers.html and >>> http://activemq.apache.org/slow-consumer-handling.html However, >>> there are >>> specific advises do not seem applicable to our scenario. >>> >>> Out set up looks like: >>> The server >>> Constantly broadcasting non-persistent messages over a topic (a) >>> Listen on a number of persistent and non-persistent queues to >>> process >>> messages asynchronously (Listener) (b) >>> Reply to the temporary queue of the request (c) >>> >>> The client >>> Listen to the broadcast messages in background (d) >>> Make request to the queues (e) >>> Wait for reply (f) >>> >>> When the clients are on fast connection, everything is fine. >>> However, once a >>> slow connecting client joins, we observe: >>> >>> 1) (e) and (f) of the fast client become extremely sluggish instantly. >>> >>> 2) Timestamp logging of (b) and (c) shows that the server still >>> takes very >>> little time to process each request, ruling out problems such as DB >>> bottleneck. On the other hand, the messaging waiting time (time at >>> the entry >>> of the listner - msg.getJMStimestamp()) increases by 50-100X >>> >>> 3) Either killing the slow connecting client or stop broadcasting >>> message >>> will have things return to normal >>> >>> The strange thing is that, according to >>> http://activemq.apache.org/slow-consumers.html, ``A slow consumer is >>> not >>> really an issue with queues.'' And that the problem occurs almost >>> instantly >>> after the slow connection is established, it seems too short for any >>> memory >>> usage built-up; and indeed no such problem is observed. We also try >>> twisting >>> ActiveMQ broker and consumer settings like prefetchsize=2000, >>> dedicated task >>> runner = true/false, increase memoryLimit/memoryUsage, >>> optimizedDispatch=true. None seems to solve the problem. >>> >>> What would be the causes and solutions for these scenario? >>> >>> (The ActiveMQ site's suggestions of discarding old messages would >>> create >>> stale data problems for our application.) >>> >>> Thanks a lot! >>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Slow-consumers-slow-down-fast-consumer-queue-requests-tp24563120p24563120.html >>> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >>> >> >> >> > > -- View this message in context: http://www.nabble.com/Slow-consumers-slow-down-fast-consumer-queue-requests-tp24563120p24811943.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
