[rabbitmq-discuss] Exchange with throttling

[Félix López]

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

2012/7/30 Tim Watson <tim at rabbitmq.com>

>  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>
>
>> 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 listrabbitmq-discuss at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120730/624a1cac/attachment.htm>