Hi Davorin<br><br><div class="gmail_quote">On 6 May 2010 11:21, Davorin Rusevljan <span dir="ltr"><<a href="mailto:davorin.rusevljan@gmail.com" target="_blank">davorin.rusevljan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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).<br>
<br>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.<br>
<br></blockquote><div><br>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.<br>
<br>At first glance it looks like the documentation for this case is
missing from the spec - thanks for pointing this out, and well spotted!<br><br>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).<br>
<br>Hope this helps,<br>Rob<br>�</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thanks!<br><font color="#888888"><br>davorin rusevljan<br>
<a href="http://www.cloud208.com/" target="_blank">http://www.cloud208.com/</a><br><br>
</font><br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br>