[jira] [Comment Edited] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back
[
https://issues.apache.org/jira/browse/QPID-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327037#comment-16327037
]
Keith Wall edited comment on QPID-8079 at 1/16/18 11:54 AM:
{{ServerTransaction.EnqueueAction}} are used in three places:
{{QueueManagingVirtualHost.Transaction#move}} and
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path
{{RoutingResult#send}} . The first two aren't affected as they are management
operations, use local transactions and don't thus use the async auto-commit
codes paths. I think the enqueue path could be a problem in the HA case. An
unfortunately timed loss of quorum whilst a message is being enqueued causing
the async auto commit transaction to fail could leak a message reference. (the
release within the rollback path of
{{org.apache.qpid.server.message.RoutingResult#send}} won't be called).
However, as in the HA case the loss of quorum results in a new master, I think
the net effect of the defect is currently nill.
In the non-HA case, if the underlying transaction fails, the Broker always
fails, so again the net effect of the defect is nill.
I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}}
so this defect cannot bite in future. Separately, I notice that one of the
{{AsyncAutoCommitTransaction#enqueue}} chains a {{postCommit}} rather than a
{{onRollback}}. This seems to a typo.
was (Author: k-wall):
{{ServerTransaction.EnqueueAction}} are used in three places:
{{QueueManagingVirtualHost.Transaction#move}} and
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path
{{RoutingResult#send}} . The first two aren't affected as they are management
operations, use local transactions and don't thus use the async auto-commit
codes paths. I think the enqueue path could be a problem in the HA case. An
unfortunately timed loss of quorum whilst a message is being enqueued causing
the async auto commit transaction to fail could leak a message reference. (the
release within the rollback path of
org.apache.qpid.server.message.RoutingResult#send won't be called). However,
as in the HA case the loss of quorum results in a new master, I think the net
effect of the defect is currently nill.
I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}}
so this defect cannot bite in future.
Separately, I notice that one of the AsyncAutoCommitTransaction#enqueue chains
a {{postCommit}} rather than a {{onRollback}}. This seems to a typo.
> [Broker-J] If the future associated with an AsyncCommand completes
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
>
> The protocol layers currently use AsyncCommands to organise for work to be
> completed after an async auto-commit transaction competes. When
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then
> calls underlying action. The code currently fails to call \{{onRollback}} in
> the failure case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back
[
https://issues.apache.org/jira/browse/QPID-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327037#comment-16327037
]
Keith Wall edited comment on QPID-8079 at 1/16/18 11:54 AM:
{{ServerTransaction.EnqueueAction}} are used in three places:
{{QueueManagingVirtualHost.Transaction#move}} and
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path
{{RoutingResult#send}} . The first two aren't affected as they are management
operations, use local transactions and don't thus use the async auto-commit
codes paths. I think the enqueue path could be a problem in the HA case. An
unfortunately timed loss of quorum whilst a message is being enqueued causing
the async auto commit transaction to fail could leak a message reference. (the
release within the rollback path of
{{org.apache.qpid.server.message.RoutingResult#send}} won't be called).
However, as in the HA case the loss of quorum results in a new master, I think
the net effect of the defect is currently nill.
In the non-HA case, if the underlying transaction fails, the Broker always
fails, so again the net effect of the defect is nill.
I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}}
so this defect cannot bite in future. Separately, I notice that one of the
{{AsyncAutoCommitTransaction#enqueue}} chains a {{postCommit}} rather than a
{{onRollback}}. This seems to a typo.
was (Author: k-wall):
{{ServerTransaction.EnqueueAction}} are used in three places:
{{QueueManagingVirtualHost.Transaction#move}} and
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path
{{RoutingResult#send}} . The first two aren't affected as they are management
operations, use local transactions and don't thus use the async auto-commit
codes paths. I think the enqueue path could be a problem in the HA case. An
unfortunately timed loss of quorum whilst a message is being enqueued causing
the async auto commit transaction to fail could leak a message reference. (the
release within the rollback path of
{{org.apache.qpid.server.message.RoutingResult#send}} won't be called).
However, as in the HA case the loss of quorum results in a new master, I think
the net effect of the defect is currently nill.
In the non-HA case, if the underlying transaction fails, the Broker always
fails, so again the net effect of the defect is nill.
I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}}
so this defect cannot bite in future. Separately, I notice that one of the
{{AsyncAutoCommitTransaction#enqueue}} chains a {{postCommit}} rather than a
{{onRollback}}. This seems to a typo.
> [Broker-J] If the future associated with an AsyncCommand completes
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
>
> The protocol layers currently use AsyncCommands to organise for work to be
> completed after an async auto-commit transaction competes. When
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then
> calls underlying action. The code currently fails to call \{{onRollback}} in
> the failure case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back
[
https://issues.apache.org/jira/browse/QPID-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327037#comment-16327037
]
Keith Wall edited comment on QPID-8079 at 1/16/18 11:49 AM:
{{ServerTransaction.EnqueueAction}} are used in three places:
{{QueueManagingVirtualHost.Transaction#move}} and
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path
{{RoutingResult#send}} . The first two aren't affected as they are management
operations, use local transactions and don't thus use the async auto-commit
codes paths. I think the enqueue path could be a problem in the HA case. An
unfortunately timed loss of quorum whilst a message is being enqueued causing
the async auto commit transaction to fail could leak a message reference. (the
release within the rollback path of
org.apache.qpid.server.message.RoutingResult#send won't be called). However,
as in the HA case the loss of quorum results in a new master, I think the net
effect of the defect is currently nill.
I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}}
so this defect cannot bite in future.
Separately, I notice that one of the AsyncAutoCommitTransaction#enqueue chains
a {{postCommit}} rather than a {{onRollback}}. This seems to a typo.
was (Author: k-wall):
{{ServerTransaction.EnqueueAction}} are used in three places:
{{QueueManagingVirtualHost.Transaction#move}} and
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path
{{RoutingResult#send}} . The first two aren't affected as they are management
operations, use local transactions and don't thus use the async auto-commit
codes paths. I think the enqueue path could be a problem in the HA case. An
unfortunately timed loss of quorum whilst a message is being enqueued causing
the async auto commit transaction to fail could leak a message reference.
However, as in the HA case the loss of quorum results in a new master, I think
the net effect of the defect is currently nill.
I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}}
so this defect cannot bite in future.
> [Broker-J] If the future associated with an AsyncCommand completes
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
>
> The protocol layers currently use AsyncCommands to organise for work to be
> completed after an async auto-commit transaction competes. When
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then
> calls underlying action. The code currently fails to call \{{onRollback}} in
> the failure case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
