Alex Rudyy created QPIDJMS-244:
----------------------------------

             Summary: Connection close does not wait for in-flight message 
acknowledgement in asyncronous auto-ack MessageConsumer
                 Key: QPIDJMS-244
                 URL: https://issues.apache.org/jira/browse/QPIDJMS-244
             Project: Qpid JMS
          Issue Type: Improvement
          Components: qpid-jms-client
    Affects Versions: 0.11.1, 0.11.0, 0.10.0, 0.9.0, 0.8.0, 0.7.0, 0.6.0, 
0.5.0, 0.4.0, 0.3.0, 0.2.0, 0.1.0, 0.20.0
            Reporter: Alex Rudyy


The jms client can fail to acknowledge the message  (with auto-ack delivery 
mode) which is in a process of delivery with MessageListener when 
Connection#close() is called from main application thread.

The exception like the one below is delivered into ExceptionListener:
Connection ExceptionListener fired, exiting.
{noformat}
javax.jms.IllegalStateException: The MessageConsumer is closed
    at 
org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessageConsumer.java:328)
    at 
org.apache.qpid.jms.JmsMessageConsumer.doAckConsumed(JmsMessageConsumer.java:372)
    at 
org.apache.qpid.jms.JmsMessageConsumer.access$600(JmsMessageConsumer.java:52)
    at 
org.apache.qpid.jms.JmsMessageConsumer$MessageDeliverTask.run(JmsMessageConsumer.java:679)
    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)
{noformat}

Such behavior could be considered JMS spec compliment, as the
JMS 1.1 specification states in "4.3.5 Closing a Connection" :
{quote}
If one or more of the connection’s session’s message listeners is processing a 
message at the point when connection close is invoked, all the facilities of 
the connection and its sessions must remain available to those listeners until 
they return control to the JMS provider."
{quote}

Thus, it seems that closing of the connection is allowed without sending the 
acknowledgment (and waiting for response), as acknowledgment is sent after the 
control is returned to JMS provider.

However, from practical point of view, such behavior might not be
desirable, as it causes duplicate message deliveries for those
messages not being acknowledged on close. I would expect from the JMS
client to acknowledge the in-flight message deliveries with
MessageConsume#onMessage before the connection close.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to