Subject: AW: too fast out-of-SENT-order messages

From: "Martin Stecher" <[email-masked]>
Date: Fri, 28 Feb 2003 21:12:56 +0100

> 
> > > 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?
> 
> You may be right, depending on the application protocol and state. For
> example, it makes no sense to continue processing an _uncachable_ HTTP
> response if the client has left and the whole transaction (the HTTP
> request-response pair) can be terminated. If response is cachable, it
> may make sense to continue, especially if a large portion of the
> response has been received already, and if the cache stores
> post-processed responses.
> 
> [...]

It seems that I misunderstood the whole concept.
I thought a transaction could be more than a single request-response pair.
I thought when the OPES processor opens a transaction it tells the callout
server what to do with all following application messages, e.g.
<xaction-start "URL-classification for HTTP requests">
following hundreds of HTTP requests before the transaction stops.
That would have been a nice way to reduce the exchange of always the same
meta data.

Martin

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 28 Feb 2003 13:38:51 -0700 (MST)

> It seems that I misunderstood the whole concept.

I am glad you asked these questions, then! Clearly, predraft needs to
do a better job at defining OPES messages.

> I thought a transaction could be more than a single request-response

It could be, depending on the application protocol. This is an
_application_ transaction we are talking about here. For HTTP, an
application transaction could be a (request, response) pair or it
might be all messages related to the same (persistent) client
connection, or server connection (less likely).

Note that some protocols (e.g., HTTP) do not define a clear
transaction boundaries. In those cases, it will be always up to the
OPES dispatcher what to call an application transaction, I guess.

> I thought when the OPES processor opens a transaction it tells the
> callout server what to do with all following application messages,
> e.g. <xaction-start "URL-classification for HTTP requests">
> That would have been a nice way to reduce the exchange of always the
> same meta data.

You seem to be thinking about OPES transactions here. Those are not
(yet?) defined in predraft version of the protocol.

We need application transactions and application messages as OPES
"objects" because a lot of processing state (metadata) will be
associated with them. We may also need OPES transactions because, like
you said, there may be lots of state associated with them as well. We
already have OPES messages, of course.

I was thinking that OPES transactions might correspond to OPES
connections. That is why I did not introduce them into the draft yet,
waiting to hear more opinions on the connection management issues. It
is probably about time for me to make a specific proposal though.

In your experience, what kind of metadata/state would be associated
with an OPES transaction (separate from the application transaction)?
Same service IDs? Dispatcher- and callout-server-specific
info? Anything else?

Thank you,

Alex.

P.S. Perhaps we should change "xid" to "axid" to emphasize that
     it identifies an Application transaction.