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

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

I see in submission the following:  


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? 



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


Actually, the two parameters do not share the same or similar semantic. 
>From the submission:
        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 

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 

(Sorry, couldn't resist!)


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 

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