<html><head></head><body bgcolor="#FFFFFF"><div><br></div><div>On 30 Jul 2012, at 10:45, Félix López &lt;<a href="mailto:jaaaelpumuki@gmail.com">jaaaelpumuki@gmail.com</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div>Definitely I would like to&nbsp;extend&nbsp;the flow control mechanism&nbsp;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">&lt;<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>&gt;</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,&nbsp;
      <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.&nbsp;</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">&lt;<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>&gt;</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>
            &gt; 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>