activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ffrenchm <>
Subject Re: ActiveMQ flow control and JMS
Date Fri, 03 Apr 2009 08:15:28 GMT


Andreas Gies-3 wrote:
> Hi there,
> as for the first question. AFAIK the methods you mention just send  
> advisory messages
> that you could monitor for the moment. I could imagine you could use  
> the method hooks for implementing
> a broker plugin that automatically disconnects slow consumers for  
> example.

uhm, could you tell me more on how I could implement this kind of broker
plugin ? I'm new on ActiveMQ and I'm not sure I can implement a proper
plugin without your good advices :) 

In my JMS client point of view in the case some of these monitoring messages
is raised, I would be happy to catch some exception from the Connection or
the Session depending about what limit is reached... What do you think about

Andreas Gies-3 wrote:
> As for the second question, I am not sure what kind of behavior you  
> desire. If you use memory limits
> and use transacted sessions, the memory kind of must match the biggest  
> transactions you want to
> perform. As the commit is outstanding the messages are not visible to  
> the client and therefore no consumer gets them.
> Are you suggesting to abort the transaction when the memory buffer is  
> full and no commit is issued ?

There is some solutions examples on this kind of problem on the QPID project
I think. In QPID the limits are defined for each destination and there is a
limit-policy parameter in the case the limits are reached to solve this kind
of problem before raising memory limit. In QPID the limit-policy are defined
like this :

    --limit-policy [none | reject | flow-to-disk | ring | ring-strict]
                         Action taken when queue limit is reached:
                             none (default) - Use broker's default policy
                             reject         - Reject enqueued messages
                             flow-to-disk   - Page messages to disk
                             ring           - Replace oldest unacquired
message with new
                             ring-strict    - Replace oldest message, reject
if oldest is acquired

I think for example if I was able to set a kind of flow-to-disk policy
without committing ( so the messages are on the disk, the memory is freed
and the receiver do not see the message even if it's on the disk ) could
solve this kind of deadlock problem...

About queue limits I think that QPID is a pretty good example to follow for
ActiveMQ. I mean another problem I have is that the queue limits are a
global broker parameters and I would prefer that we can be able to set these
parameters depending on the queue... You see what I mean ?


View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message