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: [email protected] For additional commands, e-mail: [email protected]
