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: "wsrx" <ws-rx@lists.oasis-open.org>
- Date: Thu, 17 Nov 2005 15:57:03 -0500
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]