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] i0019 - a formal proposal - take 2


Lei/Jacques,

I think that it should be clear that (IMHO) DA has nothing to do with 
i019. The purpose of the proposal
is to provide an "accurate and final acknowledgement status". That says 
nothing about whether messages
are, or are not, delivered to the AD. It is no different than the case of 
a Sequence terminating normally.
Even if you get an Ack that says all of the messages are *received*, it 
tells you nothing about which, if any,
of the messages that were *received* are actually *delivered* to the AD by 
the RMD. That isn't the concern
of the RM protocol.

One can make no assumptions in this regard, regardless of the DA.

The point that this issue and Doug's proposal address is providing an 
accurate and final acknowledgement.
This information *could* (but need not) be used by the RMS to determine 
which messages are safe to
send in a new Sequence, because the RMS is positive that the RMD has not 
received them (and even
if it did, they would be dropped on the floor, since the Sequence is 
closed).

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/31/2005 03:20:21 PM:

> Lei:
> 
> (sorry for having been silent on this thread last couple of days - was 
away for a while, and 
> getting into a frenzied catch-up mode now...)
> 
> Although my personal impression is that there are very good reasons 
(technical, business levels) 
> for the RMS to be aware of the DA, I did not want to get into this now. 
I tend to agree with Doug 
> statement for very pragmatic reasons: the issue you raised (and the 
cross-sequence consistency) 
> can reasonably be separated from this one I believe - or, put in other 
terms, the solution we are 
> trying to reach for i019 is very unlikely to become inadequate with 
whatever upgrade would come 
> out of your issue (maybe some modest amendment at best).
> 
> Regards,
> Jacques
> 
> 
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Tuesday, August 30, 2005 5:43 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
> 
> 
> Lei, 
>   Yes that is true.  So there are two thing here: 1) the proposal 
doesn't say why the RMS is 
> closing the sequence nor does it say what it will use the final ACK 
state for.  This is very 
> important.  It purposely does not get into that area because, as others 
have stated, things like 
> linking of sequence should probably be done by some higher level 
processing, which is out of scope
> (as of now anyway).  And  2) this problem exists for other areas of the 
spec, not just this 
> proposal.  Let's say the an RMS reaches the MaxMessageNumber, as defined 
by the RMD.  The way to 
> resolve this is to create a new sequence to continue - well how can we 
guarantee the ordering will
> be preserved across the sequences?  Same problem.  So this proposal does 
not introduce a new 
> problem, the problem is already there.  However, that being said, and 
even though several people 
> have said that doing things like preserving the order across sequences 
is something for a higher-
> level processing, I do personally believe that the spec should provide 
an aide to that processing.
> But I view that as a separate issue and not part of this one. 
> thanks 
> -Doug 
> 

> 
> "Lei Jin" <ljin@bea.com> 
> 08/30/2005 08:15 PM 
> 
> To
> 
> <ws-rx@lists.oasis-open.org> 
> 
> cc
> 
> 
> 
> Subject
> 
> RE: [ws-rx] i0019 - a formal proposal - take 2
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Let's assume we are using an in-order delivery assurance.  I am sending 
10 messages from AS to AD,
> and after some time, I decide to send a <close> for which I receive a 
final ack with (1 - 5). 
> 
> If I understand correctly, one of the motivations for having a final ack 
is so that you know the 
> accurate state of all the received messages, so that you can decide what 
to resend later in a new 
> sequence.  So let's say we start up a new reliable sequence and resends 
messages 6 - 10.  However,
> here is a problem.  How do I preserve the in-order delivery assurance? 
How do I guarantee that 
> message 6 will be delivered after message 5.  Note that the final ack 
only says (1 - 5) is 
> received, not delivered.  It's perfectly reasonable if message 5 is not 
delivered by the time 
> another sequence is set up and message 6 arrives.  In that case, are we 
going to have to worry 
> about delivery assurances across multiple sequences? 
> 
> Lei 
> 
> 
>  -----Original Message-----
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Tuesday, August 30, 2005 12: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 
> 
> 


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