You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Bharath Ganesh (JIRA)" <ji...@apache.org> on 2007/10/31 06:16:50 UTC

[jira] Created: (CXF-1156) Even with WS-RM network failure propogated to the application

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


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.
-
You can reply to this email to add a comment to the issue online.