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] NEW ISSUE: Clarification on base retransmission interval



I am a bit confused as in the first response to this issue you had mentioned
that this timeout applies to a live sequence at RMS and RMD. If so, then in
situation where an RMD is imminently going to terminate the session due to
timeout, how does the RMS send a keep alive message to keep RMD from
terminating? 

The example you give in your second response sounds like a retransmission
interval issue, RMS send messages but does not get acks back and therefore
retransmits as per the protocol. 


Vikas


-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Tuesday, July 26, 2005 4:21 PM
To: vikas@sonoasystems.com
Cc: vikas@sonoasystems.com; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] NEW ISSUE: Clarification on base retransmission
interval

It wasn't the intent that keepalive messages be sent. The intent was that 
the timeout would
apply in cases where a message was expected.

e.g. RMS repeatedly sends message(s) and receives no acknowledgements in 
the
specified interval.

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

"Vikas Deolaliker" <vikas@sonoasystems.com> wrote on 07/26/2005 07:01:48 
PM:

> 
> This helps, however, the submission says " If omitted, there is no 
implied
> value". It should ideally take on a default value or everybody will use 
a
> different timeout value. 
> 
> Another clarification required in light on this, is Do I now need to 
send
> keep alive messages to keep this InactivityTimeout value from getting 
too
> low?
> 
> I see in submission the following: 
> 
> /wsrm:RMAssertion/wsrm:InactivityTimeout/@milliseconds
> 
> Do I have to keep sending these message to keep the session alive 
longer? 
> 
> What if the underlying TCP times out? Can I hold a single RM session 
over
> multiple TCP sessions? 
> 
> Thanks 
> 
> Vikas
> 
> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Friday, July 22, 2005 12:28 PM
> To: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] NEW ISSUE: Clarification on base retransmission
> interval
> 
> Vikas,
> 
> Actually, the two parameters do not share the same or similar semantic. 
> >From the submission:
> /wsrm:RMAssertion/wsrm:InactivityTimeout
>         A parameter that specifies a period of inactivity for a 
Sequence. 
> If omitted, there is no implied value.
> 
> The purpose and intent of this parameter is possibly underspecified, The 

> intent that the authors (well, certainly
> my understanding) had is that a Sequence could be unilaterally 
terminated 
> by either the RMS or RMD should there be no
> activity against the Sequence for a period of the specified duration. 
> Thus, should no messages be received by
> the RMD for the specified wsrm:InactivityTimeout duration, it **could** 
> terminate the Sequence at its discretion. 
> (It does not need to do so). Likewise, should an RMS not receive any 
> SequenceAcknowledgements for the 
> specified  wsrm:InactivityTimeout duration, despite having attempted to 
> transmit messages during that 
> period (hence it was likely expecting them) then it could unilaterally 
> terminate the Sequence.
> 
> Of course, discretion should be used in selecting a suitable value for 
> this parameter, probably based on the
> expected frequency of activity (and adding a suitably generous margin of 

> error). However, it is not the intent
> that this parameter specify the frequency with which messages are to be 
> retransmitted by the RMS.
> 
> The intent was to provide a means by which an RMD could reclaim 
resources 
> for which it appears that 
> the corresponding RMS has "left the building", "bit the dust", "rode off 

> into the sunset" (e.g. possibly come
> to a horribly nasty and greusome end).
> 
> Mr. Praline: 'Ello, I wish to register a complaint.
> (The owner does not respond.)
> 
> Mr. Praline: 'Ello, Miss?
> 
> Owner: What do you mean "miss"?
> 
> Mr. Praline: I'm sorry, I have a cold. I wish to make a complaint!
> 
> Owner: We're closin' for lunch.
> 
> Mr. Praline: Never mind that, my lad. I wish to complain about this 
parrot 
> what I purchased not half an hour ago from this very boutique.
> 
> Owner: Oh yes, the, uh, the Norwegian Blue...What's,uh...What's wrong 
with 
> it?
> 
> Mr. Praline: I'll tell you what's wrong with it, my lad. 'E's dead, 
that's 
> what's wrong with it!
> 
> Owner: No, no, 'e's uh,...he's resting. 
> 
> Mr. Praline: Look, matey, I know a dead parrot when I see one, and I'm 
> looking at one right now.
> 
> [...]
> 
> Owner: No no! 'E's pining! 
> 
> Mr. Praline: 'E's not pinin'! 'E's passed on! This parrot is no more! He 

> has ceased to be! 'E's expired and 
> gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! 

> If you hadn't nailed 'im to the perch 'e'd 
> be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's 

> off the twig! 'E's kicked the bucket,
> 'e's shuffled off 'is mortal coil, run down the curtain and joined the 
> bleedin' choir invisibile!! THIS IS AN 
> EX-PARROT!! 
> 
> (Sorry, couldn't resist!)
> 
> 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
> 
> "Vikas Deolaliker" <vikas@sonoasystems.com> wrote on 07/22/2005 02:39:46 

> PM:
> 
> > 
> > 
> > *Title*: RM Policy Assertion Model's Base Retransmission Interval
> > Clarification Needed
> > 
> > *Description*:
> > The RM policy assertion model defines InactivityTimeout  and
> > BaseRetransmissionInterval. The text in the specification WS-RM Policy 

> (Page
> > 5) implies that these two parameters are essentially serving the same
> > purpose i.e. to trigger a retransmit based on a timeout value. If this 

> is
> > the intention, the spec needs to clarify the pecking order for an
> > implementation i.e. what if timeout occurs before base retransmission
> > interval has expired. 
> > 
> > *Justification*:
> > There is no obvious case mentioned in the spec that requires two 
timers 
> for
> > retransmission upon timeout. 
> > 
> > *Target*: (core | soap | wsdl | policy | schema | all)
> > Policy
> > 
> > *Type: *(design | editorial)
> > design
> > 
> > *Proposal*:
> > 
> > 1) Merge the two into one timer called Retransmission Timeout. 
> > 
> > *Related issues*:
> > 
> > None
> > 
> > 
> 
> 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]