On Thu, May 26, 2005 at 09:44:57AM +0600, Jaliya Ekanayake wrote: Hello all,
thanks for your answers. > >> ExponentialBackoff, policy assertion is used to increase the value of > retransmission interval with the number of retries. IMO all these timing > related policy assertions are for the tune-ups for the RMSource and > RMDestination that participate for a communication. These endpoints may not > interpret the exact timings of these assertions, instead they tune up their > respective values (policy related) to get a fine tuned message transfer. In > Sandesha we use this value in Sender and the necessary intervals are checked > before sending any message. Yes, I think I understand the use of Exponential Backoff in Sandesha. However, which form is used, or rather, which form should be used in WSRM, generally -- one that only lengthens the interval or one that shortens (or resets) it as well? The first introduces the problem of not being able to recover from transient faults, that's why I am asking. > >>IMO, it should happen to a particular sequence. However with the current > axis implementation there is no policy support that we can change as per > different sequences. (no dynamic policy) We use an xml file to load these > properties and use them in message level rather than in the sequence level. Ok, so it is not per-message but per sequence, right? By the way, what does Axis not supporting policies mean in re- gard to these interval adjustment methods? One could still im- plement them in Sandesha (since that is where they belong), and the only impediment lies in the absence of some infrastructure to communicate or change what is used, or is there more to it? > >> Oops, We have not implemented the Backoff strategy until today :),I have > fixed it and please check the code now. Thank you. > >>We actually consider your idea about the message number, however the > specification allows the maximum value of the message number to be a > limitation of the implementation rather than a fixed value. Please see the > following section. > > " /wsrm:Sequence/wsrm:MessageNumber > This required element MUST contain an unsignedLong representing the ordinal > position of the message within a Sequence. Sequence MessageNumbers start at > 1 > and monotonically increase throughout the Sequence. If the message number > exceeds the internal limitations of an RM Source or RM Destination or > reaches the maximum value of an unsignedLong (18,446,744,073,709,551,615), > the RM Source or Destination MUST issue a MessageNumberRollover fault. > Page 10 of 37" Ah, sorry, I must have overlooked the limitation part. Not to be nitpicky, but then you need to check whether the message number, first represented as a Double, is larger than what a long could hold _before_ casting that Double to long, don't you? Currently, MessageNumber.fromSOAPEnvelope just compares with WSRM.MAX_MSG_ NO, which is 2^64-1. > IMHO, Use of "long" is always faster than the BigInteger method and since > the spec is also supporting this, let's keep this unchanged :) Ok ;) Regards, Philipp Reinecke
