SonicMQ also does some interesting stuff with flow to store for messages until flow control is no longer in effect, which is nice:
http://www.psdn.com/library/servlet/KbServlet/download/2679-102-5202/mq_application_program.pdf Pg 221. Worth thought I reckon. Bfn, Marnie On 6/27/08, Marnie McCormack <[EMAIL PROTECTED]> wrote: > > Hi, > > Having thought about it a little, I think the limiting would really need to > be able to be configured on queue size if possible as this is the most > useful limit that client applications could set, particularly for users of > transient messaging who would wish to avoid OoM. > > The ability to set it on message number is useful too for applications that > have business related thresholds i.e. to avoid flooding downstream order > processing systems etc. I bet the message number check is cheaper :-) > > I'm coming around to the view that we need to do this work very carefully, > and I'm not sure that needing message publication to trigger flow control on > a producer is ideal. Been looking at the Active MQ producer window size and > wonder if we can't use a similar approach ? > ( > http://activemq.apache.org/maven/activemq-core/apidocs/src-html/org/apache/activemq/ActiveMQMessageProducer.html#line.71 > ) > > Thoughts ? > > Bfn, > Marnie > > On 6/26/08, Rafael Schloming <[EMAIL PROTECTED]> wrote: >> >> Aidan Skinner wrote: >> >>> I wrote up a quick sketch of what I'm planning on implementing for >>> flow controlling producers to protect the broker from out of control >>> producers / dead clients causing massive build up. Comments on this >>> would be welcome, as I'm going to have to start hacking on it RSN. >>> >>> http://cwiki.apache.org/confluence/display/qpid/Producer+flow+control >>> >> >> A few random questions/comments... >> >> Why throw an exception by default? I'd think you would want a configurable >> timeout, i.e. by default you block for n seconds, and when the time is up >> throw an exception. >> >> What should the client expect when an exception is thrown, did the message >> go through or not? >> >> Why stop the producer *after* putting the message on the queue? Is it >> really that expensive to check whether the queue is too large *before* >> putting the message on? In general this seems backwards, e.g. if a client >> were to publish a single message to a queue that is full, and then move on >> to other unfull queues, you could end up blocking the client for no reason. >> >> Are the limits going to be byte based, message based, or both? >> >> How do you intend to block the producer? >> >> --Rafael >> > >
