ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] Proposal for i055
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: "Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>
- Date: Thu, 17 Nov 2005 16:07:17 -0500
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]