[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Rel 56: another cut
A shot at Rel 56, attached.
I started from the material from Alan W., have only added two to those well defined
(so 6 parameters total are described), and left many TBD as is.
But I felt that each parameter needed a careful investigation, and its semantics refined (and sometimes modified).
So don't be afraid of the size of the doc attached...
I must add, its not yet clear that we can easily separate implementation configuration
from RM policy or agreement between two RMPs:
The parameters below make as much "application-level sense" as high-level
RM policies such as guaranteed delivery, or duplicate elimination.
Some parameters are obvious attributes of RM policies (e.g. retry interval, maximum retries)
some others focus on an optimal management of the persistence function.
In all cases, message management rules (and their parameters) have some meaning
for applications and need to be set based on application requirements.
Regards,
Jacques Durand
<<parameters-Rel56.txt>>
Rel 56: ---------------------------------------------- 1. Maximum message lifetime/duration (determines upper bound on message expiration time) (frm date it is sent?) SUMMARY: Set an expiration time for any message, when no TimeToLive was set. (PREVENT INDEFINITE/ NEVER ENDING MESSAGE EXPIRATION) REQUIREMENT: There are two issues with messages for which TimeToLive has not been set, in terms of persistence handling: (1) on receiver side, messages may persist a long time in the receiver store if "unclaimed" by the application, or application unavailable (e.g shutdown). (2) on the sender side, message removal is normally controlled by the Ack and resend mechanism. However, e.g. in some cases of long shutdown, messages do be [re]sent should be considered as too old and not be processed anymore, to free resources for new messages. In both cases, an RMP needs input to decide when it is time to discard an "old" message from the store, and to notify the loss. PARAMETER: MessageMaxPersist MODE: mandatory SENDER HANDLING: remove from store all messages as specified in spec 2.2.3, or else if no TimeToLive specified, with (sending date + MessageMaxPersist) > currdate. RECEIVER HANDLING: remove from store all messages with either: TimeToLive > currdate, or if no TimeToLive specified, with (sending date + MessageMaxPersist) > currdate. SCOPE: apply to all received and sent messages. COMMENT: - this parameter is mostly meaningful for message store management, and is common to messages for all connections Sender-Receiver. Is equivalent to a "default" TimeToLive, except that it does not rely on setting a default TimeToLive in messages (which requires all Senders to do so and cannot be controlled by a Receiver). - as only applies when TimeToLive is not set, will be override by TimeToLive. RELATED POLICY ISSUES: Need to decide (need a config param for this?): - in case of persistence failure (no more room in store), either new messages should be bounced, or older messages be flushed. ---------------------------------------------- 2. Maximum message group (or message sequence) lifetime SUMMARY: Provides criterion for removing group data from RMP store (PREVENT INDEFINITE/ NEVER ENDING MESSAGE SEQUENCE EXPIRATION) REQUIREMENT: Sequence of messages (identified by GroupId) may be started, yet not ended. In case no message is sent with @status="end" or if @removeAfter is never set, many sequences may remain indefinitely open, tying up system resources. In such case, we can either (a) set an overall max duration for all sequences, or (b) set the max elapsed time between two messages of a sequence, so that when a sequence is "inactive" beyond this time, it will be assumed it has ended. Because it is sometimes hard to estimate the max length of some sequences (some may be very long, or even never ending by nature, e.g. a monitoring flow), we'll use a parameter for (b) which seems also more intuitive. PARAMETER: GroupMaxIdle MODE: mandatory SENDER HANDLING: tracks for each group the elapsed time since last sending for the group. Remove the group data if elapsed time > GroupMaxIdle. RECEIVER HANDLING: tracks for each group the elapsed time since sending date of last message received for this group. Remove the group data if elapsed time > GroupMaxIdle. If some unordered messages of this group were still awaiting to be passed to the receiver app, then pass them, and send error notice for the missing ones. SCOPE: apply to all groups of all connections (sender/receiver) COMMENT: - If one wants this to apply only when "removeAfter" has not been specified, then Spec 3.3.1 should not consider "removeAfter" default = forever. If we consider the default is "forever", then this idle time limit policy should apply also to any group, which may be brutal, as cannot be override. ---------------------------------------------- 3. Resend interval (SEE REL 47) SUMMARY: defines the elapsed time before resending a non-acknowledged message. REQUIREMENT: When guaranteed delivery is required, need to set the time to wait for an Ack before resending the message. Assume this is specific to each Sender/Receiver connection. PARAMETER: RetryInterval MODE: mandatory when guaranteed delivery is requested. SENDER HANDLING: used to schedule the resending: minimum elapsed time before resend. RECEIVER HANDLING: none. SCOPE: apply to all messages of a connection (sender/receiver) COMMENT: - could be used as a base-interval if a more complex interval algorithm is used later. - it is important to define the scope: if specific to a connection Sender/Receiver, an RMP will have to manage a parameter for each connection, vs. just one for all connections. ---------------------------------------------- 4. Retransmission count (SEE REL 47) SUMMARY: define the max numer of resent non-acknowledged messages, before generating a delivery failure. REQUIREMENT: When guaranteed delivery is required, need to set the max number of times a message will be resent if not acknowledged (from 0 to N), so that a repeated failure to send will not tie up processing and storage resources in the Sender, and will be notified to sender application in a timely manner. Assume this is specific to each Sender/Receiver connection. PARAMETER: RetryMaxNumber MODE: mandatory when guaranteed delivery is requested. SENDER HANDLING: Used to limit the total number of message resend. RECEIVER HANDLING: none. SCOPE: apply to all messages of a connection (sender/receiver) COMMENT: - it is important to define the scope: if specific to a connection Sender/Receiver, an RMP will have to manage a parameter for each connection, vs. just one for all connections. ---------------------------------------------- 5. Duplicate search scope (minimum number of past messages to look-up) SUMMARY: Defines minimum size of set of past messages to be considered for a duplicate search. REQUIREMENT: Duplicate search cannot be guaranteed over all previously received messages. It is necessary to clarify the limits of the duplicate search, either in number of past message IDs to look-up, or in terms of past date. The trade-off scope of search / preformance can also be adjusted and prevent doing exhaustive expensive duplicate search over large logs of non-relevant message IDs. PARAMETER: DuplicateSearchSetLimit, DuplicateSearchTimeLimit MODE: Mandatory if duplicate elimination required. SENDER HANDLING: none. RECEIVER HANDLING: will limit (but guarantee) the search of duplicate over a number of past message IDs equal to DuplicateSearchSetLimit, or over the past messages until the date defined by (current date - DuplicateSearchTimeLimit). SCOPE: apply to all messages of a connection (sender/receiver) for which a duplicate elimination is required. COMMENT: - in case both parameters are also specified, the search is limited by whichever defines the larger set. - it is important to define the scope: if specific to a connection Sender/Receiver, an RMP will have to manage a parameter for each connection, vs. just one for all connections. ---------------------------------------------- 6. Unordered messages window size (max number of messages to hold) SUMMARY: Defines max size of set of unordered received messages, before taking action (notify, pass messages to application) REQUIREMENT: If a message is missing in a received sequence, the Receiver may have to store a very large number of messages, and delay their passing to the application in a damaging way (a messages may loose value way before reaching its TimeToLive). Relying on the store capacity to decide of the size of this window is crude: space resource may not be well allocated between several broken sequences. PARAMETER: UnorderedWindowSize MODE: mandatory if Ordering required. SENDER HANDLING: none. RECEIVER HANDLING: When the unordered section of a particular sequence exceeds UnorderedWindowSize, Receiver will notify of the unreceived messages, and pass all pending messages to the application. SCOPE: apply to all messages of a sequence / GroupId. COMMENT: - should the "reduction" of an unordered sequence be alterantively controlled by a time-based limit? RELATED POLICY ISSUES: - Behavior of Receiver after a broken sequence has been reduced by reaching window size, is TBD: keep ordering the rest? give up? ---------------------------------------------- RMP-specific resource capabilities: (TBD) ---------------------------------------------- These parameters are not reflecting an RM agreement, like the previous ones. Rather, they define the "profile" of an RMP, in terms of: - persistence capability (may include also some tuning info such as MessageMaxSize, MessageAvgSize) - types of MEPs supported - WS-RM spec options supported (e.g. sync/async) - alternative transport bindings supported (besides HTTP), ---------------------------------------------- RMP-specific behaviors: (TBD) ---------------------------------------------- - recovery actions to be taken on failure and/or failure recovery (power outage, no-ack count expired, crash tolerance, etc). - level of failure notification. ---------------------------------------------- General RM agreement parameters: (?) ---------------------------------------------- These parameters would represent the RM agreement, and would be interpreted by both Sender and Receiver RMPs. Could be override by header data: - Duplicate elimination - Guaranteed delivery - Message Ordering
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]