The same problem exists on 5.3 SNAPSHOT. Using the original configuration,
ActiveMQ printed out "WARN Usage - Memory usage is now at 100%". But
changing the configurations to
<policyEntry queue=">" memoryLimit="50mb"
optimizedDispatch="true"/>
<policyEntry topic=">" memoryLimit="50mb"
optimizedDispatch="true">
and
<systemUsage>
<memoryUsage>
<memoryUsage limit="256 mb"/>
do not help. The same problem occurs without the memory usage warning.
This seems another proof that it is not memory related.
Another theory is that this problem somehow related to latency. Using
bandwidth simulator Speed Limiter, I can reproduce the problem noticeably at
56kbps or slower, but it is producible using the real Internet DSL
connection @ 300kbps real speed. The simulator does not simulate latency,
while the real DSL connection has latency of about 50ms from ping.
What else I can try before I write our socket server to serve these topic
messages?
Thanks
>Does this behaviour change if you use the latest snapshot ?
>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-tp24563120p24772105.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
