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,

Few comments below.

-Anish
--

Matthew Lovett wrote:
> 
> 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)
> 

Yes, RMS can do that, but it will have to do that (and get a fault) even 
when there is no message loss.

> 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

Or the RMD may (if it chooses to do so) retransmit the 
TerminateSequenceResponse message.

> 
> b3. 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 a 
> TerminateSequenceReply or an UnknownSequence fault
> 

If we were to make TS a req-response then RMS will have to retry 
wsrm:TerminateSequence until it gets back a 
wsrm:TerminateSequenceResponse message or a fault.

> b4. A badly behaved RMS does not send a <wsrm:TerminateSequence>
> - The RMD will probably rely on some implemetation-specific cleanup
> 
> 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.
> 

Regardless of what we do in the protocol, there will always be the case 
where the RMS or RMD or the underlying network has a problem and the RMD 
and RMS must be able to handle that (cleanup/rollback/whatever).

I thought what Bob was going for was to allow the RMS and RMD to be sure 
of normal termination in the no-message loss case.

> 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?
> 

I think making it req-res is an interesting proposal. Personally, I need 
to think more on this.

> Matt
> 
> 


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