Hi all,

On our server (ActiveMQ 5.8.0) I have the problem, that the producer to a
temp queue gets frequently blocked (see below). The server is quite busy,
handling >50'000'000 messages a day. But the temp queue is the response
queue to a user-request queue that sees only a couple hundred requests per
day. That particular producer is the only one that ever gets blocked
(according to the log).

I have disabled flow-control for both queues and topics, but have the
feeling that it does not apply to temporary response queues. If that is so,
how can I disable flow control for temp queues as well or otherwise ensure
that my client-request-queues are always available to their
producers/consumers?

I am connecting to ActiveMQ through the client component in Camel 2.10.3.

Log output:

2013-04-25 18:45:07,759 | INFO  |
Usage(default:memory:temp-queue://ID:dpr-app1-50587-1366890873600-1:1:1:memory)
percentUsage=0%, usage=0, limit=3221225472,
percentUsageMinDelta=1%;Parent:Usage(default:memory) percentUsage=142%,
usage=4595091839, limit=3221225472, percentUsageMinDelta=1%: Usage Manager
Memory Limit reached. Producer (ID:dpr-app1-34414-1366878868519-1:4:2:82)
stopped to prevent flooding
temp-queue://ID:dpr-app1-50587-1366890873600-1:1:1. See
http://activemq.apache.org/producer-flow-control.html for more info
(blocking for: 244s) | org.apache.activemq.broker.region.Queue | ActiveMQ
NIO Worker 23017


activemq.xml:

<destinationPolicy>
  <policyMap>
    <policyEntries>
      <policyEntry topic=">" producerFlowControl="false">
        <pendingSubscriberPolicy>
          <fileCursor />
        </pendingSubscriberPolicy>
      </policyEntry>
      <policyEntry queue=">" producerFlowControl="false">
        <pendingQueuePolicy>
          <fileQueueCursor/>
        </pendingQueuePolicy>
      </policyEntry>
    </policyEntries>
  </policyMap>
</destinationPolicy>


Thanks!
Ralf



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Producer-to-temp-queue-gets-blocked-tp4666234.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to