Manuel, It all depends on _where_ in the dispatch path the failure is likely to occur.
Note that the purpose of WS-RM is to guarantee delivery of message from an RM source to an RM destination. Once the message reaches the RM destination and has been acknowledged, then its work is done. Now in CXF terms, the RM destination is effectively an interceptor plus some additional infrastructure in the receiver-side in-interceptor chain. So if a failure occurs subsequent to this being traversed, then the sender-side WS-RM layer won't trigger a resend of the original message. For example, if the timeout fires *after* the request has been received & ACKed by the server-side RM destination but before the implementor method completes, then the client-side RM layer will not resend the message. As far as its concerned, the message has been received so there is no need for a retransmission. For context, see the diagram on page 7 of the WS-RM spec[1]. The CXF WS-RM implementation considers the request to have been delivered to the application destination once its passed onto the next interceptor in the receiver-side chain, NOT after it has been delivered to and fully processed by the target implementor object (as you may be assuming). Also note that WS-RM doesn't have an over-arching concept of a twoway message exchange pattern - instead it treats the request message stream and response message stream as being entirely separate from a reliability point of view. Cheers, Eoghan [1] http://specs.xmlsoap.org/ws/2005/02/rm/ws-reliablemessaging.pdf 2009/8/4 EVENO Manuel <[email protected]> > > Hi Eoghan, > > I'll try to expose the problem I want to solve here : > As WebService are not transactional, so in classic web services > there's a problem when the response is sent back to the client > but is lost or commes after the receive timeout. > The client in that case, receives a timeout but don't really know > if the message has been received by the web service, has been executed > with success or error and don't really know how to handle this : > If the web service has already done the job and the client tries resending > the message, > duplicates can occurs (on create action for example). > If the client don't send the message again, then nothing happens nor the > problem nor the job to be done ;) > > So that's where I though of WS-ReliableMessaging. > I was hopping it could solve my lost response problem. > > My point is the read timeout was excepted and and I wanted to see how thing > were handled by CXF and WS-RM. > > Sorry for the allowDuplicates="false", I didn't seen it, it's a copy/paste > from an example ont the ne :) > I've removed it but the "duplicate message id" error still occurs. > After debugging, it seems that the allowDuplicates boolean in > org.apache.cxf.ws.addressing.MAPAggregator > still having a false value ... > > For the chunking thingy, I've programatically configured the chunking to > false in my client but the problem persists ... > > Maybe I'm wrong and WS-RM can solve this ... > > Thanks for your time > Manuel > PS : I've attached my project with the new configuration (chunking and > allowDuplicates) > > -----Message d'origine----- > De : Eoghan Glynn [mailto:[email protected]] > Envoyé : mardi 4 août 2009 11:07 > À : [email protected] > Objet : Re: WS-ReliableMessaging > > Hi Manuel, > > If its a timeout that's causing the request to the fail, surely a better > solution would be to increase the timeout expiry period, rather than causing > the request to be re-sent (possibly triggering the timeout a second time)? > > > [server side] java.net.HttpRetryException: cannot retry due to server > > authentication, in streaming mode > > To avoid this issue, you'll need to disable chunking, using something like > the emboldened sections in the following client-side config: > > <beans xmlns="http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > *xmlns:http-conf=" > http://cxf.apache.org/transports/http/configuration"; > * xsi:schemaLocation="* > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd > *http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd";> > > * <http-conf:conduit name="*.http-conduit"> > <http-conf:client AllowChunking="false" /> > </http-conf:conduit> * > </beans> > > > [server side] org.apache.cxf.binding.soap.SoapFault: Duplicate Message > > ID urn:uuid:49f2fe2b-e2d5-4fec-8b4d-df8987bf829a > > This error is caused by the server-side WS-Addressing layer rejecting the > resent message due to the duplicate message ID. > > Now you can explicitly configure the WSAddressingFeature to allow > duplicates as follows: > > <wsa:addressing allowDuplicates="true"/> > > but this has actually been the default behaviour for quite some time. > You're overriding the default behaviour in > src/main/resources/cxf-services.xml with the following setting: > > <wsa:addressing allowDuplicates="false" /> > > So you'll need to remove that allowDuplicates attribute. > > Cheers, > Eoghan > > 2009/8/3 EVENO Manuel <[email protected]>: > > > > Hi everyone, > > > > I'm trying to create an sample with CXF and WS-ReliableMessaging. > > I'm specifically interested in the delivery assurance functionality. > > I'm trying to implement a AtLeastOnce message exchange but with no > success. > > > > My use case is a client calls a service but that service takes a long > > time to execute so the client side request ends with a timeout. In > > that case, I want the message to be sent again. > > > > I've already tried to add some policy rule in my wsdl but I don't > > really understand how to write this part (I've also tried to read W3C > > and OASIS > specifications > > but > > everything is not that simple and clear. > > > > So I'm trying to use CXF WS-Policy Framework but I don't really > > understand what's going on. > > Various exceptions occurs in my log and I don't know how to solve them : > > [server side] java.net.HttpRetryException: cannot retry due to server > > authentication, in streaming mode [server side] > > org.apache.cxf.binding.soap.SoapFault: Duplicate Message ID > > urn:uuid:49f2fe2b-e2d5-4fec-8b4d-df8987bf829a > > > > Here my reduced maven project, including the WebService that can be > > run > with > > Tomcat or jetty > > And a web service client implemented as a JUnit Test. > > <<reliable-webservice.zip>> <<server.log>> <<client.log>> > > > > If anybody has time to have a look or a sample (of delivery assurance > > feature), this would be very helpful ! > > > > Regards, > > Manuel >
