[AMQP1.0] Intended use-case of transaction-error transaction-timeout

[Keith W <ke...@gmail.com>]

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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: [AMQP1.0] Intended use-case of transaction-error transaction-timeout

[Oleksandr Rudyy <or...@gmail.com>]

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 <ke...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>

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