[ 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