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


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 to align 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 are specified
> >  >  > 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]