[
https://issues.apache.org/jira/browse/QPIDJMS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPIDJMS-244:
-------------------------------
Summary: Connection close does not wait for in-flight message
acknowledgement with asyncronous auto-ack MessageConsumer (was: Connection
close does not wait for in-flight message acknowledgement in asyncronous
auto-ack MessageConsumer)
> Connection close does not wait for in-flight message acknowledgement with
> 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
