[openamq-dev] queue_bind, size and consume/cancel

[Martin Sustrik]

Hi Dmitri,

> On consuming side, I have an application that declares a queue, creates
> binding and starts consuming.
> 
> I have noticed that OpenAMQ topic queue starts accumulate messages right
> after the binding was created, even there is no consumer - client didn't
> call ..._consume yet. So what happens on high volume messages load, is
> that queue size reaches the limit and gets killed by server, before
> client starts consuming from it.

Is there a problem in doing queue.create, basic.consume & queue.bind in 
that order?

> I thought that queue profile will help me
>     <queue_profile name = "shared">
>         <limit name = "warn" value = "50000" />
>         <limit name = "trim" value = "100000" />
>     </queue_profile>
> 
> but I noticed that my Queue still gets killed, even I set it to trim.
> Does "trim" works for shared queues? Is there another way to postpone
> consumption from the bound queue?

This looks like a bug. What kind of behaviour are you getting exactly? 
We'll have a look at it.

> When my client wants to stop consuming queue messages, it calls
> amq_client_session_basic_cancel. I noticed that this call takes
> significant amount of time on high volume queues. When it waits
> on ...basic_cancel call, I still see messages going to it from OpenAMQ
> server. 
> I tried ..._nowait version of cancel and it helps my application, but I
> am not sure if I play nice to amq server.

Nowait versions of individual commands behave the same as original 
commands, the only difference being that command completion confirmation 
is not sent to the client. This means that when you issue cancel_nowait, 
your application is free to continue, however, the cancel may have not 
been actually executed yet. If will be executed a bit later and you'll 
continue to receive the messages in the meantime.

> Is there a proper and fast way to cancel consumption. I've looked at
> amq_client_session_channel_flow... but I am not sure - or I should be
> prepared to wait for several seconds on that call?

If you have a single consumer per connection, the flow-off on the 
connection will behave in similar manner to cancel and it should be 
faster than cancel (I believe there is prioritisation of flow-off 
command to the other commands implemented).

Martin