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 ag...@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
-------------------------------------------------------
