[
https://issues.apache.org/jira/browse/CXF-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Sosnoski reassigned CXF-1156:
------------------------------------
Assignee: Dennis Sosnoski
> Even with WS-RM network failure propogated to the application
> -------------------------------------------------------------
>
> Key: CXF-1156
> URL: https://issues.apache.org/jira/browse/CXF-1156
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.0.2
> Reporter: Bharath Ganesh
> Assignee: Dennis Sosnoski
>
> Consider the scenario:
> 1. WS-RM is enabled on the endpoint.
> 2. The client sends a request to the server endpoint(req-resp). The request
> message is passed to the application at the destination end, after going
> through the RM Destination interceptors. But the RM -destination interceptors
> do not send the acknowledgment to the client, as the acknowledgment is
> piggybacked along with the response.
> 3. Now assume the processing takes a longer time at the server side, the
> client would get a read timeout and client thread would die.
> 4. But the RM timer task at the client side would wake up and send the
> request again, making the server code to get executed twice.(rather many
> times)
> Ideally:
> In this case it was a read timeout exception which was easy to be replicated.
> Assume it was a network failure while the response was being send from server
> to client. The client application thread would get the network exception, and
> die out. But the RM timer thread would try out a resend again. Ideally the
> application should never get the exception, instead get the response received
> by the RM-retrial timer thread should be given to the application.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
