cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Postponing or blocking message delivery from interceptor
Date Thu, 20 Jan 2011 21:57:12 GMT
On Thursday 20 January 2011 2:49:53 am Dennis Sosnoski wrote:
> On 01/20/2011 08:19 AM, Daniel Kulp wrote:
> > On Wednesday 19 January 2011 5:24:58 am Dennis Sosnoski wrote:
> >> ...
> >> 
> >> In order to implement the receive handling, I need to be able to
> >> short-circuit the processing of an in-bound message in an interceptor so
> >> that no further processing is done at this time but the appropriate
> >> transport response goes back to the sender (such as an HTTP 200 code).
> > 
> > Take a look at the OneWayInInterceptor for this.   Basically, it calls
> > back into the destination with basically and empty message to notify the
> > destination that we're "done" with this.
> Do you mean org.apache.cxf.interceptor.OneWayProcessorInterceptor? 

Yea.  That's it.  :-)

> The WS-RM code does implement duplicate message checks if AtMostOnce is
> specified (in, 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)


• 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
> Incidentally, the DestinationSequence code logs a duplicate message at
> SEVERE level. Shouldn't this really be INFO level, for an event which is
> interesting but not really any kind of error?

Likely yes.

Daniel Kulp

View raw message