Doug [Davis]:
You just put your finger on
a curious thing in WS-RM:
- Why does a
MessageNumberRollover fault terminate the sequence on Destination side?
Why not simply reject any
"exceeding" message, and wait for the Source to close the seq after
it gets this fault, (or let an expiration condition kick-in if applicable) like
it would do under normal circumstances?
That would allow for a
gracious handling of pending non-acknowledged valid messages - something that has
to be handled by the Source with regular termination. That would also allow for
gracious cross-sequence ordering (in case that mattered to our
grand-grand-children...)
Because of this questionable
termination policy and because of it only, the net effect of recovering from a MessageNumberRollover
fault will not be as good as preventing it as you point out.
Now, Rollover conditions can
always happen and a sharp implementation has to best handle them anyway. I
still believe that the benefit of dealing with a rollover fault after 19 quintillion
messages only instead of say 9 quintillion, is rather meager with regard to
increased reliance on a proper out-of-band sharing of policies.
If we want a Source to be
made aware of the maximum handled by a Destination so that it can avoid rolling
over in the future , my recommendation would be a more dynamic option, such as
returning this limit in the CreateSequenceResponse or even just adding it to
the Rollover fault.
Jacques
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Thursday, July 14, 2005 5:21
PM
To: Jacques
Durand
Cc: Christopher B Ferris; Doug
Bunting; ws-rx@lists.oasis-open.org
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]
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
<JDurand@us.fujitsu.com>
07/14/2005 07:27 PM
|
|
To
|
Christopher B Ferris/Waltham/IBM@IBMUS, Doug
Bunting <Doug.Bunting@sun.com>
|
|
cc
|
Doug Davis/Raleigh/IBM@IBMUS,
Doug.Bunting@sun.com, ws-rx@lists.oasis-open.org
|
|
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:chrisfer@us.ibm.com]
Sent: Thursday, July 14, 2005 3:20 PM
To: Doug Bunting
Cc: Doug Davis; Doug.Bunting@Sun.COM; ws-rx@lists.oasis-open.org
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: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295
Doug.Bunting@Sun.COM
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
> >