OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] Proposal for i055


+1

 


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, November 17, 2005 1:07 PM
To: Bob Freund-Hitachi
Cc: Yalcinalp, Umit; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposal for i055

 


I would support removal of IT if we were to rename it to a name that reflected
the nature of my proposal (e.g. OrphanTimeout) such that it ONLY applied
to the use case I described in my proposal, of either a CSR that was not received,
by the RMS due to network hiccup or misconfigured ReplyTo prompting another CS from the
RMS and an orphaned Sequence at the RMD.

Otherwise, I agree completely. Once a Sequence is established and in-use
it should not be automagically deleted for perceived inactivity.

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


"Bob Freund-Hitachi" <bob.freund@hitachisoftware.com> wrote on 11/17/2005 03:17:20 PM:

> I have argued in the past on threads related to other issues that IT
> is irrelevant and harmful.

> The following summarized my thoughts:
> What is the purpose of IT?
> Under normal optimistic situations, IT will never be triggered
> unless miss-configured since normal protocol operation cleaned up
> closed sequences as you go.

> A proper setting for IT might be something like a factor of two or
> more over the worst-case inter-message time, thus the expiration of
> IT is indicative of an endpoint or channel failure and therefore
> will usually be treated as an exception that may (will?) need
> propagation to the application since recovery is highly application dependant.

> I expect that the intended purpose of IT was to deal with resource
> cleanup for orphaned sequences.   Resource reclamation is something
> that is related to the resource capacity of the endpoint and is
> impossible for the RMS to predict the resource availability of the
> RMD and vice versa unless a much more elaborate protocol is
> envisioned.  Therefore it is obvious that IT can only be sensibly be
> set locally, and indeed that might also be difficult to determine
> based purely on resource availability. I wonder exactly what result
> would occur if IT were set higher than could be honored? I suppose
> that the endpoint would need to implement resource threshold based
> reclamation in any case.  Since that is likely true, it is not clear
> what IT is really good for.

> Death of a connection or an endpoint may be caused by many reasons,
> all of which beg for recovery.  I see no reason to create one more
> synthetic way to declare a sequence dead other than the more natural
> causes such as the network guy tripping over a cable.

>  
> My counter-counter proposal is to resolve this issue as well as
> issue 56 by removing IT since it causes more trouble than it is worth.

>  
> Thanks
> -bob
>
> From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
> Sent: Thursday, November 17, 2005 11:34 AM
> To: Christopher B Ferris; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Proposal for i055

>  
> Hi Chris,
>  
> I agree with your concern with respect to keeping a sequence active
> when there are no application messages in the sequence have been
> sent. Some kind of heartbeat appears to be hacky at best, but lets
> look at why people may choose to implement such a solution.

>  
> At least one of the problems at hand is the fact that there are two
> entities communicating, RMD and RMS.  In reality, both of them have
> different timeout values for when they need to claim resources.
> Further the problem is coupled with the fact that there is a rate of
> messages that an RMS can send messages to an RMD which may very
> likely be dictated by an application's semantics.  

>  
> This means that even if we define the IT to be a RMD specific, we
> can not escape the fact that the timeout for the RMD will affect the
> rate of messages that an RMS sends.  In order for the RMS to keep
> the sequence alive it will need to send the next message before the
> RMD timeout occurs.

>  
> We do not oppose that IT would be defined by an RMD and would live
> in the policy document via an attachment to a WSDL that will be
> owned by the endpoint.  

>  
> However, we do not think that restriction of the definition as you
> propose is a good idea. Yes, it solves a problem, however a very
> narrow problem. The problem of aligning the rate of messages that
> may be dictated by the application layer to RMS and hence the rate
> of messages that may be sent from RMS to RMD is still going to be
> subject to a timeout that is still defined within the current
> definition of timeout. This is not the timeout definition you have.

>  
> If we narrow the definition as you suggest, this does not relieve
> the fact that there are situations where RMS need to send messages
> to RMD at a rate which is > than the internal timeout of RMD. If we
> leave the general definition out of the specification, it will still
> be handled by private protocol means as the need to synchronize the
> two sides do not appear in our opinion.

>  
> Counter Proposal for 55:
>  
> Therefore, we are in favor of making the definition to apply to RMD
> only but NOT to restrict the definition as you propose. This is our
> counter proposal for issue 50.

> We also withdraw our request to provide ranges for the value of IT.
>  
> --------------
>  
> Just because that it is not specified in the spec does not make the
> information unnecessary. It just hinders interoperability.

>  
> Thanks,
>  
> --umit
>  
> Ps. As far as the heartbeat requirement is concerned, please see our
> latest and greatest proposal for i056 that I am about to send. We do
> not think that we will need a heartbeat if we were to adopt this,
> but will need to architect it if we do not. Further, we are very
> concerned that heartbeat and an unspecified IT will be the worst
> outcome of this debate.

