]
Brian Stansberry updated JBAS-3337:
-----------------------------------
Fix Version/s: Backlog
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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: