Subject: too fast out-of-order messages

From: Alex Rousskov <[email-masked]>
Date: Thu, 27 Feb 2003 11:50:21 -0700 (MST)

No optimization comes for free. Here is a problem with supporting
priority message processing in OPES. I am seeking the group opinion on
how the problem should be handled.

We want to allow out-of-order transaction-dependent messages to be
able to abort an in-progress transaction as fast as possible. This
optimization has a problem: it is possible that the "fast"
<xaction-end> message will be processed by the callout server _before_
the server processes the corresponding <xaction-start> message. If the
current protocol rules are followed, that fast <xaction-end> message
will be ignored because it will not match any known transaction.
Moreover, the transaction may not be terminated at all, until the
timeout happens (which is exactly the opposite of what we want!).

Possible sane solutions:

	0) Prohibit out-of-order messages and related
	   optimizations.

	1) Prohibit out-of-order messages until the other
	   side acknowledges that it received the
	   <xaction-start> message (and, hence, the
	   transaction is now known to that other side).
	   The acknowledgment may be done explicitly
	   by immediately sending an <i-am-here> message
	   or implicitly by sending other transaction-dependent
	   messages as a part of normal operation.
	   We may even require immediate ACKs.

	2) Require <xaction-end> message to always be sent
	   via the usual [slow] channel, even if another
	   copy of the message was sent via a "fast" channel.
	   This way, if fast message is too fast, we have
	   no optimization but preserve the same semantics.
	   Same carbon-copy rule can be applied to all
	   future out-of-order messages. Note that it is
	   OK to send two <xaction-end> messages because
	   the second one will be ignored by the recipient.

Personally, I favor (2) because it allows for an optimization, is
simple, has no overheads for those that do not support the
optimization, and does not require creation of the "other side heard
us" state.

Note that we can inform implementors that they may _want_ to send
explicit ACKs as an optional feature (they are allowed to do that
already), especially if the callout server does not expect to send any
other transaction-dependent messages for some time. Again, the ACKs
should use existing <i-am-here> messages.

Comments/opinions?

Thanks,

Alex.

---

From: "Oskar Batuner" <[email-masked]>
Date: Thu, 27 Feb 2003 16:17:25 -0500

> 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"?  

I'd strongly suggest to avoid (to prohibit) cross-channel messages. 
All transaction processing should be done within the channel where 
it has started. Some kind of <transaction-abort> message may come 
at any moment as one side of transaction gets an abnormal condition 
that makes further processing unnecessary. But there is no "urgency" 
in transaction termination - just no need to continue. 

I can propose two type of scenarios: A. callout processor gets 
unrecoverable error condition (type 500) in situation when OPES 
processor keeps a copy of initial message waiting for the next 
more-data request. B. Data consumer unexpectedly closes connection 
to the OPES server while request processing is in process. In 
both cases other side of transaction does not expect transaction-end 
message - this is why I propose to have a special message that 
can appear at any moment (related to protocol state machine). 
But there is no need to expedite transaction termination, this 
is just a way out of intermediate processing status.

Can you propose scenarios where out-of-band message 
gives significant advantages?

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alex Rousskov
> Sent: Thursday, February 27, 2003 1:50 PM
> To: OPES Group
> Subject: too fast out-of-order messages
> 
> 
> 
> 

I support your choice (2), even in more strict definition: 
all transaction processing goes through the same channel on 
which it was started. (0) is not an option: there always are 
situations when regular processing can not be continued, so there 
should be some way out. (1) can not happen if everything goes 
on the same channel (in fact it is a good illustration what kind 
of problems may be created by asynchronous multi-channel processing). 

> should use existing <i-am-here> messages.

a) I think this is an overkill;
b) reuse of a message in a different sematic context is 
usually a very bad thing. In this situation it is very easy to 
misinterpret keep-alive message as a confirmation (well, you may 
introduce transaction id in keep-alive, but IMHO this creates even 
more mess).

Oskar

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 27 Feb 2003 15:14:01 -0700 (MST)

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

Please note that I am just explaining the motivation, not arguing
whether this optimization is worth supporting.

> it has started. Some kind of <transaction-abort> message may come at
> any moment as one side of transaction gets an abnormal condition

There is no semantics urgency indeed. It is a performance
optimization. See above for a typical example.

> can appear at any moment (related to protocol state machine).

Yes, your examples are valid. We already agreed to add the "abort"
mechanism. The only question is whether it makes sense to allow the
abort to happen faster, as a performance/resource optimization.

> gives significant advantages?

Yes, see my example above. A general optimization area is "slow and
expensive processing of data chunks for messages with multiple
chunks". Is this area large enough to be worth caring for?

> which it was started.

That is option, (0) actually. No optimization (see below).

> (0) is not an option: there always are situations when regular
> processing can not be continued, so there should be some way out.

Another terminology conflict! By out-of-order I mean out-of-SENT-order
not out-of-semantics-order: the message that was sent later was
received first. As agreed, <xaction-end error> can be sent at any time
and is never out of semantics order (i.e., you can stop at any time,
just like you wanted).

> (1) can not happen if everything goes on the same channel (in fact
> it is a good illustration what kind of problems may be created by
> asynchronous multi-channel processing).

Exactly. We need to decide whether the associated problems are worth
the optimization benefit. BTW, if you can think of any other problems,
please let me know. Keep in mind that only messages that can be sent
at any time (like your abort message) will be allowed on priority
channels if multi-channel support is added. We are not talking about
sending data out of order, for example.

> usually a very bad thing.

I agree, but the semantic context here is the same: "I am here,
processing xid".

> In this situation it is very easy to misinterpret keep-alive message
> as a confirmation (well, you may introduce transaction id in
> keep-alive, but IMHO this creates even more mess).

Actually, predraft-01 does have xids and even amids in <i-am-here>
messages :-). I do not see how they can hurt, and I can give examples
where they help (you may want to abort an application message due to a
timeout but still be able to finish the corresponding transaction
involving the other 9 messages; that is, you may want to be more
specific). But this is not related to the primary question of this
thread:

	Should we allow fast abort optimization?
	  If yes, how to make it safe?

Your last comments make the questions broader:

	Should we allow multi-channel transaction processing?
	  If yes, should we allow fast abort optimization?
	    If yes, how to make it safe?

Thank you,

Alex.