[jira] Commented: (QPID-1262) [AMQP-0-8/9] Client can incorrectly report CommitOK if previous commit timed out.

["Martin Ritchie (JIRA)" <qp...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639391#action_12639391 ] 

Martin Ritchie commented on QPID-1262:
--------------------------------------

Whilst the CommitOk from the previous loop can cause this failure when we loop the tests. I don't see how it can cause a problem when we have closed the connection between test run as happens in our test suite.

> [AMQP-0-8/9] Client can incorrectly report CommitOK if previous commit timed out.
> ---------------------------------------------------------------------------------
>
>                 Key: QPID-1262
>                 URL: https://issues.apache.org/jira/browse/QPID-1262
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: M2.1, M3
>            Reporter: Martin Ritchie
>             Fix For: M4
>
>
> Summary:
> As shown by the new SyncWaitTimeoutDelayTest there is a bug in AMQP. The TxCommitOk bodies do not have a correlation id so it is impossible to tell if the TxCommitOk received is for the last TxCommit sent if you have timed out a previous commit.
> Attached is a log for this behaviour. As this is an AMQP bug it is unlikely we can resolve it in Qpid. 
> Question is does 0-10 also exhibit this behaviour.
> Work around is to close the session after a commit timeout this will ensure that the TxCommitOk does not spuriously arrive on the client. It does however leave you unsure of the commit state, but presumably there was a reason you gave up waiting for the TxCommitOk and are prepared for the operation actually succeeding but never being notified about it.

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