Hi Gary,
thanks again.
Yes some of the queues grow larger than previously in terms of pending
messages just before the tmp store is created.
So we need to increase our memoryUsage under the systemUsage element of the
broker configuration? Currently it will just be using the defaults.
I was not
thinking a bit more, the simplest explanation is that you are reaching
your memory usage limits and pending messages are no longer cached in
memory. As a result, dispatch now needs to read from the store which
will be slower.
Do you notice an increase in queue depth before the slowdown?
post your
Hi,
no there are no slow advisory messages in the logs. We used to receive
these when using the topic and it would block our producers that added to
the topic, but we have not seen this since we changed to a virtual topic.
I'll try and arrange to capture some stack traces, the help is appreciate
There is something not right then b/c when the temp store is created
at runtime it is typically the result of flushing non persistent
pending messages to disk for a slow consumer. But from your
description, all consumers should be queue consumers and all messages
persistent.
Are there any slow advi
Hi Gary,
thanks for the info:
AMQ journalling is disabled due to master/slave requirement.
8 queues, 1 topic with a virtual topic set up so we can have multiple
consumers consuming from the topic at once. There are multiple consumers on
every queue.
All messages on all queues are persistent an
The file pending message cursor is a little slow in 5.5, we are
working on improving that. That may be the problem here, but please
provide some detail of your usage, topic/queue
persistent/nonpersistent message mix and your activemq.xml to clarify.
If you swap your use of the filebased cursor for
