[jboss-jira] [JBoss JIRA] Updated: (JBAS-3337) ClassNotFoundException during cache invalidation (option D) of EJBs with composite primary keys

ClassNotFoundException during cache invalidation (option D) of EJBs with composite primary keys ----------------------------------------------------------------------------------------------- Key: JBAS-3337 URL: https://jira.jboss.org/jira/browse/JBAS-3337 Project: JBoss Application Server Issue Type: Bug Security Level: Public(Everyone can see) Components: Clustering, EJB2, EJB3 Affects Versions: JBossAS-3.2.7 Final, JBossAS-4.0.4.GA Environment: Windows XP (java 1.4 1.5), Linux Debian (java 1.4), PC Reporter: Przemek Dlugosz Assignee: Brian Stansberry Fix For: Backlog When using ejb containers like "Standard CMP 2.x EntityBean with cache invalidation" (or similar) with option D in clustered environment we encounter ClassNotFoundException when one of our servers modify data (with composite PK) and the other one receives "invalidate" message. Then the other one prints something like this: ================================ 2006-06-23 16:19:09,325 WARN [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] failed unserializing message buffer (msg=[dst: 228.1.2.3:45566, src: metria:45663 (additional data: 19 bytes) (2 headers), size = 682 bytes]) java.lang.ClassNotFoundException: No ClassLoaders found for: com.swps.metria.ejb.PKs.MetriaParametryUzytkownikaPK at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212) at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:511) at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405) at java.lang.ClassLoader.loadClass(ClassLoader.java:262) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:322) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:207) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:551) at org.jboss.invocation.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.java:109) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1503) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1425) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1616) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1264) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1593) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1261) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1830) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1756) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1636) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1264) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1593) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1261) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1593) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1261) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:322) at org.jgroups.blocks.MethodCall.readExternal(MethodCall.java:370) at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1676) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1634) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1264) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:322) at org.jboss.ha.framework.server.HAPartitionImpl.objectFromByteBuffer(HAPartitionImpl.java:145) at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:967) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554) at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691) at java.lang.Thread.run(Thread.java:536) ================================== Our app (EJB + PKs, WAR) is packed into Metria.ear and we use jboss-app.xml: ========================== <?xml version="1.0" encoding="UTF-8"?> <jboss-app> <loader-repository> swps.edu.pl:loader=Metria.ear <loader-repository-config> java2ParentDelegation=true </loader-repository-config> </loader-repository> </jboss-app> ========================== Our app uses only cache-invalidation to propagate data modifications messages beetwen 2 servers (no clustered EJBs and no clustered HTTP sessions). Shouldn't the right classloader be detected automatically? Or there is something wrong with the app? Nevertheless invalidation works but there could be some potential dangerous situations. Best regards Przemek