qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-8091) [Broker-J] [AMQP 1.0] Store transaction timeout feature
Date Fri, 09 Feb 2018 16:10:00 GMT

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

ASF subversion and git services commented on QPID-8091:
-------------------------------------------------------

Commit d57815f89427781bb3cf3d5f6c70b3b13a8604ff in qpid-broker-j's branch refs/heads/master
from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=d57815f ]

QPID-8091: [Broker-J] Move transaction timeout protocol test to separate packages - this features
is Broker-J specific.

Also refactored the new test broker configuration mechanism so that the configuration of the
whole broker can be adjusted,
rather than just the virtualhost.


> [Broker-J] [AMQP 1.0] Store transaction timeout feature
> -------------------------------------------------------
>
>                 Key: QPID-8091
>                 URL: https://issues.apache.org/jira/browse/QPID-8091
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Broker-J
>            Reporter: Keith Wall
>            Assignee: Keith Wall
>            Priority: Major
>             Fix For: qpid-java-broker-7.1.0
>
>
> Berkeley JE's design means that once a transaction has begun, its internal cleaner is
unable to clean beyond the point the transaction started in the transaction log.  Other transaction
work continues as normal, but the disk space utilisation can't shrink until the long running
transaction is completed.  In an extreme case, disk space can be exhausted.
> This has consequence for long running store transactions in Qpid.  For 0-x, the transaction
timeout features allows the the length of time a transaction may be open or idle to be constrained,
thus limiting the harmful effects of a long running store transaction.
> For robustness, that features needs to be implemented on AMQP 1.0 too.   A decision
needs to be made about the correct course of action to be taken when a long running transaction
exceeds the threshold.   The transaction coordinator link could be closed with an error or
the entire connection closed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message