ietf-openproxy
[Top] [All Lists]

RE: too fast out-of-SENT-order messages

2003-02-28 03:05:08

Hi,


We want to allow out-of-order transaction-dependent messages to be
able to abort an in-progress transaction as fast as possible.

There always may be a need to abort a transaction in progress,
by why "out-of-order" and why "as fast as possible"?

... because some may want this optimization.

For example, consider this situation: Callout server processing of
each response chunk is long and "expensive". The callout server is
processing the first chunk, and 9 next chunks are still in its TCP
buffers waiting to be parsed and processed.  The user aborts its
request. There is no reason for the callout server to continue, but it
will not know until it gets a <xaction-end> message. Without the
optimization in question, the callout server will not know until all
10 chunks are processed.


Wait a second, to avoid a misunderstanding.
The example you are describing is this really using a <xaction-end>
message to abort? I thought it should actually be a 
<producer-end amid reason> message instead of <xaction-end xid reason>
because other application messages within this transaction are not
affected, are they?


I am somehow undecided between solutions 0) and 2).
Maybe it makes sense to go for 2) and make clear in the protocol
that the abort messages MUST be sent via the normal channel.
It could then be an option or even extension that is not handled
in the protocol from the beginning to send these messages in
copy on a fast channel.

Regards
Martin

<Prev in Thread] Current Thread [Next in Thread>