[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Discussion on Duplicate elimination issue from 6/14 minutes
Here is the discussion from the 6/14 minutes, to tip off discussion. 5.3 PC25 PC25 Spec Technical Open Doug Bunting Title: Duplicate message responses Description: http://www.oasis-open.org/archives/wsrm/200406/msg00078.html Proposal: under discussion Resolution: • RE: [wsrm] clarification on Respond primitive From Jacques Durand <JDurand@us.fujitsu.com> on 14 Jun 2004 06:19:04 -0000 Title: RE: [wsrm] clarification on Respond primitive I think we need to state clearly the problem we try to solve here, as it seems to exceed the one summarized in #3: (A) Are we trying to guarantee the delivery of the response in an underlying request-response MEP, ("Respond" invocation on receiving RMP)? (or of a complete request-response transaction?) Which, as we have investigated long ago (study September 03), is not that simple and subject to severe implementation limitations, not just caching. I thought we had decided to leave it out for this release. (note that in such case, a duplicate generated by resending should be treated differently from a duplicate generated from network problem). Jacques: the discussions on the Mailing list have been about A. Doug: in this thread you have described a related, but somewhat different problem. Two ways for the receiving rmp to response can happen. The sending RMP needs to ensure the notify is not sent more than ones. Tom: we need to add text about not having the notify sent twice. Jacques: the respond and notify message flow is not subject to reliability. Doug: I was no suggesting that. There are many ways to get duplicate response. Tom: we should allow the caching solution for the duplicate response, but we should not require. Jacques: we had earlier proposed a reliable response. We cannot guarantee delivery of response. Tom: Are you concerned about the receiving RMP being allowed to send a cached response. Doug; I would prefer recommended to cache, but I have not proposed a must for the cached response. No one has suggested a three way handshake to ensure the response is received. I am hoping to allow the consumer payloads to ride on the duplicate response. I do not want to require a soap fault in this condition, which will prevent invisible reuse of cache payload. (B) Or, more modestly, are we trying to avoid some side effect of acknowledging duplicates in underlying request-response MEP, which translates into the receiving RMP sending back a response (to the duplicate) that looks like a valid message to the sending RMP (with an RM Reply, and whatever payload) but that the sending RMP must NOT pass to its Producer ("Notify")? The safest way to do allow this filtering, I believe, is for the RM Reply to tag the message ID in the RM Reply, as "duplicate" instead of ack. (That is what I was suggesting, though that is more than editorial...) Tom: are you suggesting a new reply type, acked duplicate. This would not be a fault. Jacques: this is getting into the solution space. We need to clarify the spec in this area. Tom: I am not sure we need this new reply type. We need to discuss it further. Doug: I am not entirely sure that this new indicator would solve the problem. Jacques I suggest we leave this for discussion. NOTE: messages produced by a Consumer via "Respond" could still have guaranteed delivery even if we don't solve (A). The problem lies in the underlying request-response MEP, so we don't have to tie - in our spec - the use of "Respond" with the response leg of such an MEP. Note also that if a Producer could be notified - e.g. by a subsequent Poll - that its request has been well delivered (acked) even if the response is lost, that might be quite sufficient, and allow the Producer to take appropriate action, which may vary depending on whether the request was idempotent or not. Jacques; where we bring value with WS reliability, is that an independent spontaneous poll, the sender would know whether the request was correctly delivered is valuable. If the request/response failed should not depend on whether the response is delivered. Tom: this needs to be discussed further on the list. Thx, Jacques -----Original Message----- From: Doug Bunting [mailto:Doug.Bunting@sun.com] Sent: Saturday, June 12, 2004 8:30 PM To: Jacques Durand Cc: wsrm Subject: Re: [wsrm] clarification on Respond primitive Jacques, On 11-Jun-04 14:11, Jacques Durand wrote: ... > Now, here is a position on the duplicate issue: > - The response to a duplicate - whether acknowledged or not - should never > be passed through the WS stack of the sending side. It should be caught > by the RMP > and discarded. The Producer should never be aware of it, simply because > the Producer > in the first place did not / cannot have generated this duplicate ! (it > has to originate > at RMP level, because a duplicate Submit call on an RMP will translate > into different message IDs.) > - so the question is : how can the receiving RMP "mark" this response so > that > teh sending RMP will not pass it to the Producer? This question implies an all-powerful receiving RMP that also has complete control over the underlying protocol and can assure itself that no duplicates or unequal delays will occur during message transfer. The sending RMP must be responsible for filtering duplicate RM-Replies it receives and preventing redundant Notify invocations. Such a requirement is entirely reasonable since the sending RMP already tracks message identifiers for which RM-Replies are outstanding. Unless, of course, you have reversed our abstract model's identification of the sending and receiving RMP? In the model, the receiving RMP publicizes information and "sends" RM-Replies to the sending RMP. > Jacques thanx, doug -- ---------------------------------------------------- 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]