[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
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. 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. > > > -- ---------------------------------------------------- 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]