the timeless RM proposal...

[Jacques Durand <JDurand@fsw.fujitsu.com>]

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