RE: [ws-rx] NEW ISSUE: Is an implementation supporting a smaller maxmessage number valid? [Re: [ws-rx] NEW ISSUE: Max message number in policy]

I feel a bit like we're mixing the two
issues.  If I followed the thread correctly, most seem to be ok with
closing DougB's issue by saying that an implementation that chooses to
support a max message number that's less than the max unsigned long is
still a valid implementation - and I agree.  However, letting the
RM Destination fault when this occurs is not always something that the
source can recover from - which is the original issue I brought up.  When
the MaxMsgNumExceeded fault is thrown the sequence is terminated - this
means that any unreceived (resent) message (even ones with a smaller msg
# ) must be rejected.  So creating a new sequence does not preserve
the overall ordering across the two sequences - since unACKed messages
from the first can not simply be resent in the 2nd sequence.  This
is why I believe the RM assertion telling the RM Source what the max #
is is important - the fault needs to be avoided in the first place in order
to deal with creating subsequence sequences.

thanks,

-Doug

Jacques Durand <>

07/14/2005 07:27 PM

To

Christopher B Ferris/Waltham/IBM@IBMUS,
Doug Bunting <>

cc

Doug Davis/Raleigh/IBM@IBMUS,
, 

Subject

RE: [ws-rx] NEW ISSUE: Is
an implementation supporting a smaller         max
message number valid? [Re: [ws-rx] NEW ISSUE: Max message number in p  
     olicy]

While I fully agree with Chris' concern, I believe nothing
in the spec prevents Chris to implement exactly what he describes below:

- nothing prevents an RM destination to send back a MessageNumberRollover
*before* the specified maximum (unsignedLong max) is reached (!) 

In the mentioned Java context this occurrence would be
so remote that even if a Source is "surprised" by a lower maximum,
I'd say the overhead of recovering from the fault (meaning creating a new
sequence I guess - which needs be done anyway -, and resending some message)
is acceptable ... 

(Also even if an implementation can't handle that we'll
all die before :-) 

I was about to suggest that the current MessageNumberRollover
fault message could be extended to contain the maximum that has been exceeded,
in case this max is smaller than the specified maximum (unsignedLong max).
But it seems the Source can figure which messages have been lost in a wrap-around
event just by looking at the Acknowledgement.

Jacques  

-----Original Message----- 

From: Christopher B Ferris [mailto:]

Sent: Thursday, July 14, 2005 3:20 PM 

To: Doug Bunting 

Cc: Doug Davis; ; 

Subject: Re: [ws-rx] NEW ISSUE: Is an implementation supporting a smaller
max message number valid? [Re: [ws-rx] NEW ISSUE: Max message number in
policy]

Doug, 

A Java long is signed and hence it's maximum value is 

+9,223,372,036,854,775,807. 

In order to support an unsigned long, you need to resort
to use of 

java.math.BigInteger which 

is less efficient than using the primative type long. Besides that, J2ME

doesn't include java.math 

so it would therefore be even more difficult to implement a WS-RM endpoint

on that platform. 

Since nine quintillion is a REALLY BIG NUMBER,  (yeah,
yeah, 19 

quintillion is an even bigger number) 

we would like to propose that an endpoint  could declare the maximum

MessageNumber it supported 

is the maximum value of a long such that it would be possible to implement

processing of the 

MessageNumber using a Java long primitive type and so that the spec could

be implemented 

in a conformant manner on the J2ME platform. 

It would take ~292,471,208.67 years to exhaust a sequence
that was only 

the size of a long 

if you processed 1000 messages per second. 

Most of us will be dead before the first WS-RM Sequence
is exhausted even 

if it is reduced 

from 18 quintillion to 9 quintillion. 

Cheers, 

Christopher Ferris 

STSM, Emerging e-business Industry Architecture 

email:  

blog: http://webpages.charter.net/chrisfer/blog.html

phone: +1 508 377 9295 

 wrote on 07/14/2005 05:32:20 PM:

> *Title*: Is an implementation supporting a smaller
max message number 

valid? 

> 

> *Description*: The existing specification includes the clause "If
the 

> message number exceeds the internal limitations of an RM Source or
RM 

> Destination ...".  This allows a source or destination to
handle 

> unexpected failures gracefully.  It does not clearly allow, require,
or 

> prevent the implementation to be designed or deployed with a message

> number limit.  Should we support such a limitation?

> 

> *Justification*: Issue below presupposes a "yes" answer
to this 

> question.  Should decide this larger question before deciding
how to 

> fill gap left if the answer is "yes".

> 

> *Target*: core (RM spec) 

> 

> *Type*: design 

> 

> *Proposal*: I lean toward "no" but could be convinced otherwise.
 If 

> "no" is the answer, the specification could change to make
it clear a 

> WS-RM compliant implementation _must_ support the full unsigned long

> range for the message number.  That likely requires conformance

> terminology not presently in the specification; this issue is not

> intended to broach the even-more-general subject of conformance clauses.

>   My proposal therefore comes down to "close,
no action". 

> 

> *Related issues*: Max message number in policy [no number yet]

> 

> thanx, 

>    doug 

> 

> On 12/07/05 07:39, Doug Davis wrote: 

> > 

> > *Title*: Max message number in policy 

> > *Description*: define a policy assertion that defines the highest

> > message number the RM destination will accept.

> > *Justification*: without knowing in advance what the highest
message 

> > number is the RM source may exceed it, causing the entire sequence
to 

be 

> > terminated - when it may have been able to start a 2nd sequence
to 

> > continue its work.  By allowing the RM source the option
of 

terminating 

> > the sequence gracefully it can still deliver lost messages for
the 

> > original sequence.  As it stands now, if the sequence is
terminated 

the 

> > lost messages will not be resent. 

> > *Target:* RM policy spec 

> > *Proposal:* Define: 

> > /wsrm:RMAssertion/wsrm:MaxMessageNumber 

> > /wsrm:RMAssertion/wsrm:MaxMessageNumber@number - unsigned long

> > 

> > thanks 

> > -Doug 

> >