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]

Jacques,

 

+1 on the need to decrease reliance on out-of-band 
polilcy negotiation. People tend to gloss over this saying "you pick up the 
phone and call the guy on the other end" but when that person works for a 
different company, in a different timezone, on a different continent etc. this 
out-of-band policy stuff is murder. You're lucky if you can exchange one test 
message a day. One test message a day multiplied by n! out-of-band policy 
combinations equals way too friggin' long to set up the 
connection.

 

- g

  

  
  From: Jacques Durand 
  [mailto:] 
Sent: Friday, July 15, 2005 7:29 
  AM
To: 'Doug Davis'
Cc: Christopher B Ferris; Doug 
  Bunting; 
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]

  

  

  
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:] 
Sent: Thursday, July 14, 2005 5:21 
  PM
To: Jacques Durand
Cc: Christopher B Ferris; Doug Bunting; 
  
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 
        <> 
        

        
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 
> >