the timeless RM proposal...

Title: the timeless RM proposal...

OK, here is the ground-breaking, earth-shaking alternative in dealing with all time-related issues,

as suggested by Fujitsu engineers and Iwasa, and discussed today. I developed on the "rationale" side, see below:

- get rid of ExpiryTime (messages)

- get rid of  GroupExpiryTime 

- get rid of MaxGroupIdleTime

(NOTE: in case we decide to NOT  get rid of them, I would still propose the last summary draft I sent Sunday

as the most accomplished way -as of today- for handling group/message states, and time issues.

But i'll make myself the devil's advocate here...)

The rationale is two-fold:

1- these values have no business meaning whatsoever, their only use, is to serve as 

criteria for better managing memory, as well as reduce the overhead of operations that depend

on group/message state size in memory, like dup check. 

For example, ExpiryTime is the latest time at which a message can be accepted by the RMP - not delivered

to app. Make this value infinite, the logical outcome will be the same. Only, we'll keep around past message IDs

longer in memory, and dup check may be slower at least for singletons. Make ExpiryTime  shorter, and you'll get

more messages bounced because they expire before reaching the RMP. Faults would be generated. 

But again that is a purely arbitrary decision. 

So we are really dealing here with a resource management issue,

NOT a reliability QoS  that makes sense at application level.

These values are really about "tuning" the communication and space management of RMP, like deciding where to put

an index in a database, or what is the size of a rollback segment. 

This level can be seen as RMP implementation management or tuning, which itself

could be standardized and subject to a reliability or QoS contract, but that is another level of reliability.

2- By getting rid of these explicit resource management parameters in the protocol, 

the burden of keeping group/message state overhead within reasonable limits,  is on the RMP implementation config. 

For exemple, if an exception is generated for lack of disk space, depending on RMP config, new messages can be 

bounced and faulted, or past message/group states can be flushed, e.g. LRU... or singletons flushed first...etc..

That may be more brutal, BUT even when using above time parameters, an RMP is not immune to such hard limits,

and to dealing with them, .as (1) users may abuse these time values (making them very large), to get higher QoS

at the expense of others, or for denial of service attacks on RMP... and (2) simply because time-based paraemeters are 

not suitable to deal with sudden burst of traffic, which will clog the memory until all these states expire.

So since we CANNOT anyway guarantee a behavior according to time parameters, and have to deal anyway with

resource abuses, why not make this exclusively an implementation-level resource mgmt issue.

Whatever we decide, it appears we'll have to plan for "resource faults"...

Note also that this does not put in question the use of non-ordered groups : on the contrary, they become more precious

to reduce space overhead and dup check time (the space-greedy singletons ARE the problem in fact...)

Jacques