lio bod [https://community.jboss.org/people/liobod] created the discussion "invoke frequency and classloader" To view the discussion, visit: https://community.jboss.org/message/775985#775985 -------------------------------------------------------------- Hello world, I noticed a strange behaviour and i want to knwow if this has already been pointed or fixed. My client is invoking my remoting server by sending inside an InvocationRequest a parameter that is a complex object. In fact this object is complex only because it aggragates/composes other object. On server side, the "invoke" method of my ServerInvocationHandler, shall receive this parameter, cast it in its native (or parent) class and then shall execute it. (my complex object is not only made to structure passive data, but mainly to be ran). Most of the the time it works well. But, sometimes, for some mysterious reasons, it fails an i got the following message : java.lang.IllegalStateException: BaseClassLoader@38bce164{vfszip:[MYJBOOS_DIR]/deploy/[MY_APP.jar/} classLoader is     not connected to a domain (probably undeployed?) for class sun.reflect.ConstructorAccessorImpl   at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:793)           at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)           at java.lang.ClassLoader.loadClass(ClassLoader.java:248)           at sun.misc.Unsafe.defineClass(Native Method)           at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)           at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)           at java.security.AccessController.doPrivileged(Native Method)           at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)           at sun.reflect.MethodAccessorGenerator.generateConstructor(MethodAccessorGenerator.java:76)           at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:30)           at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)           at java.lang.reflect.Constructor.newInstance(Constructor.java:513)           at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:337)           at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:239)           at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)           at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)           at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)           at org.jboss.serial.persister.ArrayPersister.readObjectArray(ArrayPersister.java:196)           at org.jboss.serial.persister.ArrayPersister.readData(ArrayPersister.java:172)           at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)           at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)           at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)           at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)           at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)           at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)           at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)           at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)           at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)           at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)           at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)           at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)           at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)           at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)           at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)           at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)           at java.io.ObjectInputStream.readObject(ObjectInputStream.java:344)           at org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager.receiveObject(JBossSerializationManager.java:189)           at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)           at org.jboss.remoting.transport.socket.ServerThread.versionedRead(ServerThread.java:853)           at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:707)           at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)           at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:524)           at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232) Just like if the class wouldn't be in the jar... May I afford an case? It may happens if my code to be execuded (brought by my complex object and available in MY_APP.jar on server side) is very short (i.e quick) and if the load of this "invoke" method is important. It occures rarely if the complex object executes a long task even if it the ServerInvocationHandler is invocated many times (lauching the complex object instances treatments in parallel) It is systematic if the parallel treatments are fast, on the Nth invocation. Like if the class disapeared from the jar... On the beginning, i though it was more a jboss problem that needed a restart. But after few seconds (if the ServerInvocationHandler is no more requested - time to get cooler ;-)) it may re-work properly. And then it is able to refind the class in the jar... Humbly, my hypothesis is it may come from a question of load, of frequency...(size of queue between remoting mecanics and native jboss classcloader?) Does anyone faced this before? Will i have a chance to find it out? and to get a workaroud? For information, i'm still using jboss 5.1.0.GA and i'd like not to upgrade its integrated libs jboss-remoting-2_5_1 and jboss-serialization-1.0.3.GA. Any advice/hint is welcome, Thx. -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/775985#775985] Start a new discussion in JBoss Remoting at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&...]