[rabbitmq-discuss] Exchange with throttling

[Tim Watson]

Just to add to Emile's comments, I there are a couple of things to 
consider here.

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.

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.

Cheers,
Tim

On 07/28/2012 11:52 AM, Félix López wrote:
> Thanks,
>
> 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.
>
> The plugin is here 
> https://github.com/flopezluis/rabbitmq-throttling-exchange, It has a 
> lot to improve and certainly I'm not sure of the impact of this 
> exchange in the performance of rabbitmq.
>
>
> 2012/7/24 Emile Joubert <emile at rabbitmq.com <mailto:emile at rabbitmq.com>>
>
>     Hi,
>
>     On 23/07/12 18:20, Félix wrote:
>     > Is there anything similar in rabbitmq?
>
>     Yes, the broker has a connection-based flow control mechanism - see
>     http://www.rabbitmq.com/memory.html#per-connection
>     and a blog post that explains further:
>     http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-part-1/
>
>     Bear in mind that blocking an Erlang process will lead to a backlog in
>     its internal mailbox without slowing down the network. Also, the
>     exchange is not a natural control point for bandwidth limiting,
>     because
>     an exchange is not a process. A channel would be a more natural
>     choice.
>     You may be able to adapt the existing flow control mechanism to grant
>     credits based on bandwidth rather than message count.
>
>
>
>     -Emile
>
>
>
>
> -- 
> http://www.linkedin.com/in/flopezluis
>
> It's easier to ask forgiveness than it is to get permission
>
>
> ".....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."
> --Mark Cuban"
>
> "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
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://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/20120730/675fc544/attachment.htm>