]
Christian von Kutzleben commented on WFLY-1456:
-----------------------------------------------
some additional information:
it turned out, that this (duplicate) bug I've found did not cause the problem; it
still occurred after migrating to EAP 6.1
However after some lengthy debugging through the Unmarshaller, it eventually turned out,
that our two environments (Eclipse and command line)
which showed different behavior (worked vs. StreamCorruptedException) had 2 different
versions of javax.ejb.EJBException
in the classpath (and the 2 environments ordered the classpath differently)
one of the EJBException classes has a field:
private java.lang.Exception causeException;
the other has no declared fields
After serializing all other fields, JBoss serialized this field (here: 2 bytes) but only
the client with the right EJBException version deserialized everything correctly, the
other
one deserialized everything less the 2 bytes. So when "readAttachments" was
called, a wrong value
was read, because the position in the bytestream was wrong.
2 responses sent to bean client on bean invocation returning an
exception, resulting in StreamCorruptedException under certain conditions
-----------------------------------------------------------------------------------------------------------------------------------------
Key: WFLY-1456
URL:
https://issues.jboss.org/browse/WFLY-1456
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: No Release
Reporter: Christian von Kutzleben
Assignee: jaikiran pai
Fix For: 8.0.0.Alpha1
I've debugged that against EAP 6.0.1, but the symptom occurred for 7.1.1 as well:
My test case throws a RuntimeException in the beans method body.
I've experienced a strang behavior: if my junit test, that is the bean client, was
executed within Eclipse, everything seemed to work fine on the client side. I debugged
into the RiverUnmarshaller and it received the correctly deserialized exception, there
were no attachments transmitted.
When I executed the junit test case from ant, the RiverUnmarshaller threw an exception,
here: java.io.EOFException: Read past end of file
(I did also get StreamCorruptedExceptions if the exception was thrown in the commit phase
rather than the method body).
In both stack traces (EOFException and StreamCorruptedException) the problem occurred in
org.jboss.ejb.client.remoting.ProtocolMessageHandler.readAttachments.
When I debugged the client invoked from ant, I found, that like in Eclipse, first the
exception is correctly deserialized, but then, it tries to read 57 attachments, but not a
single byte follows (-> EOFException).
The next step was, to debug into the server:
org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler
anonymous inner class #1, starts at about line 185:
result = invokeMethod(invocationId, componentView, invokedMethod, methodParams, locator,
attachments); //l.202
throws an exception, this is handled:
MethodInvocationMessageHandler.this.writeException(channelAssociation,
MethodInvocationMessageHandler.this.marshallerFactory, invocationId, throwable,
attachments); //l.206
"attachments" is empty; a response message is created containing no
attachments, this is the same for the Eclipse and ant invocation.
The weird thing now is, regardless, that an exception was thrown and a response message
written, in l. 238
writeMethodInvocationResponse(channelAssociation, invocationId, result, attachments);
another, second response is written. Containing "null" as result, and this time
a single affinity object in the attachments.
When run from Eclipse, this code executed fine, however the bean client seems to never
read the second response.
When run from ant, this code throws an exception:
JBAS014560: Could not open message outputstream for writing to Channel
and the client reads a corrupted first response, containing a valid exception and some
nonsense thereafter.
I blame the different behavior on different timings, for me it seems that the cause of
the issue is, that in the exceptional case a second response is written, that should not
be written.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: