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 > > >
