You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by EVENO Manuel <ME...@generali.fr> on 2009/08/03 14:21:36 UTC
WS-ReliableMessaging
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
RE: WS-ReliableMessaging
Posted by EVENO Manuel <ME...@generali.fr>.
And how about in a zipped file .... ?
________________________________
De : EVENO Manuel [mailto:MEVENO@generali.fr]
Envoyé : lundi 3 août 2009 14:24
À : users@cxf.apache.org
Objet : RE: WS-ReliableMessaging
Here the log files again which seems to have been filtered ...
________________________________
De : EVENO Manuel
Envoyé : lundi 3 août 2009 14:22
À : users@cxf.apache.org
Objet : WS-ReliableMessaging
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
RE: WS-ReliableMessaging
Posted by EVENO Manuel <ME...@generali.fr>.
Here the log files again which seems to have been filtered ...
________________________________
De : EVENO Manuel
Envoyé : lundi 3 août 2009 14:22
À : users@cxf.apache.org
Objet : WS-ReliableMessaging
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
RE: WS-ReliableMessaging
Posted by EVENO Manuel <ME...@generali.fr>.
Ok thanks for the clear explanation.
I'll have a look at callbacks and decoupled endpoints ...
Regards,
Manuel
-----Message d'origine-----
De : Eoghan Glynn [mailto:eoglynn@gmail.com]
Envoyé : vendredi 7 août 2009 11:24
À : users@cxf.apache.org
Objet : Re: WS-ReliableMessaging
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 <ME...@generali.fr>
>
> 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:eoglynn@gmail.com] Envoyé : jeudi 6 août
> 2009 16:10 À : users@cxf.apache.org 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 <ME...@generali.fr>
>
> >
> > 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:eoglynn@gmail.com] Envoyé : mercredi 5
> > août
> > 2009 18:32 À : users@cxf.apache.org 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 <ME...@generali.fr>
> >
> > >
> > > 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:eoglynn@gmail.com] Envoyé : mardi 4 août
> > > 2009 11:07 À : users@cxf.apache.org 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 <ME...@generali.fr>:
> > > >
> > > > 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
> > >
> >
>
Re: WS-ReliableMessaging
Posted by Eoghan Glynn <eo...@gmail.com>.
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 <ME...@generali.fr>
>
> 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:eoglynn@gmail.com]
> Envoyé : jeudi 6 août 2009 16:10
> À : users@cxf.apache.org
> 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 <ME...@generali.fr>
>
> >
> > 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:eoglynn@gmail.com] Envoyé : mercredi 5 août
> > 2009 18:32 À : users@cxf.apache.org 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 <ME...@generali.fr>
> >
> > >
> > > 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:eoglynn@gmail.com] Envoyé : mardi 4 août
> > > 2009 11:07 À : users@cxf.apache.org 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 <ME...@generali.fr>:
> > > >
> > > > 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
> > >
> >
>
RE: WS-ReliableMessaging
Posted by EVENO Manuel <ME...@generali.fr>.
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:eoglynn@gmail.com]
Envoyé : jeudi 6 août 2009 16:10
À : users@cxf.apache.org
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 <ME...@generali.fr>
>
> 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:eoglynn@gmail.com] Envoyé : mercredi 5 août
> 2009 18:32 À : users@cxf.apache.org 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 <ME...@generali.fr>
>
> >
> > 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:eoglynn@gmail.com] Envoyé : mardi 4 août
> > 2009 11:07 À : users@cxf.apache.org 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 <ME...@generali.fr>:
> > >
> > > 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
> >
>
Re: WS-ReliableMessaging
Posted by Eoghan Glynn <eo...@gmail.com>.
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 <ME...@generali.fr>
>
> 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:eoglynn@gmail.com]
> Envoyé : mercredi 5 août 2009 18:32
> À : users@cxf.apache.org
> 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 <ME...@generali.fr>
>
> >
> > 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:eoglynn@gmail.com] Envoyé : mardi 4 août
> > 2009 11:07 À : users@cxf.apache.org 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 <ME...@generali.fr>:
> > >
> > > 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
> >
>
RE: WS-ReliableMessaging
Posted by EVENO Manuel <ME...@generali.fr>.
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:eoglynn@gmail.com]
Envoyé : mercredi 5 août 2009 18:32
À : users@cxf.apache.org
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 <ME...@generali.fr>
>
> 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:eoglynn@gmail.com] Envoyé : mardi 4 août
> 2009 11:07 À : users@cxf.apache.org 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 <ME...@generali.fr>:
> >
> > 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
>
Re: WS-ReliableMessaging
Posted by Eoghan Glynn <eo...@gmail.com>.
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 <ME...@generali.fr>
>
> 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:eoglynn@gmail.com]
> Envoyé : mardi 4 août 2009 11:07
> À : users@cxf.apache.org
> 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 <ME...@generali.fr>:
> >
> > 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
>
RE: WS-ReliableMessaging
Posted by EVENO Manuel <ME...@generali.fr>.
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:eoglynn@gmail.com]
Envoyé : mardi 4 août 2009 11:07
À : users@cxf.apache.org
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 <ME...@generali.fr>:
>
> 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
Re: WS-ReliableMessaging
Posted by Eoghan Glynn <eo...@gmail.com>.
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 <ME...@generali.fr>:
>
> 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