I don't understand what happens, if a queue-consumer does not ack a message, if the session is client_acknowledge.
I would think there is some kind of timeout, after which the message is considered "lost" + a resending to one of the queue's consumers? If you throw an exception in a message consumer, is the mesage explicitely "unacknowledged" (so that another consumer can stat consuming it)?
I ran into this problem while setting up jms over http. Say i have a jms server with an outgoing queue, and a remote client program, consuming messages from that queue.
When i boot the client, it starts consuming. After i killed and restarted the client, the server doesn't immediately notice. At least one message is never send to the "new" client. Though when i reboot the jms server (and the client), that one message finally reaches the client.
So it looks like the jms has chosen the dead client, to process that message. Since that client doesn't exists, the message is never ack'ed, and rebooting the jms forces the message to be redelivered.
I wonder how i can work arround this. I do not want to reboot the server every time a client goes down (which is impossible, because the server doesn't know when this client goes down).
-- resuming my test scenario:
I set up a jms server on machine S holding queue Q.
I post a message to queue Q.
I start a client on machine C.
The client consumes from Q, and receives and acks the message.
I kill the client process (it does not un-register with the queue).
I post a message to queue Q.
I start a client on machine C.
This message is NOT received.
I kill the client process.
I reboot the jms server jboss.
I start the client.
Now the message is received by the client.
