[jira] Commented: (QPID-397) Client closeure can be processed before final message ack.

["Rupert Smith (JIRA)" <qp...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481206 ] 

Rupert Smith commented on QPID-397:
-----------------------------------

The javadoc for javax.jms.Session#close says:

"This call will block until a receive call or message listener in progress has completed. A blocked message consumer receive call returns null when this session is closed."

Therefore, calling close from onMessage ought to mean that the call blocks forever, waiting for onMessage to complete. In other words, you cannot call session.close from onMessage.

The situation where another thread calls session.close still exists and the close gets send before the ack, still exists. Creating a test case for it.



> Client closeure can be processed before final message ack.
> ----------------------------------------------------------
>
>                 Key: QPID-397
>                 URL: https://issues.apache.org/jira/browse/QPID-397
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker, Java Client
>    Affects Versions: M1, M2
>            Reporter: Martin Ritchie
>            Priority: Blocker
>             Fix For: M2
>
>
> We may need an AMQ protocol change to sort out this issue.
> Because the Qpid client uses a dispatcher thread to handle the sending of the ack during auto-ack. There is no guarantee it will send the Ack before a different thread calls consumer.close while the ack is in the process of sending to the broker.
> Perhaps.
> Lock whilst receiving message on consumer so the close cannot be sent first.
> Imagine test case..
> onMessage()
> {
> if(messageType == "Close")
> {
>  _consumer.close();
> }
> }
> Would be good if this could work.
> the close() call should stop receive calls but cannot wait for the receive call to finish. So if there is lock out on receiving request that the person relinquishing the lock performs a close.
> This would allow the close call to return... question is does JMS allow the close() call to return without the connection actually closing?
> Here is a thread trace:
> AnonymousIoService-8 2007-03-02 15:58:42,187 DEBUG [qpid.client.protocol.AMQProtocolHandler] Sent frame Frame channelId: 1, bodyFrame: class org.apache.qpid.framing.BasicCancelBody Class: 60 Method: 30  consumerTag: 1  nowait: false
> pool-1-thread-1 2007-03-02 15:58:42,187 DEBUG [qpid.server.protocol.AMQProtocolSession] Method frame received: Frame channelId: 1, bodyFrame: class org.apache.qpid.framing.BasicCancelBody Class: 60 Method: 30  consumerTag: 1  nowait: false
> Dispatcher-Channel-1 2007-03-02 15:58:42,187 DEBUG [apache.qpid.client.AMQSession] Sending ack for delivery tag 12 on channel 1

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.