[
https://issues.apache.org/jira/browse/QPID-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307671#comment-15307671
]
Keith Wall commented on QPID-7044:
----------------------------------
I think on 6.0 and beyond we already have this behaviour. When publish
confirms are in use, the confirm is queued up in the transport's buffer list
(org/apache/qpid/server/protocol/v0_8/AMQChannel.java:520) , but it won't
actually go down the wire until control returns to the IO layer. This won't
happened until after #receivedCompleteAllChannels has been called. It calls
AMQChannel#sync, which completes the channel's unfinished commands. The
unfinished commands include the store's future. I think therefore that the
confirm ack won't appear on the wire until after the store async transaction
has finished.
This JIRA would have been applicable to 0.32 where the ack would have gone
asynchronously.
I think this JIRA and can be marked as Invalid.
> [Java Broker] [AMQP0-9-1 ext] Publish confirm ack should be sent after
> performing a sync
> ----------------------------------------------------------------------------------------
>
> Key: QPID-7044
> URL: https://issues.apache.org/jira/browse/QPID-7044
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Reporter: Keith Wall
> Priority: Minor
> Fix For: qpid-java-6.1
>
>
> When using publish confirms (the AMQP 0-9-1 extension), the Broker current
> sends the Ack back to the client immediately after the message is received
> completely. It ought to sync (completing the unfinished commands) before
> sending the Ack response.
> This defect does not affect use cases where messages are published in a
> transaction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
