OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Sunil:

The sending RMP will have no problem dealing with a dupicate response, 
and if it did not
receive the prior response, will include the payload in the notify 
instead of a fault (which would
be the case with 3).

In the case of the NO payload rm fault, the sending rmp will ignore it 
if it already notified the payload to the producer
from the preceeding ack, or otherwise it will send the fault on the 
notify (since it does not have a response payload).

With regards to the soap fault with rm fault, I am surprised you are 
raising this so late in the process.

Tom Rutt

Sunil Kunisetty wrote:

> Tom Rutt wrote:
>
>> I propose to allow both 1) and 3) behaviours , that is:
>>
>> 1) Sending rmp allowed to return buffered response from previous 
>> invocation with rm-acknolwedgement indication, or
>>
>> 3) define a new RM-Fault called "Response Payload Not Available for 
>> Duplicate request" which gets sent with
>> a soap fault in the case where the duplicate invoke requires  a 
>> response which is not available because of duplicate request 
>> elimination.
>>
> Sending both RM and SOAP Fault is wrong in my opinion. See the other 
> thread for the reasons.
>
> Coming to this issue, while I'm not against having 2 options in 
> principle, the concern I've here is
> interoperability. Since we don't have a corresponding RM agreement 
> item or policy negotiation
> that 2 (RMP) endpoint can decide upfront, how is it going to be 
> interoperable as the behavior
> is subject to change between 2 different Receiving RMP endpoints.
>
>
>> Tom Rutt
>>
>>
>>
>> Sunil Kunisetty wrote:
>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. 
>
>

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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]