serialVersionUID does not match error following WildFly 10 to WildFly 14 upgrade

[joseph.pugh]

The software developers that I work with have run into an issue with EJB/Hibernate requests that contain full entities following the upgrade from WildFly 10 to WildFly 14.  I realize this is a large jump in versions and functionality, but they have been unable to resolve the error, so I thought as the WildFly administrator I would reach out to the developer community.

Here is the error they are receiving:

javax.ejb.EJBException: java.io.StreamCorruptedException: serialVersionUID does not match!

at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:130)

at org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleInvocationRequest(EJBServerChannel.java:450)

at org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleMessage(EJBServerChannel.java:188)

at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)

at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)

at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)

at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)

at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)

at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)

at java.lang.Thread.run(Thread.java:745)

at ...asynchronous invocation...(Unknown Source)

at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)

at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:276)

at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)

at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)

at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)

at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)

at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)

at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)

at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)

at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)

at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)

at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)

at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)

at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)

at com.sun.proxy.$Proxy191.getRealmApplications(Unknown Source)

at com.touchnet.framework.tpgadmin.TPGAppUtil.loadCmmProperties(TPGAppUtil.java:2443)

at com.touchnet.framework.tpgadmin.TPGApp.processPage(TPGApp.java:1171)

at com.touchnet.servlets.TAppServlet.process(TAppServlet.java:1402)

at com.touchnet.servlets.TAppServlet.doPost(TAppServlet.java:1115)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)

at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)

at com.touchnet.servlets.filter.MdcSessionFilter.doFilter(MdcSessionFilter.java:63)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)

at com.touchnet.servlets.filter.CharsetRequestFilter.doFilter(CharsetRequestFilter.java:65)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)

at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:528)

at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1099)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:670)

at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520)

at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:745)

Caused by: java.io.StreamCorruptedException: serialVersionUID does not match!

at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108)

at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:1022)

at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1351)

at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)

at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:220)

at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1849)

at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1763)

at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1391)

at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)

at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)

at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)

at org.jboss.ejb.protocol.remote.EJBServerChannel$RemotingInvocationRequest.getRequestContent(EJBServerChannel.java:805)

at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:128)

at org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleInvocationRequest(EJBServerChannel.java:450)

at org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleMessage(EJBServerChannel.java:188)

at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)

at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)

at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)

at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)

at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)

at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)

... 1 more

All of my research has indicated that the use of an entry in the class such as

"private static final long serialVersionUID = ######"

should resolve the issue, but according to the developers they already had the above declared within their classes.

Has anyone seen this for EJB / Hibernate requests following the upgrade from WildFly 10 to WildFly 11+?

Thanks in advance for any insights you might have.

Joe

[jaikiran]

Can you narrow this down to a specific EJB method invocation and then narrow it down to a specific param class or return type that's part of that invocation which triggers this?

[jewellgm]

I would just like to expand on Jaikiran's response.

When a client invokes a method on a "remote" bean, all of the parameters that are passed to the method, and any return value, must implement the Serializable interface.  Serializable is a marker interface in Java that tells the JVM that the class data has to be transmitted in a certain manner.  It's recommended, although not required, that any classes that implement the Serializable interface, also declare the serialVersionUid parameter you mentioned.  The purpose of this field is to declare sort of a version number for the class.  If the class is changed at a later date, the serialVersionUid value should also be changed.  If the client and server have two different versions of the jar in their classpath, and if the serialVersionUid specified in the class differ, you will get that exception.  This is intended to be a protective mechanism so that the client and server aren't unknowingly using incompatible jars.  If the code did not declare the serialVersionUid, this particular exception may not occur, but you could very well get unexpected behavior that would be difficult to track down.  Sometimes you wouldn't even know about the incorrect behavior at all.

By narrowing down the error to a specific EJB method invocation, you can determine which classes are mismatched between the client and server.  You may be embedding a jar in your ear, but a module in wildfly may have a different version of the same jar and take precedence.  Or perhaps your deployment is just depending on a module that was updated in the newer version of wildfly, but your client wasn't updated to match.

[joseph.pugh]

Greg and Jaikiran,

Thanks for the additional questions and clarification.  I have reached out to the software developers locally for that information. 

[joseph.pugh]

After a few discussions with the developers, I have been unable to gather any additional detail regarding methods or classes.

Thanks for taking the time to comment/ask questions.

Joe

[wjchuah]

Hi, I had a similar issue when migrating jboss and what we did to resolve it was to make sure the hibernate-core.jar on the client matches that of the server.

In EAP's case, we had to get the version from the <JBOSS_HOME>\modules\system\layers\base\.overlays\<patch_version>\org\hibernate\main