You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Oleksandr Rudyy <or...@gmail.com> on 2016/12/09 16:40:59 UTC
Closing connection whilst MessageListener in-flight delivery is in progress
Hi,
Recently I noticed that new jms client can fail to acknowledge the
message (with auto-ack delivery mode) which was 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.
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)
Although such behavior could be considered JMS spec compliment, as the
specs states in "4.3.5 Closing a Connection" of JMS spec 1.1:
"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."
Thus, it seems that closing of the connection is allowed without
sending the acknowledgment, 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
client to acknowledge the delivered messages with
MessageConsume#onMessage before the connection close.
Are there any plans to change the client to wait for in-flight message
delivery acknowledgment before closing the connection?
Kind Regards,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Closing connection whilst MessageListener in-flight delivery is
in progress
Posted by Robbie Gemmell <ro...@gmail.com>.
On 9 December 2016 at 16:40, Oleksandr Rudyy <or...@gmail.com> wrote:
> Hi,
>
> Recently I noticed that new jms client can fail to acknowledge the
> message (with auto-ack delivery mode) which was 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.
> 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)
>
> Although such behavior could be considered JMS spec compliment, as the
> specs states in "4.3.5 Closing a Connection" of JMS spec 1.1:
> "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."
>
> Thus, it seems that closing of the connection is allowed without
> sending the acknowledgment, 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
> client to acknowledge the delivered messages with
> MessageConsume#onMessage before the connection close.
>
> Are there any plans to change the client to wait for in-flight message
> delivery acknowledgment before closing the connection?
>
> Kind Regards,
> Alex
>
No existings plans, feel free to JIRA it :)
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org