[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
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 I meant the behavour to apply to Receiving RMP for 1) above, as well as for 3) below > > 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]