Re: [ws-rx] i119 - discussion of ballot

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

Everyone will have their own definition
of "corner case" but since I think a lot (most?)
people view ref-params as info that
is used for routing purposes it only seems
natural (IMO) to view them as critical
pieces of data when trying to determine if a 
message is going to the right place.
 WSA itself defines ref-params as:

A reference may contain a number
of individual parameters that are associated
with the endpoint to facilitate a
particular interaction. Reference parameters are 
namespace-qualified element information
items that are required to properly 
interact with the endpoint.

"required to properly interact"
- doesn't seem that WSA views the importance of
these as "corner cases" either.
 But, without knowledge of what each ref-param
is actually used for (whether its for
routing or just for some header to be included
in the msg) it would seem that for interop
purposes the RMD should take the safest
approach and check them all.  Maybe
this is an argument for a "SHOULD" instead
of a "MUST" when doing the
checking?

I do agree with your comment that it
would be far more optimal if we could just
look at the wsa:Address but given that
we have ref-p's I don't see how we can
avoid 'em.

If I understand your 'uncoordinated'
comment correctly, you're saying that a
gateway should know how to route the
message, right?  But if the Body is
intended for backend#1 and the Ack is
intended for backend#2 how would
that work? Or are you suggesting that
the gateway should split the msg into
pieces and send each part to the correct
backend machine? Or are you 
requiring that the gateway machine understand
all possible RM states
for all backend machines?

thanks,
-Doug

Doug Bunting <Doug.Bunting@Sun.COM>
Sent by: Doug.Bunting@Sun.COM

05/22/2006 11:57 AM

To	Doug Davis/Raleigh/IBM@IBMUS
cc	ws-rx@lists.oasis-open.org
Subject	Re: [ws-rx] i119 - discussion of ballot

Doug,

Some of this discussion certainly happened in the "chat room".
 I 
(separately from the interop question) asked there why we were 
optimizing for the clustered corner case?  In the far more common
case 
where one system is an RMS for multiple ongoing conversations, latency
would be greatly reduced if /every/ message intended for that 
transfer-level destination were able to carry /every/ available 
acknowledgement.

As well, a correctness issue arises if and only if the clustered RMS is
completely uncoordinated.  Seems as if we're optimizing for the poor
implementation of a corner case.

thanx,
    doug

On 21/05/06 19:02, Doug Davis wrote:
>
> On last Thursday's call (or perhaps it was in the webconf) someone
> asked why this issue wasn't seen during the interop - I wanted to
> address this.  During the interop we only tested the most basic
of 
> scenarios and in particular single endpoint to endpoint testing.  i119
> will most likely show itself in cases where an RMS is running in a
> clustered environment - clearly not something we would normally test
> during an interop.  In such an environment the wsa:Address of
the 
> acksTo might be common across all endpoints behind the gateway/cluster
> and the routing may be based on reference parameters.  So, as
a result 
> if the only thing an RMD examined when determining whether or not
to 
> piggy-back Acks was just the wsa:Address then the Acks might flow
to 
> the wrong back-end machine (if each one had its own RM state).  And
of 
> course, the reverse can be true for SeqAck if the RMD was behind in
a 
> clustered environment as well.  This is why its dangerous to
not have 
> some form of EPR comparing (aside from just the wsa:Address) when
> making these determinations.
> -Doug