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.