Re: [wsrm] Discussion on Issues Rel 108 and 115

[Tom Rutt <tom@coastin.com>]

Sunil Kunisetty wrote:

>  
>
> Tom Rutt wrote:
>
>> Sunil Kunisetty wrote:
>>
>> >
>> >  Tom,
>> >
>>
>>
>> information about the faults which casse messages not to be delivered.
>>
>> >          1. Definition of MessageOrder and DuplicateElimination has to
>> >             change (slightly) since we persist faulty messages also.
>> >             So a duplicate message is deleted only if the earlier
>> >             message was not faulted. Something similar has to be said
>> >             for Message Ordering.
>> >
>> I do not understand.  A faulted message is not delivered, and that is
>> all that matter as far as duplicate elimination is concerned.
>> A duplicate is
>>  not be delivered if the earlier message was delivrered.  The poll
>> reporting syntax has nothing to do with the definitions of
>> duplicate elimination.  Same for message ordereing, do not deliver if
>> the prior is not delivered.
>>  
>>
>  A poll as such doesn't have effect on the DE and MO, however, persisting
>  the IDs for faulty messages has an effect. So, what I meant was:
>  1) Earlier, if we are just doing duplicate elimination, a check for 
> the msg Id
>      in the persistence store was a good enough check to see a whether a
>      msg. was delivered or not. Now, that won't be enough and we also 
> need
>      to maintain the delivery status. A FaultCode could be used as an
>      indicator that a Msg. was not delivered.
>  2) For message ordering, we need to clarify the group termination and
>      status removal criteria whether the group termination parameters
>      (IdleDuration and GroupExpiryTime) on a Fault messages has
>      an effect or so.
>
>      Here is an example:
>      Msg1:  groupId=1, SeqNo=1,  groupExpiryTime 4.00 pm.
>      Msg2:  groupId=1, SeqNo=2,  groupExpiryTime 10.00 pm.
>
>      Assume Msg2 caused some fault and was not delivered, so in that case
>      what shall be the group's expiry time, 4.00 pm or 10.00 pm?
>
The group expiry time is updated as soon as a messge is received.   I 
agree We need to clarify whether it gets
updated for faulted message requests. 

If the message faulted for bad expiry time, then it should not be updated.

What about for other fault codes?


>      Earlier, it was not an issue as we were not persisting the msg2 
> and hence
>      it would be 4.00 pm in that case.
>
>     Now, we need to clarify one way or other.
>
>>  
>
>> >    1. Have to be mentioned that only non-expired message faults will
>> >       be sent back.
>> >
>> agree
>>
>> >    1. Have to be mentioned that not all non-expired faulty message's
>> >       faults can be sent back as some messages can cause fatal errors
>> >       (those that cause PermanentProcessingFailures faults).
>> >
>> If the receiving rmp can send the fault on a response or a callback, why
>> could it not send it on a poll response?
>>
>  The difference is in the Response and Callback case, the Fault will be
>  sent back immediately and hence will have an InvalidExpiryTime fault.
>
>  Because for a Poll case as we plan to say that only non-expired faults
>  (see the above bullet) will be sent back, InvalidExpiryTime faults
>  may be or may not be sent.
>
We need a uinified response for all three reply patterns.

See my other email on this topic.

>>   
>


-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133