[rabbitmq-discuss] request for help!

Thu May 6 13:53:22 BST 2010

Hi Davorin

On 6 May 2010 11:21, Davorin Rusevljan <davorin.rusevljan at gmail.com> wrote:

> I hope you do not mind beginner "how would I xxx in amqp1.0" type
> questions. They are not direct comments on the standard specs, but maybe
> some of them could eventually lead to the points that could be better
> explained, so answering them might not be a complete waste of time. (but if
> you do mind please let me know so that I can stop).
>
> So, as far as I see consumer issues a credits to the link, and if I am
> reading it correctly, it can stop the delivery of the messages to him that
> way. Now is there a way (automatic or programmed) for a broker or producer
> to get rid of the consumer if the number of messages awaiting for him to
> consume gets to high? Motivation for that would be preventing some ill
> intended client from DOSing the producer broker by forcing it to store large
> number of messages.
>
>
The sender of messages should be able to indicate that despite the fact
that, while the receiver of messages has issued credit, the sender will not
send more until the receiver has acknowledged some of the existing
outstanding messages.  Thus the receiver can make the choice as to whether
it wants to receive more messages - in which case it needs to acknowledge
some of those it is holding on to (thus allowing the sender to delete them),
or whether it wishes to continue working with the messages it has.  In
general there is no obligation for the sender to send even if credit has
been supplied - but it should indicate through its state it is choosing not
to send because there is too much unresolved state already, not because
there are no messages to send.

At first glance it looks like the documentation for this case is missing
from the spec - thanks for pointing this out, and well spotted!

Also note that at any time the sender may chose to unilaterally disconnect
the link, session or even the connection with an appropriate error code (for
instance there may be a policy to do so with "slow" consumers who are
preventing messages being garbage collected from a "Topic" node).

Hope this helps,
Rob

> Thanks!
>
> davorin rusevljan
> http://www.cloud208.com/
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/19572ab9/attachment.htm 