Alex Rousskov wrote:
[...] I suggest that we keep it simple unless somebody argues that
reordering message parts is common/important enough to be optimized
for.
Agreed! Anyone else, if there are good reasons not to do so, now is
the time to speak up!
[...] Copying _commitment_ (i.e, "I will copy from now on" flag)
allows for "getting out of the loop" optimization but is also
subject to deadlock.
Got it, I somehow missed that you were talking about the copying
*commitment*.
> [...] One way to avoid the deadlock is to support the following
> confirmation/dialog:
>
> server: I want to get out of the loop!
> processor: OK, you can get out of the loop after
> processing first N bytes of this application
> message (N could be zero). I will stop
> sending you more data as of now.
> server: here is the data you asked for (could be
> several data messages)
> server: I am out of the loop
>
> Unfortunately, supporting this kind of dialog efficiently requires
> dedicated/priority connection: The primary data connection may be
> clogged by (yet unprocessed) data messages to the callout server,
> preventing the "OK" response from reaching the server fast. If the
> "OK" response is slow, there may be little gain from the
> optimization because a lot of data messages would be processed by
> then.
OK, let me see whether I understood the scenario correctly: The
callout server has decided that it has seen enough and wants to get
out of the loop as quickly as possible. This is signaled to the OPES
processor and happens at "Time A". After receiving the signal from the
callout server, the OPES processor sets a specific "end" flag in the
next outgoing message, indicating to the callout processor the end of
the specific transaction. This message is received by the callout
server at "Time B". Between "Time A" and "Time B", the callout server
can discard any message it receives for this transaction and that has
the [copied] flag set (doesn't seem to be too much overhed). Messages
without the [copied] flag set have to be sent back to the OPES
processor (which has to be done anyway...).
Or are you more concerned about messages that might be stuck in the
local queues at the OPES processor? But this seems to be more of a
local implementation issue...
Thanks,
Markus