You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Lionel Cons <li...@cern.ch> on 2011/08/26 11:34:23 UTC

How can a broker stop a STOMP producer?

In Apollo, one can set slow_consumer_policy=block for a topic. This is
described as:

  the producers block on slow consumers which makes producers only as
  fast as the slowest consumer on the topic

I guess one can achieve something similar in ActiveMQ too.

But how can a broker block a producer over STOMP where it doesn't know
what the next client frame will be?

Does this translate into returning an ERROR frame for a SEND frame to
the "blocked topic"?

Does it mean stop reading from the producer after the first SEND frame
is received? If yes, what happens for new clients? Are they all
allowed to send one message before being blocked?

FWIW, we have a typical use case with many distributed clients
connecting over STOMP just to send one message and then disconnect.

Cheers,

Lionel

Re: How can a broker stop a STOMP producer?

Posted by Hiram Chirino <hi...@hiramchirino.com>.
Lionel,

Right now in apollo we suspend doing more socket reads from the
blocked producer.  And like you said, a connection always can accept
at least one message, so if you couple that with synchronous sends
then the client can just use a timeout strategy to figure out that he
has been blocked.

Note that on a high throughput producer, he will be blocked many times
per second even though he's moving a large volume of messages.


Regards,
Hiram

FuseSource
Web: http://fusesource.com/




On Fri, Aug 26, 2011 at 5:34 AM, Lionel Cons <li...@cern.ch> wrote:
> In Apollo, one can set slow_consumer_policy=block for a topic. This is
> described as:
>
>  the producers block on slow consumers which makes producers only as
>  fast as the slowest consumer on the topic
>
> I guess one can achieve something similar in ActiveMQ too.
>
> But how can a broker block a producer over STOMP where it doesn't know
> what the next client frame will be?
>
> Does this translate into returning an ERROR frame for a SEND frame to
> the "blocked topic"?
>
> Does it mean stop reading from the producer after the first SEND frame
> is received? If yes, what happens for new clients? Are they all
> allowed to send one message before being blocked?
>
> FWIW, we have a typical use case with many distributed clients
> connecting over STOMP just to send one message and then disconnect.
>
> Cheers,
>
> Lionel
>

Re: How can a broker stop a STOMP producer?

Posted by Dejan Bosanac <de...@nighttale.net>.
Hi Lionel,

Stomp protocol define "synchronous send" semantics by using receipts. So
when producer sends a message to a broker (with a receipt header in it), it
should wait from the broker for the RECEIPT frame back. And the broker
should return RECEIPT only it successfully stored a message. So if broker is
out of resources (memory, disk, etc.), the producer will be blocked until
broker process the message.

Regards
-- 
Dejan Bosanac - http://twitter.com/dejanb
-----------------
The experts in open source integration and messaging - http://fusesource.com
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net


On Fri, Aug 26, 2011 at 11:34 AM, Lionel Cons <li...@cern.ch> wrote:

> In Apollo, one can set slow_consumer_policy=block for a topic. This is
> described as:
>
>  the producers block on slow consumers which makes producers only as
>  fast as the slowest consumer on the topic
>
> I guess one can achieve something similar in ActiveMQ too.
>
> But how can a broker block a producer over STOMP where it doesn't know
> what the next client frame will be?
>
> Does this translate into returning an ERROR frame for a SEND frame to
> the "blocked topic"?
>
> Does it mean stop reading from the producer after the first SEND frame
> is received? If yes, what happens for new clients? Are they all
> allowed to send one message before being blocked?
>
> FWIW, we have a typical use case with many distributed clients
> connecting over STOMP just to send one message and then disconnect.
>
> Cheers,
>
> Lionel
>