|
Is it possibile to rise the priority of this issue?
Thanks for the suggestion! I believe this should be implemented in JaxRpcPortClientInterceptor itself rather than through a proxy with a TargetSource, though.
However, first of all, I wonder what such reinitialization actually solves: An I/O exception will usually be caused by HTTP transport problems. Any further invocation on the JaxRpcPortClientInterceptor instance will simply send a new HTTP request and thus retry anyway. So why do you need to reinitialize the JAX-RPC service and port here? What does this give you beyond simply retrying an invocation on the existing stub? Juergen Hi Juergen,
My first reaction was exactly the same - I tried to subclass the JaxRpcPortClientInterceptor and do the magic there. Let me start a bit further back - the reason why I need to re-create the JAX-RPC proxy from scratch is that we have a round-robin style clustered environment. I needed to fetch the WSDL document every time - this in effect sends me to a different server every time. Sometimes I observed that even though the particular WS server might be back up, Axis would refuse to talk to it after a fault - I am not sure where the problem comes from, it could well be specific to our networking environment. I agree with you that the aspect as is probably doesn't belong in the Spring framework itself - I was encouraged to post it here for the sake of documenting the issue and perhaps starting some discussion around it. I am sorry that I can't provide more technical detail around why exactly Axis stops working after repeated I/O errors, this is what worked for me in the end. Regards, Pavel It should be noted that in the attached class, the line:
targetFactory.addInterface(port.getPortInterface()); Should be targetFactory.addInterface(port.getServiceInterface()); So that if a serviceInterface and a portInterface have been provided the serviceInterface is the target rather than the portInterface. Daniel it should be noted that if an exception occurs in the prepare method, the JaxRpcPortClientInterceptor is never initiliazed properly
since after the exception isPrepared method returns true. It is quite bad, because if the the network is down during the first invocation of the service, there is no way to recover from this error. Indeed, the preparation code needs to use an explicit flag for checking 'prepared' state there! That might indeed cause issues in case of on-the-fly preparation.
Juergen Concretely, I've added a "refreshServiceAfterConnectFailure" bean property to JaxRpcPortClientInterceptor, allowing for service recovery similar to what we offer for RMI / EJB. Simply turn this flag on to fully reinitialize the JAX-RPC service in case of connect failure, similar to what the TargetSource approach (as suggested above) achieves. This is going to be available in Spring 2.0.3.
The prepare status check is fixed in both 2.0.3 and 1.2.9. Juergen Thanks very much! :-)
Pavel I just downloaded version 1.2.9 and thie refreshServiceAfterConnectFailure property is absent. Will this be implemented in later versions?
Thanks, Aidan As indicated in the header of this JIRA issue and in my comment above, the "refreshServiceAfterConnectFailure" feature will only be available in Spring 2.0.3 (to be released today). This has not been backported to Spring 1.2.9 to avoid side effects that could affect strict Spring 1.2 backwards compatibility.
So I'm afraid you'll have to upgrade to Spring 2.0.3 to benefit from this feature. Juergen |
|||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
org.springframework.remoting.jaxrpc.JaxRpcPortClientInterceptor does not handle Axis failures gracefully
As I've seen issues over in Jakarta Commons that get pulled in a year later, but their links are dead, thought I'd go ahead and attach the code to keep it with the Spring issue/forum.