[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
A final acknowledgement status could be sent back that reflects the = exact state at termination time. That could be done by sending (or by = making available for polling even after the sequence is terminated) a = last SequenceAcknowledgement element, at the time the RM Destination = terminates the sequence (either at reception of TerminateSequence, or = due to timeout). Such a SequenceAcknowledgement element should have a = "last" marker.=20 proposed-02=20 better support in handling space-greedy sequences=20 core - design - unassigned =20 Description=20 In case an RM destination expects a large number of concurrent = sequences, it may find itself in a position where maintaining the state = of existing sequences takes too much resources. As a consequence, = existing sequences may need to be terminated by the RM Destination, or = new CreateSequence requests may be turned down, and denial of service = occurs. COnsider a rate of message loss (and not RM-recovered) of about = one for each million in average, over a sequence 1 trillion long (about = 18,000, 000 times smaller than allowed maximum). Representing the state = of such a sequence would require 1M intervals, with about 12 bytes to = code an interval of (long) integers (long starting number + length on = 4bytes) about 12Mb is used for the sequence state. For am RM Destination = with tens of thousands of concurrent long-lasting sequences, it means = that potentially terabytes of persistent space will be needed to store = the state of these sequences. Also, the SequenceAcknowledgement element = for such sequences may become extremely bulky (with such a rate loss = above, could reach several Gb once the sequence gets big.)=20 Justification=20 Space needs over time for sequences states is something unpredictable = but manageable, (somehow like cache management). If one wants to ensure = the scalability of the RM mechanism, such dynamic policies as:=20 * (1) deciding to arbitrarily end some existing sequence (e.g. = LFU)=20 * (2) dynamically adjust the maximum sequence length of new = sequences at creation time=20 should be supported (though their specification should remain out of = scope). For example, in many cases it is preferable to preventively = limit the size of requested new sequences, and to decide that below a = threshold of available memory, the maximum length of new sequences would = get smaller. The RM specification is currently not open to such = policies, mandating a fixed maximum to all sequences created regardless = of resource status.=20 Origin=20 Jacques Durand = <http://lists.oasis-open.org/archives/ws-rx/200508/msg00061.html> =20 Owner=20 Jacques Durand = <file:///\\cpzaw-pro-05\mydocs4\mgoodner\Visual%20Studio%202005\Projects\= WS-RM%20Issues\IssueList\JDurand@us.fujitsu.com> =20 Proposal 12005-08-09=20
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]