Serialization of Throwable from server (jdk8) to client (jdk9) causes exception. Bug?

[sam.clunie]

Hi

We have a Wildfly 10.1.0.Final server running on JDK 1.8.0u144, and are doing some testing of running our Swing client under the latest JDK9 Early Access release (currently 178). When an exception is thrown by one of our Stateless Session Beans back to our client, we get the attached exception.

It would appear that in JDK9, StackTraceElement has several additional fields over what was in JDK8, and I suspect that this is causing issues for JBoss Marshalling River.

Java 8:

private String declaringClass;
private String methodName;
private String fileName;
private int    lineNumber;

Java 9:

private String classLoaderName;
private String moduleName;
private String moduleVersion;
private String declaringClass;
private String methodName;
private String fileName;
private int    lineNumber;
private byte   format = 0; // Default to show all

A bit of debugging revealed that the org.jboss.as.ejb3.remote.protocol.versionone.ProtocolV1ClassTable class table from wildfly-ejb-10.1.0.Final.jar is being used for marshalling, and that there were similar issues reported before for JDK6/JDK7 compatibility issues with the Throwable Class, discussed here:

1. Jboss AS 7.1, EJB exceptions and java.io.StreamCorruptedException
2. [EJBCLIENT-46] Problem with Throwable in the class table - JBoss Issue Tracker

Client side, we are using jboss-ejb-client-2.1.4.Final.jar, and both client and server are using jboss-marshalling-river-1.4.11.Final.jar and jboss-marshalling-1.4.11.Final.jar.

Is anyone else experiencing the same, or able to confirm whether this is a problem in org.jboss.as.ejb3.remote.protocol.versionone.ProtocolV1ClassTable that needs to be resolved in a similar way?

Thanks.

[ctomc]

1) latest build of jdk9 is 181

2) please use WildFly 11 build for any experiments with JDK9

in your case you would for sure need to use client libs from wildfly 11 to make it work on JDK9.

[dmlloyd]

Sam Clunie wrote:

Hi

We have a Wildfly 10.1.0.Final server running on JDK 1.8.0u144, and are doing some testing of running our Swing client under the latest JDK9 Early Access release (currently 178). When an exception is thrown by one of our Stateless Session Beans back to our client, we get the attached exception.

It would appear that in JDK9, StackTraceElement has several additional fields over what was in JDK8, and I suspect that this is causing issues for JBoss Marshalling River.

Java 8:

1. privateStringdeclaringClass;
2. privateStringmethodName;
3. privateStringfileName;
4. privateintlineNumber;

Java 9:

1. privateStringclassLoaderName;
2. privateStringmoduleName;
3. privateStringmoduleVersion;
4. privateStringdeclaringClass;
5. privateStringmethodName;
6. privateStringfileName;
7. privateintlineNumber;
8. privatebyteformat=0;//Defaulttoshowall

A bit of debugging revealed that the org.jboss.as.ejb3.remote.protocol.versionone.ProtocolV1ClassTable class table from wildfly-ejb-10.1.0.Final.jar is being used for marshalling, and that there were similar issues reported before for JDK6/JDK7 compatibility issues with the Throwable Class, discussed here:

1. Jboss AS 7.1, EJB exceptions and java.io.StreamCorruptedException
2. [EJBCLIENT-46] Problem with Throwable in the class table - JBoss Issue Tracker

Client side, we are using jboss-ejb-client-2.1.4.Final.jar, and both client and server are using jboss-marshalling-river-1.4.11.Final.jar and jboss-marshalling-1.4.11.Final.jar.

Is anyone else experiencing the same, or able to confirm whether this is a problem in org.jboss.as.ejb3.remote.protocol.versionone.ProtocolV1ClassTable that needs to be resolved in a similar way?

Thanks.

This is a legitimate bug.  We mostly solved this kind of problem in the 4.x series of the EJB client by creating a table of classes which should not be sent by table.  But I see we did not add StackTraceElement to that set; I'll do a review of these classes to ensure these get fixed for WildFly 11.  Also I think we can get the same fix into the legacy client as well.

[dmlloyd]

I created https://issues.jboss.org/browse/EJBCLIENT-268 to track this problem.

[sam.clunie]

David,

Thanks for the quick response. Much appreciated!

Cheers.

[sam.clunie]

David,

I see that there is now a fix available for EJBCLIENT-268. Do you have a recommendation for how I can make use of this fix for running Wildfly 10.1.0.Final?

Thanks.

[dmlloyd]

The fix would have to be backported to the EJB client branch used by 10.1.0.Final.  Alternatively the client side could use the client libs for WildFly 11, which should be backwards-compatible.

[sam.clunie]

Thanks David.

We gave using the Wildfly 11 Client libraries a try, but encountered issues with ArrayStoreException's being thrown when unmarshalling to either a JDK8 or JDK9 client with the server still running on JDK8 and Wildfly 10.1.0.Final, presumably due to the use of the new StackTraceElement4 class.

We'll go with a customised build of wildfly-ejb-10.1.0.Final.jar (updating org.jboss.as.ejb3.remote.protocol.versionone.ProtocolV1ClassTable), and a customised version of jboss-ejb-client-2.1.4.Final.jar(updating org.jboss.ejb.client.remoting.ProtocolV1ClassTable) to work past the issue.

Thanks.

[dmlloyd]

Sam Clunie wrote:

Thanks David.

We gave using the Wildfly 11 Client libraries a try, but encountered issues with ArrayStoreException's being thrown when unmarshalling to either a JDK8 or JDK9 client with the server still running on JDK8 and Wildfly 10.1.0.Final, presumably due to the use of the new StackTraceElement4 class.

We'll go with a customised build of wildfly-ejb-10.1.0.Final.jar (updating org.jboss.as.ejb3.remote.protocol.versionone.ProtocolV1ClassTable), and a customised version of jboss-ejb-client-2.1.4.Final.jar(updating org.jboss.ejb.client.remoting.ProtocolV1ClassTable) to work past the issue.

Thanks.

This is a known problem which will be fixed soon (and will require a new jboss-marshalling-river as well as an updated jboss-ejb-client).  I plan to cut the release for jboss-marshalling today or tomorrow.