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



Umit,

Please see my comments below.

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/17/2005 02:33:46 PM:

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


I don't understand why it is that you believe that it is necessary
for the RMS and RMD to coordinate on the rate of message transmission
in this manner. It seems that you are assuming a short-lived Sequence
possibly?

The proposal I offered was to eliminate the need of a specified InactivityTimeout
that was based on the rate of message exchanges, in either direction.
Frankly, I don't see the need for this. every application will be different.
One that is driven by virtue of human activity at one end, manually inputting
transactions, will exhibit stocastic behavior at best. In many cases there can be no
possible way to calculate a predetermined frequency of the application
messages belonging to a Sequence.

I am also not in favor of any automated mechanism that reclaims resources
associated with an allegedly defunct Sequence based on the lack of receipt
of messages for that Sequence. There are simply too many things that could
go wrong that would create more problems than the proposed InactivityTimeout
is supposedly intended to solve.

Consider the case where some smart-alecky developer were to set the
InactivityTimeout based upon his expectations of the message traffic, even
assigning a suitable padding to accommodate poor performance characteristics
of the system. All seems to go well when things are running along smoothly
and then s/he suffers a hardware related system crash. S/he promptly calls
in the hardware dudes to replace the failed component, but they are busy
with another problem in another department and can't get there until the
next day.

Oops... time's up... the IT expires and now all of the Sequences for that
application are automagically nuked by the respective RMDs. When s/he
is finally able to bring the system back up, s/he finds that all of the
active Sequences are gone and there is no way to tell, beyond the last
set of acks received, what the state of the corresponding RMDs was.

Not good.

The RM protocol is supposed to be able to deal with just such a situation
and now you would have as a formal part of that protocol something which
actively works against it?

When I made my counter proposal, I did away with the IT as a function
of the expected frequency of message transmission and focused in on
an area that is much more likely to require attention... that of orphaned
Sequences resulting from lost CreateSequenceResponse messages.

As for what happens after a Sequence is started, and messages have been
successfully transmitted and/or acknowledged, that should be left to
non-automated administration. Inactivity should be a function of weeks
or months, not seconds and certainly not a function of the frequency
of message transmission. Afterall, we are trying to improve the reliability
of systems in the face of inevitable failure such as I described above.

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


I disagree that the problem that my proposal addresses is narrow. I think
it will be far more commonplace than that of either an RMS or RMD
going for a permanent dirt nap.

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


I think that it is important to keep a separation of concerns in place
between the RM layer and application semantics.

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


Not if that rate is a function of weeks or months, and not if there
is no automated reclamation of resources.

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