Red Hat Bugzilla – Bug 1155815
[GSS](6.4.0) Array of size 0 causes java.lang.ClassCastException
Last modified: 2015-02-26 19:50:05 EST
In a <distributable> web app with a session scoped bean that has an empty object array, for example : @SessionScoped @Named public class SessionData implements Serializable { public class SomeObject implements Serializable { } private SomeObject[] someObjectsArray = new SomeObject[0]; public SomeObject[] getSomeObjectsArray() { return someObjectsArray; } public void setSomeObjectsArray(SomeObject[] someObjectsArray) { this.someObjectsArray = someObjectsArray; } private String name = "test name"; public String getName() { return name; } public void setName(String name) { this.name = name; } } when the session is replicated to another cluster nodes the deserialization fails
Stack trace: 16:13:10,139 WARN [org.jboss.as.clustering.web.infinispan] (http-/192.168.1.103:8180-1) JBAS010322: Failed to load session awqqAI2iOGKu8fn8fuLhSe0v: java.lang.RuntimeException: JBAS010333: Failed to load session attributes for session: awqqAI2iOGKu8fn8fuLhSe0v at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$2.invoke(DistributedCacheManager.java:229) at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$2.invoke(DistributedCacheManager.java:212) at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) at org.jboss.as.clustering.infinispan.invoker.BatchCacheInvoker.invoke(BatchCacheInvoker.java:48) at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:85) at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$ForceSynchronousCacheInvoker.invoke(DistributedCacheManager.java:550) at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getData(DistributedCacheManager.java:238) at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionData(DistributedCacheManager.java:196) at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1429) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:688) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.apache.catalina.connector.Request.doGetSession(Request.java:2659) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.connector.Request.getSession(Request.java:2381) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:791) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at com.sun.faces.context.ExternalContextImpl.getSession(ExternalContextImpl.java:157) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] at com.sun.faces.application.view.FaceletViewHandlingStrategy.getSession(FaceletViewHandlingStrategy.java:502) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:408) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jboss-jsf-api_2.1_spec-2.1.28.Final-redhat-1.jar:2.1.28.Final-redhat-1] at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.1.28.Final-redhat-1.jar:2.1.28.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91) at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72) at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67] Caused by: java.lang.ClassCastException: com.redhat.marshaller.SomeSessionData cannot be cast to java.lang.String at org.jboss.marshalling.ModularClassResolver.resolveClass(ModularClassResolver.java:95) at org.jboss.as.clustering.ClassLoaderAwareClassResolver.resolveClass(ClassLoaderAwareClassResolver.java:92) at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:943) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:310) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1712) at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1628) at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1269) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1712) at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1628) at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1269) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.river.RiverUnmarshaller.doReadMapObject(RiverUnmarshaller.java:195) at org.jboss.marshalling.river.RiverUnmarshaller.readMapData(RiverUnmarshaller.java:819) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:682) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) at org.jboss.as.clustering.SimpleMarshalledValue.get(SimpleMarshalledValue.java:122) at org.jboss.as.clustering.web.impl.SessionAttributeMarshallerImpl.unmarshal(SessionAttributeMarshallerImpl.java:72) at org.jboss.as.clustering.web.infinispan.CoarseSessionAttributeStorage.load(CoarseSessionAttributeStorage.java:64) at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$2.invoke(DistributedCacheManager.java:227) ... 41 more Caused by: an exception which occurred: in field someObjectsArray in object of type com.redhat.marshaller.SomeSessionData in field instance in object of type org.jboss.weld.context.SerializableContextualInstanceImpl in map value at index [1] of size [3]
a workaround is to set the array to null rather then size 0.
looks like an upstream issue https://developer.jboss.org/message/907097
I have attempted to reproduce this with a standalone river marshaller, but it worked fine. also tried using different class-loaders , and using SimpleMarshalledValue but still could not reproduce. possible culprits might be the class resolver when combined with jboss-modules or possibly WELD's SerializableContextualInstanceImpl/SerializableContextualImpl
All reported incidents of this occurring that I have found so far all have one factor in common: it always happens with web clustering.
Created attachment 953699 [details] Arquillian test that reproduces the issue. I was able to reproduce this using a simple arquillian test that uses only JBoss Marshalling. I'm assigning this to dmlloyd to investigate.
David Lloyd <david.lloyd@redhat.com> updated the status of jira JBMAR-172 to Resolved
Created attachment 953869 [details] JBoss Marshalling River JAR, 1.4 branch, snapshot with fix Check out 1.4 branch, update to revision f179414a859ed16a4b7b67e2a2a15766ab6bb96a
The details of the problem are on the JBMAR-172 JIRA. The attached JAR is a snapshot of the River protocol JAR with the described fix. Compatibility impact: any previously serialized (e.g. to disk or cache) data will read properly with the fix (only the read [unmarshalling] code was changed). Any JVM which was exhibiting the exception (e.g. upon receiving EJB payload) should function correctly after installing the repaired JAR.