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 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 > 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 [email protected] http://dankulp.com/blog
