activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcin Giedz <marcin.gi...@arise.pl>
Subject Re: PFC + temp-queue
Date Wed, 04 Jul 2012 14:17:20 GMT
HI Gary, 


My understanding was that if I reach memory limit on temp-queue it will go the same way as
for regular queue or topic. At the moment we have PFC on for temp-queue and sometimes when
Clients disconnects without clean exit its temp-queues stay alive with ConsumerCount=0, ProducerCount=0
and EnqueueMessage counting up. Once memeory limit is reached on such temp-queue PFC starts
and producer is stopped. I can live temporary with such zombie temp-queues to the nightly
AMQ restart/clean but I can't efford on producer being stopped. 


SHould I disable PFC on temp-queues? Zombie temp-queues is the subject I've already discussed
on AMQ bug tracker since early 5.3 but with 5.6 it's still exists. 


Thx 
Marcin 




----- Oryginalna wiadomość -----

Od: "Gary Tully" <gary.tully@gmail.com> 
Do: users@activemq.apache.org 
Wysłane: czwartek, 28 czerwiec 2012 17:07:12 
Temat: Re: PFC + temp-queue 

answers inline: 

On 28 June 2012 06:40, Marcin Giedz <marcin.giedz@arise.pl> 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 



-- 

Pozdrawiam 
Marcin Giedz 
Wiceprezes Zarządu 

ARISE Sp. z o.o. 
mob. +48 502 537 157 
mail: marcin.giedz@arise.pl 

Al. Solidarności 117 
00-140 Warszawa 
tel. +48 (22) 440 56 20 
fax +48 (22) 440 56 22 
http://www.arise.pl 

ARISE Sp. z o.o. z siedzibą w Warszawie, Al. Solidarności 117, 00-140 Warszawa, zarejestrowana
przez Sąd Rejonowy dla m. st. Warszawy w Warszawie XII Wydział Gospodarczy Krajowego Rejestru
Sądowego pod nr KRS 0000316860; REGON 141595449; NIP 527-259-06-10; z pokrytym w całości
kapitałem zakładowym wynoszącym 250,000.00 zł. 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message