Re: [wsrm] Discussion on Duplicate elimination issue from 6/14 minutes

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

Tom Rutt wrote:

> I have one question inserted below.
>
> Tom Rutt
>
> Sunil Kunisetty wrote:
>
>> Here is the mail I sent on Duplicate Elimination a week ago.
>> It has the summary, possible solutions and my preferred solution.
>>
>> ----------------------------------------------------------------------------------------------------- 
>>
>> I'd like to summarize the options of using Duplicate Elimination for a
>> Request-Response MEP.
>>
>> 1) Cache the message until the original request expires and Send the
>>    "payload  response" for every subsequent request.
>> 2)  Send an empty SOAP envelope.
>>      (Note that when there is no AckRequested, there won't be any Ack 
>> and
>>      hence the SOAP envelope will have empty Header/body).
>> 3)  Send a signal that it is a "Duplicate Message".
>> 4)  Spec. says that this is combination is not supported.
>>
>> While I personally like (4),  we can't do it as the TC voted to support
>> this combination.
>>
>> I'm very un-comfortable with (2) as it will cause all kinds of issues 
>> and
>> as such it is meaningless/un-informative to send "empty signal".
>>
>> As per (1), while it is theoritcally reasonable and easy to implement,
>> it is impractical from a product/solution perspective.
>>
>> Here are few reasons:
>> (i) Potentially can throttle the server with memory being sucked up.
>>    Generally speaking, expire time is used optimistically and will 
>> have a
>>    large life span. Caching responses that long is not too good .
>> (ii) I believe this thing (async. responses) is beyond the scope
>>    of this specification and should be handled  in the "OASIS 
>> Asynchronous
>>    Service Access  Protocol TC"  [1]
>> (iii) There are many subtle things about caching responses:
>>         - there should be mechanism to invalidate the cache
>>         - what if the request has time sensitive information. for ex.,
>>           if I ask for getStockQuote for Oracle with a duration of 
>> say 1 hr...
>>           Assume the first  message is lost.
>>           Say the RMP resent the same message after 10 mins... they may
>>           get a stock quote that was 10 mins. ago.
>>           So if time sensitive data exists, there should be mechanism
>>           for data resync..
>>
>> So for these reasons, I just like a RM signal [3] solution so that
>> the application can resend the request.
>>  
>>
> The situation that causes the most trouble is when the response had 
> been previously sent, so the responder RMP
> has no response payload to return since it did not invoke the second 
> deliver. Thus the sender resending will
> not help all all.
>
> The reason to give an indication is so the sender will not continue to 
> resend the duplicate, in cases where the original

 Right. That's why I said I like to send a RM signal so that the Sender 
can either resend the Message
 with a different MessageId or query as you suggested.

 Option 2 (sending an empty SOAP envelope) is the wrong thing to do.


> response is lost. However an indication will let the sender know it 
> SHOULD NOT resend the duplicate. Instead, it
> could invoke other operations to query the server state (eg, get the 
> current ballance of the account to see if the
> first invoke actually happened.