[
http://jira.jboss.com/jira/browse/JBREM-665?page=comments#action_12360784 ]
Ron Sigal commented on JBREM-665:
---------------------------------
1. When an exception is thrown in ServerInvocationHandler, it will trapped, sent to the
client, and rethrown.
2. This particular exception is throw outside of the application code. I've run a
similar, though pure Remoting, example in Windows (jdk 1.4 and jdk 1.5) and linux (jdk
1.5), and in all cases I see the following on the client side:
java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException:
org.jboss.test.remoting.ExceptionServer$SampleInvocationHandler
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at
org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:133)
at
org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:95)
at
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:937)
at
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:579)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:123)
at org.jboss.remoting.Client.invoke(Client.java:1550)
at org.jboss.remoting.Client.invoke(Client.java:530)
at org.jboss.remoting.Client.invoke(Client.java:518)
at org.jboss.test.remoting.ExceptionClient.testException(ExceptionClient.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.io.NotSerializableException:
org.jboss.test.remoting.ExceptionServer$SampleInvocationHandler
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at
org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:86)
at
org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:104)
at
org.jboss.remoting.transport.socket.ServerThread.versionedWrite(ServerThread.java:780)
at
org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:585)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:363)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:159)
So in my case the NotSerializableException makes it back to the client. Maybe the
behavior is implementation dependent (which is why I tried several environments).
It's strange, though, that the exception in Scott's example is thrown at line 352,
which seems to match the line
response = versionedRead(inputStream, unmarshaller, version);
in Remoting 2.0.0.GA. Why isn't it coming from inside of versionedRead()? Could AOP
be affecting something?
In general, the try/catch block in ServerThread, which is where the exception is coming
from, could be extended to catch more exceptions outside of ServerInvocationHandler, but I
don't see how it would help in this case. If an exception is thrown in the course of
writing the response, then it's likely that the connection is broken, and catching and
transmitting the exception is likely to fail as well. That's not the case here, but
in this case, an exception really is making its way back to the client, though different
exceptions are arriving in the different circumstances. If the behavior is implementation
dependent, then there may not be much we can do about that in Remoting.
If this issue is worth persuing, then it would be helpful to be able to recreate the
original situation. Scott, where did that exception come from?
Need better error reporting of response marshalling errors
----------------------------------------------------------
Key: JBREM-665
URL:
http://jira.jboss.com/jira/browse/JBREM-665
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Affects Versions: 2.2.0.Alpha4
Reporter: Scott M Stark
Assigned To: Ron Sigal
Priority: Critical
Fix For: 2.4.0.Beta1 (Pinto)
A failure to write a response on the server such as:
21:03:32,935 ERROR [ServerThread] failed to process invocation.
java.io.NotSerializableException: java.util.HashMap$KeySet
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at
org.jboss.aop.joinpoint.InvocationResponse.writeExternal(InvocationResponse.java:101)
at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at
org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:85)
at
org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:84)
at
org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:66)
at
org.jboss.remoting.transport.socket.ServerThread.versionedWrite(ServerThread.java:491)
at
org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:470)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:527)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:261)
results in this uninformative exception on the client:
java.rmi.MarshalException: Failed to communicate. Problem during
marshalling/unmarshalling; nested exception is:
...
Caused by: java.net.SocketException
at
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:352)
at
org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:125)
at org.jboss.remoting.Client.invoke(Client.java:589)
at org.jboss.remoting.Client.invoke(Client.java:581)
at
org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at
org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at AOPProxy$1.getTemplateNames(AOPProxy$1.java)
at
org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testAddDataSource(ProfileServiceUnitTestCase.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
at
org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74)
... 23 more
Need to look at how this can be improved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira