RE: [ws-rx] i0019 - a formal proposal - take 2

[Doug Davis <dug@us.ibm.com>]

Marc,
  Ever have a conversation with
someone about something and you're both actually talking about two different
things - I feel like this is the case here.
You quote me as saying "Close is
supposed to be used in cases where...something is going wrong".
You then say "If close is not for
addressing situations where something has gone wrong...then what is it
for?"

Store owner: this product will remove
stains
Customer: but what should I use to remove
stains?  

Note that the proposal does not address
what that something is nor does it say whether the RMS or the RMD detects
this bad thing.  It is designed for the RMS to get an accurate and
final state of the sequence - without regard for why it wants to know or
what it plans on using this information for.  Also note that the proposal
changes a couple of Faults so they do not terminate a sequence. Not sure
if this helps the point you were trying to make but I'm a bit lost.

You said "So
if Close is not for addressing the fault issues in i019 and it isn’t for
use when a sequence is fine then what is it for? "
- and again, I'm lost - it _is_ for cases where the there's a fault.

Let me take a guess at what you might be
thinking...are you suggesting that i019 is focusing on one particular Fault
and this proposal doesn't help that particular Fault scenario?  If
so, check the issue and the proposal.  The issue talks about 3 different
types of faults - as of now all three of them are terminating (meaning
the sequence goes away afterwards).  This proposal changes two of
them so they are not terminating - meaning Close() can be used because
the sequence has not been forgotten.  The last remaining Fault (SequenceTerminated),
as the name implies, does terminate the sequence.  True, this proposal
does not help with this one Fault but I consider this fault to be used
in cases where all hope is lost and the RMD needs to forget about the sequence
because something catastrophic has happened.  If you check the proposal,
it introduces another Fault called SequenceClosed - this Fault can now
be used in cases where the sequence needs to shutdown but not necessarily
totally forgotten.  Something akin to SequenceTerminated but not quite
as drastic.  To me, this new Fault should be used in most cases where
SequenceTerminated would have been used in the past - this would allow
the RMS to still ask for the state of the sequence.  Continuing to
use SequenceTerminated doesn't help the RMS since it can't query for the
state once the sequence has been forgotten.

Actually, rereading the proposal, I think
there might be an area that can be cleared up.  It focused on the
RMS sending a Close() to shut it down, but it also possible that the RMD
can choose to shut it down itself.  I'll modify the proposal to make
that clearer.  Would this help clear things up for you?

I think Chris addressed your DA question
in his 'dead horse' response.  :-)

thanks
-Doug

"Marc Goodner" <mgoodner@microsoft.com>

09/01/2005 01:12 AM

To	Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
cc
Subject	RE: [ws-rx] i0019 - a formal proposal - take 2

Doug, you said below:
 
“I don't believe your text
is accurate in that Close is supposed to be used in cases where the sequence
needs to end due to something going wrong.”
 
i019 is titled Sequence termination
on Fault and is concerned with the RMD terminating a sequence and the RMS
wanting to know the final state of sent messages. So if Close is not for
addressing situations where something has gone wrong, like faults that
this issue is concerned with, then what is it for? Furthermore this proposal
is all about actions taken by the RMS, how does that solve the issue of
problems originating at the RMD?
 
You then go on to say:
 
“You've
described a case where the sequence is functioning just fine - and while
Close can be used in those cases as well, it provides no additional value.”
 
So if Close is not for addressing
the fault issues in i019 and it isn’t for use when a sequence is fine
then what is it for? 
 
You then go on to specify a
use of the Close operation when there is a problem. It is unclear to me
if the problem you describe is at the RMS or RMD. I’m also now even more
confused as to what problem this is solving based on your own descriptions
it seems we have wandered away from the issue this is supposed to be addressing.

 
I also share concerns with
this that it doesn’t work with all of the DAs. That makes it unique in
a bad way, I can’t think of another feature in RM that would break when
one DA was in place but not another.

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, August 30, 2005 1:08 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
 

Yet more comments. :-) 
-Doug

"Stefan Batres" <stefanba@microsoft.com>

08/30/2005 03:35 PM

To	Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
cc
Subject	RE: [ws-rx] i0019 - a formal proposal - take 2

 

