Re: [ws-rx] Proposal for i055

[Christopher B Ferris <chrisfer@us.ibm.com>]

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