Well that would imply that WS-RM maintains a correlation between the response and the original request, which just isn't the case.
RM doesn't care whether the original response was two-way or one-way, as its considers the client->server and server->client message streams as completely separate from a reliability point of view. Once the ACK for an outgoing request is received, the message is ejected from the client-side retransmission queue, as it will never need to be re-sent, seeing as it has been successfully received and acknowledged. Whether a corresponding response is ever sent or received is not considered relevant by the client-side WS-RM to the resend status of the original request. Of course if a response was sent and then not acknowledged, then the server-side WS-RM layer would cause the response to be resent. But the client-side would never resend the original request due to the lack of a response. The key point to note is that RM has no concept of an over-arching message exchange pattern such as request-response. It only guarantees delivery of sequences of *individual* messages. Cheers, Eoghan 2009/8/6 EVENO Manuel <[email protected]> > > Wouldn't it be possible to store the unsent reponse in a cache. > On a response receive timeout, the client could resent the request > and the service could send back the response without executing > the work again (the web service could assert that it is the same > initial message with the WS-Adressing messge id). > > With this problem, we think that we can use web services for create, > update, delete operation as we can't be garanteed to have a response. > The only usable operation is read. > > How do other people handle this ? > Hope it doesn't occur ? :) > > Manuel > > -----Message d'origine----- > De : Eoghan Glynn [mailto:[email protected]] > Envoyé : jeudi 6 août 2009 16:10 > À : [email protected] > Objet : Re: WS-ReliableMessaging > > 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 > > > > > >
