[jboss-jira] [JBoss JIRA] (WFLY-1456) 2 responses sent to bean client on bean invocation returning an exception, resulting in StreamCorruptedException under certain conditions

[Christian von Kutzleben (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787317#comment-12787317 ] 

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: http://www.atlassian.com/software/jira