Consumer message buffer

[johnnysoccer]

A question about the consumer message buffer, and the impact it has on moving messages between queues.

We have a system where we monitor each durable subscription on a topic and, based on the accumulation of messages, make a determination that a particular subscription is not performing adequately and we want to move it's messages to a holding queue specific for it's messages in order to avoid degrading the performance of the other durable subscriptions on the topic.

Using JMX, I am able to move the messages from one queue to another, but I occasionally get messages that remain in the original queue. My assumption is that these are messages in the consumer message buffer that have yet to be acknowledged as processed. I started to force a disconnect from HornetQ to the machine that is non-performing, in hopes that this would immediately release the messages in the buffer so they could be moved to the alternate queue. Still no luck, though I have observed that after a period of time (probably associated with HornetQ cleaning up its resources) that the messages eventually become available to move.

Is there a way to make the messages in the buffer immediately available to be moved by a call to QueueControl.moveMessages() without having to wait for the timeout, or disable the consumer message buffer?

-- John

[clebert.suconic]

Those messages are being delivered. The only way to make them available to redelivery is if you remove the consumers by a management call.

You could also disable buffering on the clients if your consumers are doing slow processing.

[timfox]

Unacknowledged in delivery messages will get returned to the queue immediately if the sessions that have them are closed.

[johnnysoccer]

Two questions then, regarding Clebert's response. wouldn't removing the consumer cause the messages to be lost since the consumer has (had) a durable subscription?

Tim, How do I identify which session belongs to the specific queue in order to close it from a management call?

John

[timfox]

No, the whole point of a durable subscription is it is durable.

The consumer can close than "reattach" at some later date to consume the messages. That's what distinguishes a durable from a non durable subscription.

[johnnysoccer]

I apologize, I understand that the consumer being durable is what allows it to reconnect at a later time.  I guess I was just thinking in terms of management calls that the only one I have seen for disconnecting a consumer was 1) to disconnect all connections from an address (which is what I do right now) which doesn't seem to close the session, hence the problem with still having messages in the buffer, and 2) the call on the topic to drop the durable subscription, which, as it says, drops the durable subscription.

It seems the key is closing the session, which leads back to my previous question.  Is there a management call for closing a specific session? All I've noticed is one for listing the sessions, though you need to know which connection_id's they are associated with.