You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@activemq.apache.org by Geurt Schimmel <GS...@schubergphilis.com> on 2012/12/03 11:42:18 UTC

destinationPolicy and producerFlowControl for large messages

Hi,

Using a destinationPolicy for dealing with large messages (23Mb):

         <policyEntry topic="LOCAL.ORATK.CFILE" producerFlowControl="true" memoryLimit="30mb">
                  <pendingQueuePolicy>
                    <vmQueueCursor/>
                  </pendingQueuePolicy>
          </policyEntry>

My broker hangs on flowcontrol as the topic has reached the 30Mb boundary - why ? Sending just 1 message of 23Mb by splitting it into chunks of 10kb and offering them to a Camel File component. At the other end of a network-of-brokers a Camel File component is writing the chunks to disk. The only way to release the flowcontrol is to bounce the affected brokers. Why ? There is enough diskspace at the consumer-end, don't understand why flowcontrol is never released.
The poor-man's solution by setting producerFlowControle=false and slowing down the number of chunks offered to the Camel-component works, but that is not a very scalable solution.
Any ideas ?

Thanks

Re: destinationPolicy and producerFlowControl for large messages

Posted by Gary Tully <ga...@gmail.com>.

two things would help understand:

1) a thread dump of the broker... to see where the send it waiting
2) some snippets from the broker log ... to see relevant usage limits that
are hit


On 3 December 2012 10:42, Geurt Schimmel <GS...@schubergphilis.com>wrote:

> Hi,
>
> Using a destinationPolicy for dealing with large messages (23Mb):
>
>          <policyEntry topic="LOCAL.ORATK.CFILE" producerFlowControl="true"
> memoryLimit="30mb">
>                   <pendingQueuePolicy>
>                     <vmQueueCursor/>
>                   </pendingQueuePolicy>
>           </policyEntry>
>
> My broker hangs on flowcontrol as the topic has reached the 30Mb boundary
> - why ? Sending just 1 message of 23Mb by splitting it into chunks of 10kb
> and offering them to a Camel File component. At the other end of a
> network-of-brokers a Camel File component is writing the chunks to disk.
> The only way to release the flowcontrol is to bounce the affected brokers.
> Why ? There is enough diskspace at the consumer-end, don't understand why
> flowcontrol is never released.
> The poor-man's solution by setting producerFlowControle=false and slowing
> down the number of chunks offered to the Camel-component works, but that is
> not a very scalable solution.
> Any ideas ?
>
> Thanks
>



-- 
http://redhat.com
http://blog.garytully.com