activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Gies <ag...@progress.com>
Subject Re: ActiveMQ flow control and JMS
Date Fri, 03 Apr 2009 10:58:47 GMT
Hi,

sure thing:

typically these plugins implement org.apache.activemq.broker.Broker.  
There is a class BrokerPluginSupport that can serve as the base class
for your own plugins. If you are using Eclipse I would suggest to look  
at the class hierarchy of those classes and have a look at some of the
other Broker plugins inheriting from BrokerPluginSupport.

If you are interested to do something about a slow consumer you would  
hook into the method

     void slowConsumer(ConnectionContext context,Destination  
destination, Subscription subs);

As you see, you can grab the ConnectionContext from there and for  
example close the connection to
a slow consumer if that makes sense.

Hope that helps
Andreas

On Apr 3, 2009, at 10:15 AM, ffrenchm wrote:

>
> Hello,
>
>
> 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 ?
>
> Thanks
>
>
>
> -- 
> View this message in context: http://www.nabble.com/ActiveMQ-flow-control-and-JMS-tp22843016p22863980.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

---
Mit freundlichen Grüssen - Kind Regards
Andreas Gies
Principal Consultant
Open Source Center of Competence

Progress Software GmbH
Agrippinawerft 26
50678 Köln

E-Mail      	agies@progress.com
Direct Line 	+49 (0)9953 980349
Mobile      	+49 (0)170 5759611
Skype        	+44 (0)20 3239 2922
Skype       	+353 (0)1 443 4971
Skype       	+1 (0)781 262 0168

http://www.progress.com
http://fusesource.com
http://open-source-adventures.blogspot.com




-------------------------------------------------------
Progress Software GmbH
Sitz der Gesellschaft: Agrippinawerft 26, 50678 Koeln;
Niederlassung: Fuerstenrieder Str. 279, 81377 Muenchen
Amtsgericht Koeln, HRB 15620; 
Geschaeftsfuehrung: David Ireland
-------------------------------------------------------
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message