>  
>
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Wednesday, Nov 16, 2005 3:54 PM
> To: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] Proposal for i055

>
> -1,
>
> PLEASE do NOT file such an issue. IBM would strongly oppose any
> normative or non-normative
> language in the spec that even suggested anything that was used to
> keep a sequence
> "active" when there are no application messages in the sequence to
> be sent. This smacks of heartbeats and that
> would be a REALLY BAD IDEA to pursue.
>
> IMO, InactivityTimeout is probably a bad idea with one exception,
> that is to deal with orphaned sequences.
> By this, I mean a Sequence that has been created but for which there
> have been NO messages received
> from the RMS related to that Sequence since the
> CreateSequenceResponse was sent.
>
> I think that it wll be common that there are such orphaned
> sequences. Given that the CS and CSR are
> sent unreliably, the chances that a CSR would never reach the RMS
> are not insignificant.
>
> However, for a Sequence for which there HAVE been messsges sent, it
> is unclear to me that the most appropriate
> course of action is for the RMD to automagically nuke the "inactive"
> sequences. It may be more appropriate that the
> administrator of the RMD contact the administrator of the RMS to
> find out what the problem is and whether they wish the sequence
> state to be preserved or if they are okay with terminating the
> sequence (manually) because the RMS cannot
> be recovered, etc.
>
> IMO, the traffic associated with a sequence will exhibit stochastic
> properties of frequency in most cases and setting
> an InactivityTimeout timer that is reset to a fixed value upon
> receipt of each message is problematic. I would also
> think that any attempt to have he RMS predict the timing of the next
> message is also problematic and simply
> adds to the complexity of the protocol.
>
> IMO, the only time that it would be appropriate to reclaim resources
> for "inactive" sequences is for the
> case where the RMS has suffered a catestrophic failure and cannot be
> recovered. Again, this can be
> and probably should be dealt with administratively.
>
> Proposal:
>
> Change the definition of wsrm:InactivityTimeout at line 150 in wsrmp-cd-01 to:
>
> /wsrmp:RMAssertion/wsrm:InactivityTimeout
> A parameter that specifies a period of inactivity immediately following the
> CreateSequenceResponse that the RMD will use to reclaim apparently
> orphaned Sequences. If omitted, there is no
> implied value.
>
> Note that I could also see some prose added as a Note that suggests
> that the RMD MAY reclaim
> resources for an apparently inactive sequence but that the RMD
> administrator SHOULD first seek to
> determine the root cause before doing so. (or something to that effect)
>
> 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
>
> Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 11/16/2005 01:54:42 PM:
>
> > It seems to me that it might be worthwhile to talk about various ways
> > the RMS/RMD can keep the Sequence alive when there are no new messages.
> > I'll file a new issue for this. I don't envision the spec saying
> > anything normatively, but merely mention a few ways implementors can
> > keep the Sequence alive.
> >
> > I don't have connectivity right now, but I hope the WSRMP spec does not
> > define IT in terms of *new* messages in the Sequence. If so, this might
> > be another issue.
> >
> > -Anish
> > --
> >
> >
> > Doug Davis wrote:
> > >
> > > Anish,
> > >   That was my assumption but it might need to be stated in the spec.
> > > -Doug
> > >
> > >
> > >
> > > *Anish Karmarkar <Anish.Karmarkar@oracle.com>*
> > >
> > > 11/03/2005 02:16 PM
> > >
> > >    
> > > To
> > >    Christopher B Ferris/Waltham/IBM@IBMUS
> > > cc
> > >    ws-rx@lists.oasis-open.org
> > > Subject
> > >    Re: [ws-rx] Proposal for i055
> > >
> > >
> > >    
> > >
> > >
> > >
> > >
> > >
> > >         Slightly related question, thought about implementation rather
> > > than the
> > > spec:
> > >
> > > It is possible that in a Sequence there may be periods where there isn't
> > > any activity (no new messages are being sent by the RMS), but the
> > > RMS/RMD do not want to terminate the Sequence, because there is more
> > > stuff coming down the pipe later.
> > >
> > > An obvious way to send 'keep-alive' messages is to send req-for-ack
> > > message on the RMS side and for the RMD to resend an ack. These are very
> > > small messages (with only one header). Is this what implementors are
> > > thinking off? Are there better ways?
> > >
> > > Thx.
> > >
> > > -Anish
> > > --
> > >
> > > Christopher B Ferris wrote:
> > >  >
> > >  > -1
> > >  >
> > >  > I don't see a need for the InactivityTimeout to apply to the RMS. It is
> > >  > free to discard/terminate
> > >  > a Sequence whenever it wants to do so.
> > >  > I am preparing an alternate
> > >  > resolution to i055, but
> > >  > we're still circling the wagons internally.
> > >  >
> > >  > 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
> > >  >
> > >  > "Yalcinalp, Umit" <umit.yalcinalp@sap.com> wrote on 11/02/2005
> > > 04:48:57 PM:
> > >  >
> > >  >  > Issue i055:
> > >  >  > This proposal is to resolve i055[1] based on the clarification that
> > >  >  > we propose for resolution of Issue i054 [2].
> > >  >  > We observe that although the InactivityTimeout should be specified
> > >  >  > by the RMD in the policy, it should be possible for RMS toalign its
> > >  >  > own inactivity timeout with respect to RMDs specification of the
> > >  > timeout.
> > >  >  > In this regard, we propose to modify the definition of
> > >  >  > InactivityTimeout which is currently a single value. Instead, we
> > >  >  > propose that RMD should specify the InactivityTimeout to be a range
> > >  >  > of values, with a lower and upper bound as well as a default value.
> > >  >  > We think that this change will allow RMS to be able to configure the
> > >  >  > IT to be able to send messages in an appropriate interval to the
> > >  >  > RMD, still complying with the configuration of the RMD. How this
> > >  >  > particular configuration may be addressed will be the subject of a
> > >  >  > subsequent message as it is a separate issue (i056 [3])
> > >  >  > We propose to add the following two attributes to the definition of
> > >  >  > InactivityTimeout at Line 158 [4] and move the specified value as
> > >  >  > the content value of the element as follows:
> > >  >  > Remove the lines 154-155 [4]
> > >  >  > {
> > >  >  > /wsrmp:RMAssertion/wsrm:InactivityTimeout/@Milliseconds
> > >  >  > The inactivity timeout duration, specified in milliseconds.
> > >  >  > }
> > >  >  > Replace the lines 151-153 with
> > >  >  > {/wsrmp:RMAssertion/wsrm:InactivityTimeout
> > >  >  > A parameter that specifies a period of inactivity for a Sequence. If
> > >  >  > omitted, there is no
> > >  >  > implied value. The value of the element indicates the default
> > >  >  > inactivity timeout duration in milliseconds.
> > >  >  > }
> > >  >  > Add the lines:
> > >  >  > {/wsrmp:RMAssertion/wsrm:InactivityTimeout/@minValue
> > >  >  > A parameter that specifies a minimum value of inactivity for a
> > >  >  > Sequence. If omitted, there is no
> > >  >  > implied value. This attribute is only present when the @maxValue is
> > >  > present.
> > >  >  > /wsrmp:RMAssertion/wsrm:InactivityTimeout/@maxValue
> > >  >  > A parameter that specifies a maximum value of inactivity for a
> > >  >  > Sequence. If omitted, there is no
> > >  >  > implied value.
> > >  >  > }
> > >  >  > You probably noticed that we are also pointing out a small
> > >  >  > problem/anomaly in the specification, where the values arespecified
> > >  >  > by attributes (i.e @Milliseconds attribute) instead of element
> > >  >  > content. We propose that the definition of the InactivityTimeout to
> > >  >  > be changed so that it should be using the value of the element
> > >  >  > instead of the attribute. Further, minValue and maxValue attributes
> > >  >  > are used to define a range.
> > >  >  > If the TC wishes to retain the usage of attribute values instead of
> > >  >  > element content as proposed, it may be retained along with minValue
> > >  >  > and maxValue proposal we are making. However, we really want to know
> > >  >  > the rationale for which the values are specified as attributes
> > >  >  > instead of elements contrary to the general practice used today with
> > >  > XML.
> > >  >  >
> > >  >  > Thanks.
> > >  >  > --umit
> > >  >  > [1]
> > >  > http://docs.oasis-open.org/ws-
> rx/issues/ReliableMessagingIssues.xml#i055
> > >  >  > [2]
> > >  > http://docs.oasis-open.org/ws-
> rx/issues/ReliableMessagingIssues.xml#i054
> > >  >  > [3]
> > >  > http://docs.oasis-open.org/ws-
> rx/issues/ReliableMessagingIssues.xml#i056
> > >  >  > [4] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.
> > >  >  > php/14986/wsrmp-1.1-spec-wd-01.pdf
> > >  >  >
> > >  >  > ----------------------
> > >  >  > Dr. Umit Yalcinalp
> > >  >  > Standards Architect
> > >  >  > NetWeaver Industry Standards
> > >  >  > SAP Labs, LLC
> > >  >  > umit.yalcinalp@sap.com
> > >  >  > Tel: (650) 320-3095
> > >
> >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]