answers inline: On 28 June 2012 06:40, Marcin Giedz <[email protected]> wrote: > > Hi, > > > I was wondering why with temp-queue and producer flow control set to ON + > temp storage we still experience producers stop preventing flooding. Is this > a bug or a feature? > That is a feature. the cursor gets to consume all of the destination limit and then the destination is considered full. The filepending message cursor will only spool to disk with the systemUsage limit is reached, up until that point it will keep messages in memory like the vmpendingMessage cursor.
> > > <broker xmlns="http://activemq.apache.org/schema/core" brokerName="waw1-amq1" > dataDirectory="${activemq.base}/waw-data" useJmx="true" > advisorySupport="true" persistent="true" > schedulePeriodForDestinationPurge="10000" networkConnectorStartAsync="true" > allowTempAutoCreationOnSend="true"> > > > > > > <policyEntry tempQueue="true" producerFlowControl="true" memoryLimit="100mb" > gcInactiveDestinations="true" inactiveTimoutBeforeGC="60000"> > <pendingQueuePolicy> > <fileQueueCursor/> > </pendingQueuePolicy> > </policyEntry> > > > .... > > > > <systemUsage> > <systemUsage> > <memoryUsage> > <memoryUsage limit="24 gb"/> > </memoryUsage> > <storeUsage> > <storeUsage limit="10 gb" name="store"/> > </storeUsage> > <tempUsage> > <tempUsage limit="10 gb"/> > </tempUsage> > </systemUsage> > </systemUsage> > > > If I disable PFC on temp-queue I can see storage utilization once memory is > exhousted but there is no any control over temp-queue. This behavour is > common for 5.5.1 and 5.6.0. Should I file a bug or change my configuration? > With the destination limit removed, the system limit gets a chance to be reached and the file cursor purges to temp storage. It is possible to limit the temp store, and then the destination will block on a send. If key here is to understand that the spooling to disk with the file pending message cursor is controlled by the shared systemUsage and not the destination usage. What behavior would you like to have? > > Thank you > Marcin -- http://fusesource.com http://blog.garytully.com
