Hi Keith, I think that closing the connection is the simplest reasonable thing to do in order to fail early on transaction timeout. Though, I believe that the handling of transaction timeouts can be improved further by closing the link(s), where the timed out transactional work have been performed. That would allow other transactional and non-transactional links on the same connection to continue to operate without the impact. I also do not think that closing of coordinator link would be necessary in this case, as other link transactions can be run on the same coordinator link.
Kind Regards, Alex On 6 February 2018 at 14:34, Keith W <keith.w...@gmail.com> wrote: > An AMQP1.0 question has arisen during the implementation of > QPID-8091[Broker-J] [AMQP 1.0] Store transaction timeout. I would > like some guidance as to the best way to use AMQP 1.0 in this > situation. > > Background: > > Broker-J has a defence against long running store transactions. The > reason this defence exists relates to the way Berkeley BDB JE works: > once a transaction is started, the BDB JE cleaner is unable to > progress past that point in the transaction log until that transaction > completes. If a transaction remains open for a long period of time > whilst other work continues, the transaction log will grow until > eventually disk space is exhausted and the system fails. Broker-J's > defence against this it is to identify messaging connections that have > long running transactions and terminate them, allowing the transaction > to rollback and the cleaner to do its work. When this happens, on > the wire, for AMQP 0-8..0-91 the connection is closed and for AMQP > 0-10 the session is detached. > > Question: > My question relates to the best way to do an analogous action for AMQP 1.0. > > It would be possible to simply close the connection (as AMQP 0-8..0-91 > does) , but this seems distasteful. More attractive - superficially > at least - would be to somehow signal to the transaction controller > that the time-out has occurred, and let other unrelated work continue. > > I noticed that transaction-error includes a transaction-timeout [1] > option. I am intrigued to know the intended use-case(s). > > It would be possible to signal the timeout by having the transactional > resource detach the coordinator link with a transaction-timeout. This > would require that transaction coordinators be capable of handling > reasonably a spontaneous coordinator link detach. > > Assuming this is reasonable approach, what should be done with > existing transfers that are associated with timed-out transactions? > Things seem less than straight-forward: > > 1) For transactional posting - the transactional resource would need > to reject the transfers (if the link supported the outcome) or close > the link from where they came otherwise. > > 2) For transaction retirement - the specification allows[2], in the > event of a controller-initiated rollback that the deliveries (which > are still 'live' and still acquired by the controller) to be enlisted > by the coordinator into a new transaction (or none). It seems to me > reasonable that this should also apply in the timeout situation i..e > transaction resource initiated rollback. > > 3) For transaction acquisition - as there is no provision in the > specification for existing transfers to be assigned a different > transaction-id, I suppose the onus would be on the transaction > coordinator to reject the transfers. > > Having explored the idea, I find myself returning to a position of > simply closing the connection. The complications for both the > transaction resource and transactional controller outweigh any > benefits. However, I would appreciating hearing other thoughts and the > background for transaction-timeout. > > Kind regards, > Keith. > > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#choice-transaction-error-transaction-rollback > [2] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#doc-idp120240 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
