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.
