<html><head></head><body bgcolor="#FFFFFF"><div><br></div><div>On 30 Jul 2012, at 10:45, Félix López <<a href="mailto:jaaaelpumuki@gmail.com">jaaaelpumuki@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>Definitely I would like to extend the flow control mechanism to support something similar as I've done with plugin, so someone can set a maximum messages per second or something similar<br><br></div></blockquote><div><br></div><div>The flow control mechanism at the moment uses the concept of credit. You could possibly use internal or user defined sensors to limit or release available credit, without introducing throttle points at unnatural junctions in the process flow. I'm not saying we would do that, just that it sounds like a more convincing approach to customising flow control. The key thing is to understand where you actually want to introduce back pressure, as apply it in the wrong place almost certainly won't help and a lot of careful thought went into designing the existing approach, so (a) changing that would require just as much careful consideration and (b) opening the choice of how to apply throttling to user defined actions, sensors or throttles would require even more careful design. We would also have to consider the implications of supporting this, as any arbitrary user code that runs inside rabbit can have a variety of effects which need to be understood and documented.</div><div><br></div><div>I would also like to offer another architectural approach to meeting this requirement. By introducing traffic management in a border controller you obviate the need to alter the broker's behaviour in potentially unpredictable ways. A border control component doesn't have to be AMQP aware, so you can defer to smart network kit or a trusted software implementation. If a single connection (to a given endpoint) can be both producer and consumer, then a traffic manager that isn't aware of AMQP framing could potentially block progress by, for example, preventing ACKs from being delivered where a single client connection is handling both roles over two different channels. In this case, you could deploy a rabbit node to act as a border controller and use an intermediary client (say the erlang direct client, which is likely to be very efficient in this respect) to do the rate limiting before forwarding messages to the real destination endpoint. I think it's worthwhile exploring the alternative possibilities before adding complexity to the broker.</div><br><blockquote type="cite"><div><div class="gmail_quote">
2012/7/30 Tim Watson <span dir="ltr"><<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Just to add to Emile's comments, I there are a couple of things to
consider here.<br>
<br>
Firstly, it's important to point out that letting the Channel
process mailbox fill up could lead to unexpected and unpredictable
performance characteristics, and doesn't appear to offer anything
that per-connection flow control isn't already doing. Also, creating
an mnesia transaction for each routing operation is likely to
produce an altogether *different* kind of throttling of Rabbit's
performance across a cluster, and probably (in fact, almost
certainly) not the one you intended.<br>
<br>
I would strongly recommend reconsidering this approach. If you're
interested in extending the flow control mechanism to support
alternative measures, then perhaps we should have a collective
conversation about that instead, as Emile is quite right in
suggesting that approach makes more sense.<br>
<br>
Cheers,<br>
Tim<div><div class="h5"><br>
<br>
On 07/28/2012 11:52 AM, Félix López wrote:
</div></div><blockquote type="cite"><div><div class="h5">Thanks,
<div><br>
</div>
<div>
<div>I've finally made a plugin to do that. I think what I
wanted to do It cannot be possible with mechanism you sent me
in the email. </div>
<div><br>
</div>
<div>The plugin is here <a href="https://github.com/flopezluis/rabbitmq-throttling-exchange" target="_blank">https://github.com/flopezluis/rabbitmq-throttling-exchange</a>,
It has a lot to improve and certainly I'm not sure of the
impact of this exchange in the performance of rabbitmq.</div>
<div><br>
</div>
<br>
<div class="gmail_quote">2012/7/24 Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
On 23/07/12 18:20, Félix wrote:<br>
> Is there anything similar in rabbitmq?<br>
<br>
Yes, the broker has a connection-based flow control
mechanism - see<br>
<a href="http://www.rabbitmq.com/memory.html#per-connection" target="_blank">http://www.rabbitmq.com/memory.html#per-connection</a><br>
and a blog post that explains further:<br>
<a href="http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-part-1/" target="_blank">http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-part-1/</a><br>
<br>
Bear in mind that blocking an Erlang process will lead to a
backlog in<br>
its internal mailbox without slowing down the network. Also,
the<br>
exchange is not a natural control point for bandwidth
limiting, because<br>
an exchange is not a process. A channel would be a more
natural choice.<br>
You may be able to adapt the existing flow control mechanism
to grant<br>
credits based on bandwidth rather than message count.<br>
<span><font color="#888888"><br>
<br>
<br>
-Emile<br>
<br>
</font></span></blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<a href="http://www.linkedin.com/in/flopezluis" target="_blank">http://www.linkedin.com/in/flopezluis</a><br>
<br>
It's easier to ask forgiveness than it is to get permission<br>
<br>
<br>
".....it doesn't matter how many times you fail. It doesn't
matter how many times you almost get it right. No one is going
to know or care about your failures, and either should you. All
you have to do is learn from them and those around you
because...All that matters in business is that you get it right
once. Then everyone can tell you how lucky you are."<br>
--Mark Cuban"<br>
<br>
"Always be the worst guy in every band you're in." If you're the
best guy there, you need to be in a different band. And I think
that works for almost everything that's out there as well." Pat
Metheny<br>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
rabbitmq-discuss mailing list
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><a href="http://www.linkedin.com/in/flopezluis" target="_blank">http://www.linkedin.com/in/flopezluis</a><br><br>It's easier to ask forgiveness than it is to get permission<br>
<br><br>".....it doesn't matter how many times you fail. It doesn't matter how many times you almost get it right. No one is going to know or care about your failures, and either should you. All you have to do is learn from them and those around you because...All that matters in business is that you get it right once. Then everyone can tell you how lucky you are."<br>
--Mark Cuban"<br><br>"Always be the worst guy in every band you're in." If you're the best guy there, you need to be in a different band. And I think that works for almost everything that's out there as well." Pat Metheny<br>
</div></blockquote></body></html>