OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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

Subject: RE: [wsrm] Do we really need GroupMaxIdleTime?

Title: RE: [wsrm] Do we really need GroupMaxIdleTime?

I have tried to address this in the proposal I am about to send...

But I have a problem with giving ExpiryTime any kind of group termination semantics,
as that was not its intent, and this overloading can be confusing.
Plus, the latest refinement proposed at f-2-f for ExpiryTime semantics, which I
like,  really gives it no use after message is received:
- ExpiryTime only indicates the latest date at which an RMP can accept a message.
Once a message is accepted, an "expiring ExpiryTime" has no further meaning or effect on
final outcome.
(the fact it helps to optimize duplicate checks is incidental).

For open-ended groups with neither groupExpiryTime  nor GroupMaxIdleDuration - if we keep
allowing this - I would simply not try to "logically" terminate the group.
Note that a forever-lasting group is not a problem, provided
there is no need to hold infinite out-of-order sequences, (see my proposal for this soon..)
as the memory-size of the state of the group does not increase with the group size.
What may become a memory problem is when too many groups are active.
But here, I'd think implementations must rely on impl-specific safeguards instead, e.g. config.
 (such limits need be enforced anyway in other cases due to memory / resource hard limits).

I still like GroupMaxIdleDuration , which still does not appear to me to cause problem...


-----Original Message-----
From: Tom Rutt [mailto:tom@coastin.com]
Sent: Friday, October 31, 2003 8:10 PM
To: wsrm
Subject: [wsrm] Do we really need GroupMaxIdleTime?

I had a thought.

If we allow open ended groups with the latest expiry time (asssuming a
monotonic increasing sequence of message expiry times for the group)
serving as the effective groupExpiryTime (as
I have previously proposed),  there might not be a need for the
groupMaxIdleTime parameter.

If a sender wants to trigger the group termination from a max idle
condition, it can start sending its mesages with an expiry time far
enough into the future to be greater than the current time plus the
desired GroupMaxIdleDuration value.   The behaviour of the receiver rmp
will be the same as if there were a GroupMaxIdleDuration.

Also, I question whether there are any use cases for using both a
GroupExpiryTime and a GroupMaxIdleDuration parameter in the same group

Perhaps we can get rid of the GroupMaxIdleDuration element althogether!

Tom Rutt

Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.

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