[rabbitmq-discuss] RabbitMQ+STOMP Plugin: Bulk Message Allocation Behavior?

[Darien Kindlund]

Hi Tony,

Thanks for the patch!  I'll try it out and let you know if I run into
any problems.  If I upgrade the STOMP adapter code with your patch,
will I still be able to use it with RabbitMQ 1.5.0?  (Or must I
upgrade that to v1.5.1 also?)

Thanks,
-- Darien

On Tue, Feb 3, 2009 at 3:39 PM, Tony Garnock-Jones <tonyg at lshift.net> wrote:
> I've just committed a patch to the STOMP adapter that calls out to
> Basic.Qos. It doesn't work with the Ruby STOMP client at the moment, because
> that client doesn't let you specify custom headers to CONNECT, but works
> with Net::Stomp.
>
> To switch on prefetch-windowing, you have to set "prefetch" to non-zero on
> CONNECT, and "ack" to "client" on SUBSCRIBE. To see what the "prefetch"
> CONNECT header is for, look at the documentation for the "prefetch count"
> field in the Basic.Qos command in the AMQP specification.
>
> Regards,
>  Tony
>
> Darien Kindlund wrote:
>>
>> Okay, thanks.  If there's a way to reduce the prefetch window to 1
>> message via the STOMP adapter, I'd appreciate it.  I'm guessing that
>> when you reduce the prefetch window, you also incur an additional
>> latency in overall message delivery.  In the long term, I'm thinking
>> that having programmatic control over this window size would help me
>> determine a realistic value that works for my application.
>>
>> -- Darien
>>
>> On Tue, Feb 3, 2009 at 2:46 PM, Tony Garnock-Jones <tonyg at lshift.net>
>> wrote:
>>>
>>> Hi Darien,
>>>
>>> This is because acknowledgement and prefetch-windowing are orthogonal
>>> issues. RabbitMQ very recently gained prefetch-windowing control in the
>>> form
>>> of AMQP's "Basic.Qos" method, but there's no support for that in the
>>> STOMP
>>> adapter yet.
>>>
>>> I'll take a look.
>>>
>>> Tony
>>>
>>>
>>> Darien Kindlund wrote:
>>>>
>>>> Hi Tony,
>>>>
>>>> Using: RabbitMQ 1.5.0 / Stomp 1.5.0
>>>>
>>>> Maybe you can shed some light on this.  I have a topic exchange setup
>>>> with one (durable) queue bound to the exchange.  All messages sent to
>>>> the exchange are using a single Net::Stomp perl process and have the
>>>> proper routing key such that all messages get sent to the shared
>>>> queue.
>>>>
>>>> I also have about 75 to 100 perl processes all using Net::Stomp which
>>>> are subscribed to the same queue, receiving these messages.  Each perl
>>>> process receives one message, processes the message, then sends back
>>>> an explicit ACK (client => 'ack') to the queue in order for the
>>>> message to be removed from the shared queue.
>>>>
>>>> Here are the order of events:
>>>>
>>>> 0) No perl processes are subscribed to the queue.
>>>> 1) 50,000 messages are sent to the exchange and are routed to the
>>>> queue (which are stored on the queue).
>>>> 2) 50 perl processes start up and subscribe to the queue and start
>>>> processing the messages.
>>>> ... wait 1-2 minutes ...
>>>> 3) rabbitmqctl shows that messages_ready=0, BUT
>>>> messages_unacknowledged=messages_uncommited=30000
>>>> 4) 10 new perl processes start up and subscribe to the queue.  At this
>>>> point, these 10 new perl processes NEVER obtain any of the remaining
>>>> 30,000 messages
>>>>
>>>> Here's the problem:
>>>>
>>>> I want each perl process to handle ONE and only one message at a time,
>>>> yet it seems that RabbitMQ (or the STOMP adapter) pre-allocates more
>>>> than one message per STOMP connection.  Bottom line: This means that
>>>> one of the perl processes can be overloaded with messages while
>>>> another perl process may not have any messages to process.
>>>>
>>>> Could you please confirm that this is, in fact, happening?  Next,
>>>> could you provide a recommendation as to how I should resolve this
>>>> issue?
>>>>
>>>> Thanks again,
>>>> -- Darien
>