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