cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Postponing or blocking message delivery from interceptor
Date Fri, 21 Jan 2011 18:27:07 GMT
On Thursday 20 January 2011 5:51:27 pm Dennis Sosnoski wrote:
> On 01/21/2011 10:57 AM, Daniel Kulp wrote:
> > On Thursday 20 January 2011 2:49:53 am Dennis Sosnoski wrote:
> > 
> > ..................
> > 
> >> The WS-RM code does implement duplicate message checks if AtMostOnce is
> >> specified (in org.apache.cxf.ws.rm.DestinationSequence), in which case
> >> it throws an exception that goes all the way up the call stack to
> >> PhaseInterceptorChain. I'd think that would result in a Fault response
> >> to the client when using two-way calls, though - so it really needs to
> >> be handled using the above type of approach instead, right?
> > 
> > Isn't that correct though?  Looking at  the RM 1.1 spec section 3.2.2 on
> > duplicate elimination, it says:
> > ------------------------------
> > When the Response RM-Reply Pattern is requested with Duplicate
> > Elimination for a Reliable Message, the Receiving RMP cannot deliver
> > that message to the Consumer again (because it is a duplicate of a
> > previously delivered message), and a Consumer response payload is
> > expected, the response of the SOAP MEP instance MUST contain one (but
> > not both) of the following:
> > • a copy of the original response payload returned for that Message (in
> > the SOAP Body) in addition to the Acknowledgment Indication (in the SOAP
> > Header)
> > 
> >  or
> > 
> > • a SOAP server Fault (in the SOAP Body) in addition to the
> > Acknowledgment Indication (in the SOAP Header). The Sending RMP and
> > Producer expect either a complete response or a SOAP Fault when using
> > the Response RM-Reply Pattern; these two allowed behaviors satisfy that
> > expectation.
> > ----------------------------------
> > 
> > Since we don't save the response to the original request, the second
> > option of the fault is, I think,  the  only option.    Right?   (this
> > could be a 1.1 change though.  I don't have the 1.0 spec handy right
> > now0
> 
> It looks like you're getting that from the WS-Reliability 1.1 spec,
> rather than WS-RM 1.1
> (http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01-e1.html).
> WS-RM doesn't appear to say anything about responses to duplicates. 

DOH!

Yep.  Wrong ws* PDF file.  

 
> My own feeling is that responses should be cached and resent in response
> to duplicate request messages - otherwise, WS-RM is pretty much useless
> for request-response flows - but that does add potentially a lot of
> overhead since all responses would need to be held until the sequence
> was closed.  :-( Let me see what Metro does in this case, and also check
> with one of the WS-RM people to see why they didn't address it in the
> spec. It seems like it would have made sense to include response
> acknowledgments to handle this case.

Let us know what you find out.  If there is an issue, definitel log a bug.  
And a patch.    :-)

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message