[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 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]