Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HttpInvokerClientInterceptor should not wrap client-side Error as RemoteAccessException [SPR-14985] #19551

Closed
spring-projects-issues opened this issue Dec 6, 2016 · 3 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Dec 6, 2016

Michael Krüske opened SPR-14985 and commented

When doing a remote call via HttpInvoker an OutOfMemoryError occured in our client application. However this OutOfMemoryError got wrapped as RemoteAccessException which is quite confusing.

HttpInvokerClientInterceptor#convertHttpInvokerAccessException should not wrap java.lang.Error, but just throw them as-is.


Affects: 3.2.17, 4.3.4

Issue Links:

  • #15593 HttpInvokerClientInterceptor.convertHttpInvokerAccessException implementation throws the RemoteAccessException instead of return it
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 6, 2016

Juergen Hoeller commented

Generally speaking, we explicitly want to handle an Error as well, in particular for remote access: Otherwise it's unclear whether an OutOfMemoryError for example occurred locally or on the remote server.

That said, we should consider wrapping those in a more specific subclass, not in the general RemoteAccessException that they're ending up in currently.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 6, 2016

Michael Krüske commented

If an Error was thrown in the remote side it would be okay for me to wrap it.

I just don't like Error on the local side to be wrapped - so we need to find a way to keep these to apart.

This possible requires the server-side to wrap its Error instances in something specific before returning it.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 8, 2016

Juergen Hoeller commented

This turns out to be easy enough to differentiate: At the executeRequest level, we only really deal with local exceptions and should let an Error get propagated as-is, with the sole exception of NoClassDefFoundError which hints at a deserialization problem. Whereas for server-side exceptions, they'll only get recreated in the next step - recreateRemoteInvocationResult - anyway.

I've refined our default convertHttpInvokerAccessException implementation accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.