Yes, the source and destination roles are reversed for the response. That's really what I meant when I talked about WS-RM treating "the request message stream and response message stream as being entirely separate from a reliability point of view".
So an unacknowledged response would be resent, just like an unacknowledged request. However whether this resent response is delivered to the client-side application will depend on how and where the timeout fired, and whether this led to a timeout exception being propagated to the application layer. Remember that WS-RM is all about resending lost messages, not about recovering from failures exposed to the application layer. Cheers, Eoghan 2009/8/6 EVENO Manuel <[email protected]> > > I was aware of that but I was thinking that the same mecanism > would apply for the web service while sending back the response ... > > In that case (for the response), the RM Source is the webservice > and the RM Destination is the client, we should have some kind > of retry mecanism until the reponse have been received ? > > So there's no way to handle this timeout case properly and > the response lost case more widely ? > > Manuel > > -----Message d'origine----- > De : Eoghan Glynn [mailto:[email protected]] > Envoyé : mercredi 5 août 2009 18:32 > À : [email protected] > Objet : Re: WS-ReliableMessaging > > 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 > > >
