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

[jaikiran pai (JIRA)]

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

jaikiran pai commented on WFLY-1456:
------------------------------------

This indeed is the same bug, that I thought it was. It was fixed as part of https://issues.jboss.org/browse/AS7-6474.

I'll mark this as a duplicate. Please use the later EAP version or the WildFly version http://wildfly.org/download/ which has this fix.

By the way, thank you for spending time to open the code and debug what's going on. This one wouldn't have been easy to figure out if you hadn't done that.

                
> 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
>
> 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