[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]