Doug,
 
Some more comments and thoughts on your proposal:
 
 
<dug>... When or why an RMS uses CloseSequence is up to it to decide.
All we know is that it wants to shut things down and get an accurate ACK from the RMD.</dug>
 
I still have not heard of a plausible reason why an RMS “wants to shut things down” and the current spec presents a problem. Comparing the spec as it stands today vs. the spec + this proposal:
 

• TODAY: RMS wants to end the sequence so it sends a LastMessage and must wait for a complete set of acks; this might require retransmitting messages. Once a full set of acks is received RMS sends TerminateSequence.

• TODAY + THIS PROPOSAL: RMS wants to end the sequence so it sends Close, waits for a CloseResponse, possibly retransmitting the Close. Once a CloseResponse is received RMS sends TerminateSequence.

The problem with the TODAY scenario, as I’ve heard it in this forum, is
that the RMS might have to wait unacceptably long between sending LastMessage
and getting a full ack range. But if getting some messages or acks across
proves difficult; why would the RMS expect that getting Close across would
be any easier? 

<dug> 1 - I don't believe your text is accurate in that Close is
supposed to be used in cases where the sequence needs to end due to something
going wrong.  You've described a case where the sequence is functioning
just fine - and while Close can be used in those cases as well, it provides
no additional value.  2- Sending a Close and sending application data
can have quite a different set of features executed so I don't think its
hard to imagine cases where RM messages can get processed just fine but
application messages run into problems.  I believe Chris mentioned
on some call the notion of two different persistent stores - one for RM
data and one for app-data.  Its possible that the app-data one is
running into problems.  3 - Using the CloseSequence operation is option
- if you feel that, as an RMS implementor, you'll never see its usefulness
then you're free to never implement/send it.  However, I'd hate remove
this option for those of us who do see value in it.  </dug>



  
<dug>The case that I keep thinking about is one where the RMD is
actually a cluster of machines and when a sequence gets created it has
an affinity to a certain server in the cluster - meaning it processes all
of the messages for that sequence. If that server starts to have problems,
and for some reason it just can't seem to process any new app messages
then the RMS can close down the sequence and start up a new one. Hopefully,
the new sequence will be directed to a different server in the cluster.
</dug> 
  
There are two problems with this scenario and the proposed solution.
1.      If
an RMD has sequence-to-machine affinity that should be strictly the RMDs
decision and the RMDs problem. The RMS is autonomous; this proposal puts
expectations on the RMS’ behavior based on particularities of the RMD
implementation. To be clear, I’ll note that affinity can be achieved in
two ways: 
                    
                     
             i.
           By
performing stateful routing at the RMD; basically the RMD has to remember
every active sequence and what machine it has affinity to. In this case
it would be simple to change the RMD’s routing table when a machine fails.
                    
                     
            ii.
           By
generating different EPR’s for each machine. For affinity to function
this way two things are necessary:
1.      Some
sort of endpoint resolution mechanism would have to be devised for the
RMS to learn the EPR that it should target.
2.      A
mechanism for migrating that EPR.

Clearly 1) and 2) are outside the scope of the TC and, in my view, this proposal might be defining 2) in an informal way that is specific to WS-RM.

 
2.      If the RMS somehow guesses that there is a problem on the EPR to which it is sending its messages and somehow decides that Closing the sequence and starting a new one is the right course of action, ordering guarantees are compromised.

<dug> I probably didn't state the problem very well.  I didn't intend to claim that the RMS knew about this affinity, but instead it knew that something was wrong with the current sequence and in order to try to fix the situation it decided to try another sequence.  The affinity bit was thrown in there to explain why starting a new sequence _might_ fix the problem.

I should also point out that while a lot of these discussions have focused on InOrder+ExactlyOnce DA, this feature is still useful in other DAs.  For example, if the DA is just ExactlyOnce - having an accurate accounting of the ACKs allows a subsequent sequence to send just the gaps from the first, so getting an accurate list of the gaps becomes critical.  And this of course leads us to the discussion of how to determine the DA in use - which I think might be part of issues 6, 9, 24 and 27.
</dug>
 
Finally, I agree with you that considering a gap-filling mechanism would be a good thing for this TC to do.
 
 
--Stefan