Sunil Kunisetty wrote:
> My proposal would be:
>
> 0) Have MaxMessageExpiryTimeout and MaxGroupExpiryTimeout as RM
> agreement parameters. The latter should be greater r atleast equal to
> the
> former.
>
> 1) Have DefaultMessageExpiryTimeout and DefaultGroupExpiryTimeout as RM
> agreement parameters. The latter should be greater r atleast equal to
> the
> former.
>
> DefaultMessageExpiryTimeout should be less than or equal to
> MaxMessageExpiryTimeout.
> DefaultGroupExpiryTimeout should be less than or equal to
> MaxGroupExpiryTimeout.
>
> 2) Make ExpiryTimeout sub-element and removeAfter attribute be made
> optional.
>
> 3) If ExpiryTimeout doesn't exist on the message, the message has a
> DefaultMessageExpiryTimeout
> value. If it does exist, it should be less than MaxMessageExpiryTimeout,
> if not, fault is
> thrown.
>
> 4) If removeAfter doesn't exist on the message, the message has a
> DefaultGroupExpiryTimeout
> value. If it does exist, it should be less than MaxGroupExpiryTimeout,
> if not, fault is
> thrown.
>
> 5) For grouped messages, if subsequent messages have removeAfter, we could
> say one
> of the following:
> a) The latest one takes precedence
> b) If the values are different, throw a fault
> c) ignore subsequent ones
>
> I'm okay with (a) or (b), but not (c)
>
> 6) For the grouped messages (ordered or un-ordered), a message's ExpiryTime
> (one sent on the wire or the default value) shouldn't exceed the
> group's ExpiryTime
> (one sent or the defaulted one). If not, fault is thrown.
>
> 7) For a grouped messages, the group information (Group & SequenceNumber)
> information
> is removed from the RMP's persistence cache if the last message is
> signaled (Status END)
> or the Group's time (the one sent or the defaulted one) expires.
>
> 8) For singleton messages, removeAfter is not recommended, if exists,
> should be more
> than the message time. For singleton messages, the message information
> is
> stripped from the RMP's persistence case once the message expires (one
> sent or the defaulted one).
>
> 9) DuplicateElimination & Persistence definition should be re-worded
> accordingly.
>
> -Sunil
