Messages can get stuck in queue if consumer is killed

[carl.heymann]

I executed a simple test on a standalone, non-clustered JBM 2.0.0-BETA1 instance, which caused messages to get stuck in the queue. Here are the steps:
1. Start a clean, standalone, non-clustered JBM 2.0.0-BETA1 instance.
2. Start a producer, putting 200 messages in a specific queue. Stop the producer process.
3. Start a session transacted consumer on the queue. It consumes all the messages.
4. Kill the consumer process (don't close&cleanup the consumer properly).
5. At this point there are no messages on the queue. Run the producer again to put another 200 messages on the queue, then stop the producer process.
6. Start the consumer process again. Now it doesn't consume any messages, even though we know there are 200 messages on the queue.

I would expect that the new consumer would eventually start receiving the messages, but they really seem stuck.

To get a consumer to consume any messages again, it is necessary to restart the messaging server. Thereafter the messages can be consumed again.

The problem doesn't occur at all if the consumers are cleanly closed in stead of the processes killed.

Is this a known issue? I don't see any JIRAs on something like this for JBM 2.

[timfox]

Hi Carl-

If consumers crash or exit without cleanly closing their connections, then sometime after the connection TTL time, the server should automatically close them on the server which would result in any delivered but unacknowledged messages going back on their queue(s).

Default connection ttl is quite long, this allows users to reconnect to any detached sessions on the server, after network problems etc.

http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta1/html/connection-ttl.html

If you'd like to reduce connection ttl to a lower value this can be done by setting the param on the connection factory or session factory.

Sometimes the server can take up 2 * connection TTL to actually clear up the connection, this is because it checks the connection state after connection TTL ms to see if any data has been received since the last time. So the first time it checks it the answer is yes, but the second time it is now.

We could do a little bit of work to make it never wait much more than connection ttl, but in all cases I have seen so far, connection was eventually cleared up.

[carl.heymann]

Hi Tim,

thanks, I'll see what happens if I play with the TTL.

Regards,
Carl