[ https://issues.apache.org/jira/browse/QPIDJMS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Rudyy updated QPIDJMS-244: ------------------------------- Description: 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 specification v1.1 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 would cause duplicate message deliveries for those messages not being acknowledged on close. I would expect from the JMS client to acknowledge the in-flight auto-ack message deliveries with MessageConsume#onMessage before the connection close. was: 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. > 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.1.0, 0.2.0, 0.3.0, 0.4.0, 0.5.0, 0.6.0, 0.7.0, 0.8.0, > 0.9.0, 0.10.0, 0.11.0, 0.11.1, 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 > specification v1.1 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 would cause duplicate message deliveries for those messages not being > acknowledged on close. I would expect from the JMS client to acknowledge the > in-flight auto-ack 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