RE: [ws-rx] Fw: Sequence termination, and issue 19 [i019]

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: RE: [ws-rx] Fw: Sequence termination, and issue 19 [i019]

>In summary:
>The RM source may send ack requested, even after a fault has occurred. The >RM source should send an explicit terminate sequence message for every >sequence, even after a fault. The RM destination should not drop the >sequence state until it receives the terminate message (or the sequence >times out). If the destination is unable able to clean up 'gaps' in the >sequence then it marks the ack state as final.

In short, your proposal seems in agreement with both options 1 and 2 proposed in the issue log. Let me try to rephrase:

- a Sequence error may "disable" the sequence in the sense that RM Destination won't accept any more messages for it, but not terminate it in the sense that a TerminateSequence message is always expected to do this like in normal cases. The Source knows a sequence is disabled when receiving corresponding sequence error.

- as long as a sequence is not terminated, it can respond to ack requests.

Now, I am not sure if we need to introduce a special marker "final" in the ack of such disabled sequences (just trying to avoid introducing new signaling...): once a sequence error has been received by the RM Source, any response to an AckRequest sent after that will for sure return the final state.

Important note:
- Even in non-fault cases, an RM Source may decide to terminate a sequence even if some messages have not been received by Destination. It may be crucial for the Source to at least have an accurate image of the final state of the sequence, i.e. avoid cases where some late message was received by Destination after the last Ack was received by Source and before the TerminateSequence takes effect (because the RM Source will not be aware of such reception, the AS may be notified of failure and some inappropriate resending may take place at AS level). One way to address this is to return a (final) SequenceAck element as response to the TerminateSequence call.

Regards,
Jacques

-----Original Message-----
From: Daniel Millwood [mailto:MILLWOOD@uk.ibm.com]
Sent: Thursday, August 04, 2005 7:05 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] Fw: Sequence termination, and issue 19

Forwarding on behalf of a colleague who's not a full member of the TC. --
Matthew Lovett

I've been thinking around the topic of sequence shutdown (I'm avoiding the
term 'termination' for now). The spec seems clear on the fair-weather case:
the source is in control, is always able to get ack state, and explicitly
terminates the sequence when it is happy. It is less clear in error case,
where the provider has rased a fault.

I think a guiding principle is that the source should always (within
reason) be able to get accurate ack state. That state should give them as
much information as they need to make sensible recovery decisions. That
state is also governed by the remit of WS-RM - it should only express
information about the contract between the RM endpoints, and should not try
to consider the relationship between RM and the application.

I think we should introduce a 'final' flag to the Acknowledgement header.
If final is true, then the source can be sure that the ack state will never
change. That implies that any new / retransmitted application messages will
be ignored by the provider. See below for detail on the use of this flag.
(It's also worth noting that a complete sequence that included a last
message indicator would send 'final' ack messages.)

There are a variety of possible faults, each with their own impact. I don't
think we can hope to enumerate them all, but we can define some broad
cases, and define the protocol behaviour for each:

1: Fault such that no new messages may be added to the sequence (example:
LastMessageNumberExceeded)
- From the source point of view we should be able to fill in 'gaps' in the
sequence, before terminating it cleanly
- Protocol response is an fault message including the current ack state.
The source may re-transmit gaps, and may request ack state. If the state is
ever a complete sequence from 1 - limit, then the state becomes final. The
client may send a terminate sequence message at any time. If the source
sends a new message (e.g. a higher message number) then the RM destination
should respond with LastMessageNumberExceeded fault.

2: Fault such that no new messages may be added to the sequence, and the
destination cannot accept re-transmission of older messages
- From the source point of view we are quite stuck, and need higher
intervention to sort it out [see below]
- Protocol response is a fault message, including SequenceAcknowledgement
in 'final' ack state. The source may request ack state, or terminate the
sequence. If the source does retransmit a message then the destination
should reply with 'sequence is final' fault. If the source sends a new
message (e.g. a higher message number) then the RM destination should
respond with LastMessageNumberExceeded fault.

3: Fault such that all bets are off (provider no longer has any reliable
ack state for the sequence)
- From the source point of view we are quite stuck, and need higher
intervention to sort it out.
- Rather than define some new fault messages, the provider should dump it's
state and respond to source requests with 'sequence not known'. (We could
define a new 'sequence corrupted' fault, but the source is unlikely to be
able to do any more recovery than if it gets 'sequence not known', so there
is little benefit. In addition, in this failure mode, the provider may not
have any record of the sequence anyway!)

Note that I have said that all these cases should result in no new messages
being added to the sequence. There may be some faults where that need not
be true, but to accommodate it would require another flag. That seems like
an edge case that brings more problems, and it is not strictly needed
anyway - the client is free to create a new sequence.

The final flag exists to distinguish between cases 1 and 2. In case 1 the
client is able to recover, regardless of the delivery assurance between RM
destination and application. In case 2 the client recovery processing is
more complex - to recover automatically the client needs to know if the DA
was in-order or not, and as it cannot know that it must trigger higher
level processing to sort it out. By adding the flag we allowed many faults
to be handed at the protocol level, without needing higher intervention.

In summary:
The RM source may send ack requested, even after a fault has occurred. The
RM source should send an explicit terminate sequence message for every
sequence, even after a fault. The RM destination should not drop the
sequence state until it receives the terminate message (or the sequence
times out). If the destination is unable able to clean up 'gaps' in the
sequence then it marks the ack state as final.

Matt

Thanks,  Dan

WebSphere Platform Development
MP 211
Hursley
Tel. Internal 248617
Tel. External +44 1962 818617
Email. millwood@uk.ibm.com