org.springframework.remoting.jaxrpc.JaxRpcPortClientInterceptor does not handle Axis failures gracefully [SPR-1688]

[spring-projects-issues]

Pavel Tcholakov opened SPR-1688 and commented

It is possible (e.g. due to temporary network failure, etc.) for the Axis port to become unavailable. In this case, the standard Spring class does not handle reconnections. I wrote a custom TargetSource which allows for new JaxRpcPortClientInterceptor's to be created on the fly as needed.

Please see this thread which has links to code & XML samples:

http://forum.springframework.org/showthread.php?t=22112

---

Affects: 1.2.6

Attachments:

• JaxRpcPortTargetSource.java (5.81 kB)

1 votes, 4 watchers

[spring-projects-issues]

Henri Yandell commented

Hope you don't mind Pavel; I happened to be looking at this issue as part of my day job at SourceLabs (seemed like a good FAQ issue for customers) and noticed that the piece of code wasn't attached to the issue.

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.

[spring-projects-issues]

Paolo Balzarotti commented

Is it possibile to rise the priority of this issue?

[spring-projects-issues]

Juergen Hoeller commented

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

[spring-projects-issues]

Pavel Tcholakov commented

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

[spring-projects-issues]

Daniel Massie commented

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

[spring-projects-issues]

FX poignart commented

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.

[spring-projects-issues]

Juergen Hoeller commented

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

[spring-projects-issues]

Juergen Hoeller commented

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

[spring-projects-issues]

Pavel Tcholakov commented

Thanks very much! :-)

Pavel

[spring-projects-issues]

Aidan McGowran commented

I just downloaded version 1.2.9 and thie refreshServiceAfterConnectFailure property is absent. Will this be implemented in later versions?

Thanks,
Aidan

[spring-projects-issues]

Juergen Hoeller commented

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