OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] Issue i078


Matt,

A few comments in-line

Granted, with or without this modification, an RMD must be able to do reoutine housekeeping and must be able to clean up after ALL potential protocol errors, orphaned sequences, and so forth.

 


From: Matthew Lovett [mailto:MLOVETT@uk.ibm.com]
Sent: Wednesday, December 07, 2005 12:18 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] Issue i078

 


Hi all,

I'd like to kick off some discussion about issue i078. I see where it is coming from, and I do have some sympathy with the issue, but I'm not sure that making the operation 2-way really helps. Consider the following cases (where I assume that terminate sequence is still one-way):

a1. RMS sends a <wsrm:TerminateSequence> and the RMD receives it
- all ok, but the RMS doesn't know that
- If the RMS wants to it can retry until it gets an UnknownSequence fault (always one more message than we needed)

a2. RMS sends a <wsrm:TerminateSequence>, which is lost
- The RMD will probably rely on some implemetation-specific cleanup
- If the RMS wants to it can retry until it gets an UnknownSequence fault (always one more message than we needed)

a3. A badly behaved RMS does not send a <wsrm:TerminateSequence>
- The RMD will probably rely on some implemetation-specific cleanup

If we put a 2-way terminate sequence into the mix then we get an increase in the number of cases, but I don't see much advantage

b1. RMS sends a <wsrm:TerminateSequence> and the RMD receives it, and the reply gets back to the RMS
- all ok

b2. RMS sends a <wsrm:TerminateSequence> and the RMD receives it, but the reply gets lost
- all ok, but the RMS doesn't know that
- If the RMS wants to it can retry until it gets an UnknownSequence fault

b3. RMS sends a <wsrm:TerminateSequence>, which is lost
- The RMD will probably rely on some implemetation-specific cleanup

b4. A badly behaved RMS does not send a <wsrm:TerminateSequence>
- The RMD will probably rely on some implemetation-specific cleanup
- If the RMS wants to it can retry until it gets a TerminateSequenceReply or an UnknownSequence fault

I think that it would look more like this:

B1. RMS sends a <wsrm:TerminateSequence>,
- If the RMS sees TerminateSequenceReply, then all is ok,

- If the RMS did not see the response, it will re-try the <wsrm:TerminateSequence>
- The RMS retries until it gets a TerminateSequenceReply or an UnknownSequence fault  In either case its next state remains the same; or it gets bored and declares an exception.

B2. A badly behaved RMS does not send a <wsrm:TerminateSequence>
- The RMD will probably rely on some implemetation-specific cleanup

 

I don’t really see this as a complication



So, we have complicated the protocol, but a defensive RMD still needs some way to clean up stale sequences. The advantage is that sometimes the RMS will get an unambiguous TerminateSequenceReply, though the RMS still needs to handle the case where it gets a UnknownSequence fault.

I also believe that the overwhelming majority of <wsrm:TerminateSequence> messages will get to the RMD. Given that I think that the best thing to do here is leave the operation as a 1-way.

Does anyone else have any comments?

Matt



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]