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 13:58:00 GMT

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

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

Commit 63c315f07553dcdf32e2de1888f1cb9749e15d5c 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=63c315f ]

QPID-8091: [Broker-J] Update transaction timeout chapter in docbook

* Remove note regarding AMQP 1.0
* Generalise from 'producer transaction timeout' to 'transaction timeout'.  The former was
only true when using the Qpid JMS AMQP 0-x client
  (which delayed acking the messages until the application called commit).
* Update the operational log messages


> [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