Bugs item #516684, was opened at 2002-02-12 14:51
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516684&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned to: Scott M Stark (starksm)
Summary: CCE on redeployment of ear with sar/ejb
Initial Comment:
The perf-service.ear in the current main testsuite is
not usable across redeployments. Steps to reproduce:
1. Deploy the perf-service.ear and then execute the
jboss.test:service=PerfTest runTests(100) operation.
Ignore the NPE shown under testTimings.
2. Simply touch the perf-service.ear and then execute
the runTests(100) operation again on the
jboss.test:service=PerfTest mbean, you will see:
+++ testTimingsCMT()
testTimingsCMT failed:
java.lang.ClassCastException: $Proxy19
at
org.jboss.test.perf.test.PerfTest.testTimingsCMT
(PerfTest.java:134)
at org.jboss.test.perf.test.PerfTest.runTests
(PerfTest.java:66)
at java.lang.reflect.Method.invoke(Native
Method)
at
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1628)
at
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1523)
at com.sun.jdmk.comm.HtmlInvokePage.buildPage
(HtmlInvokePage.java:240)
at
com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest
(HtmlRequestHandler.java:325)
at
com.sun.jdmk.comm.HtmlRequestHandler.processRequest
(HtmlRequestHandler.java:152)
at com.sun.jdmk.comm.HtmlRequestHandler.doRun
(HtmlRequestHandler.java:79)
at com.sun.jdmk.comm.ClientHandler.run
(ClientHandler.java:84)
at java.lang.Thread.run(Thread.java:484)
----------------------------------------------------------------------
Comment By: David Jencks (d_jencks)
Date: 2002-02-17 16:36
Message:
Logged In: YES
user_id=60525
"If the mbean service
along with any external classes it references is reloaded,
the next execution of the mbean service uses the same
MBeanClassLoader instance to load classes,"
Did you make sure it is the same MBeanClassLoader? There is
code to remove the old MBeanClassLoader when the mbean is
removed from the mbeanserver and then a new one is created
(with the same object name) for the new deployment. If the
"remove mbeanClassLoader" code is not being executed that
could be the problem, maybe...
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-02-17 16:17
Message:
Logged In: YES
user_id=175228
The real issue appears to be the new class loader model and
caching of classes at the vm level. When the PerfTest
service looks up the ProbeHome interface this is the stack
trace where the class for the ProbeHome interface class
gets loaded:
java.lang.Class.forName (Class.java:195)
sun.rmi.server.MarshalInputStream.resolveProxyClass
(MarshalInputStream.java:183)
java.io.ObjectInputStream.inputProxyClassDescriptor
(ObjectInputStream.java:982)
java.io.ObjectInputStream.readObject
(ObjectInputStream.java:370)
java.io.ObjectInputStream.readObject
(ObjectInputStream.java:236)
java.io.ObjectInputStream.inputObject
(ObjectInputStream.java:1186)
java.io.ObjectInputStream.readObject
(ObjectInputStream.java:386)
java.io.ObjectInputStream.readObject
(ObjectInputStream.java:236)
java.rmi.MarshalledObject.get (MarshalledObject.java:138)
org.jnp.interfaces.NamingContext.lookup
(NamingContext.java:376)
org.jnp.interfaces.NamingContext.lookup
(NamingContext.java:356)
javax.naming.InitialContext.lookup (InitialContext.java:350)
org.jboss.test.perf.test.PerfTest.testTimings
(PerfTest.java:102)
org.jboss.test.perf.test.PerfTest.runTests
(PerfTest.java:56)
java.lang.reflect.Method.invoke (Native Method)
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1628)
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1523)
com.sun.jdmk.comm.HtmlInvokePage.buildPage
(HtmlInvokePage.java:240)
com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest
(HtmlRequestHandler.java:325)
com.sun.jdmk.comm.HtmlRequestHandler.processRequest
(HtmlRequestHandler.java:152)
com.sun.jdmk.comm.HtmlRequestHandler.doRun
(HtmlRequestHandler.java:79)
com.sun.jdmk.comm.ClientHandler.run (ClientHandler.java:84)
java.lang.Thread.run (Thread.java:484)
The public static Class forName(String name, boolean
initialize, ClassLoader loader)
throws ClassNotFoundException
in turn calls the forName0 native method:
private static native Class forName0(String name, boolean
initialize, ClassLoader loader)
throws ClassNotFoundException;
This ultimate calls this native function:
static ClassClass *
LookupLoaderCache(char *hashed_name, struct
Hjava_lang_ClassLoader *loader)
from j2sdk1.3.1-src/src/share/javavm/runtime/classresolver.c
This is simply a hash table of class bytes keyed by the
loader and class name. The issue is that mbean services
run with the same thread context class MBeanClassLoader
and only when a class is first seen is the is this
load asked to load the class which results in a call to
the ServiceLibraries repository. If the mbean service
along with any external classes it references is reloaded,
the next execution of the mbean service uses the same
MBeanClassLoader instance to load classes, and those that
were originally cached are still returned and these will
conflict if when the class loader that loaded the class
into the ServiceLibraries repository was not the main
MBeanClassLoader.
----------------------------------------------------------------------
Comment By: David Jencks (d_jencks)
Date: 2002-02-14 20:25
Message:
Logged In: YES
user_id=60525
I have found a workaround for this.
Instead of e.g.
ProbeHome ph = (ProbeHome) new
InitialContext().lookup("jndiname");
set the context classloader first to that of the class we
are expecting:
ClassLoader oldClass =
Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(ProbeHome.class.getClassLoader());
try
{
ProbeHome ph = (ProbeHome) new
InitialContext().lookup("jndiname");
...
...
}
finally
{
Thread.currentThread().setContextClassLoader(oldCl);
}
The rmi unmarshalling code, in the absence of location
annotations, ends up using the context classloader of the
caller when constructing a new proxy. In order to get the
correct class, you apparently have to set this classloader
to the classloader actually used for the class you are
looking for. The mbeanClassLoader doesn't work.
I'm not sure if this should be considered a problem with
--sun's marshalling code
--the location annotations (currently none, since jboss
URLClassLoader return no URLs) (Putting them back in doesn't
remove the problem, however)
--our extensible classloader framework.
I believe that returning the original object bound rather
than a serialized-deserialized version would always work.
----------------------------------------------------------------------
Comment By: David Jencks (d_jencks)
Date: 2002-02-14 08:46
Message:
Logged In: YES
user_id=60525
I think this may have something to do with
ObjectInput/OutputStream and marshalling.
On each deploy, a new proxy is bound into jndi. It is
stored as a MarshalledObject. For instance, I see it being
bound as classes $Proxy23, $Proxy42 and $Proxy57 on
successive deployments.
When it is retrieved, the className is different: $Proxy27
Once it is retrieved, the retrieved class is always the
same: $Proxy27 in this example.
I haven't dug into ObjectInput/Output stream enough to see
what is going on.
However....since serialization is the root of all
application lethargy, is it really necessary to bind the
proxy serialized? For in vm calls, wouldn't it be
significantly faster to use an ObjectFactory/reference
scheme to return the actual object bound?
I don't know enough about how jndi/rmi works to know if this
would work with remote access. Would it be possible to bind
using an ObjectFactory for local access and also a
pre-serialized MarshalledObject for remote access?
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-02-13 22:33
Message:
Logged In: YES
user_id=175228
The most recent PerfTest mbean output shows clearly what
the problem is. On the initial deployment and execution of
the runTests operation, both the ProbeHome interface as
seen by the proxy bound in JNDI and the class reference in
the PerfTest service mbean are seen to be loaded from the
same perf.jar location:
ProbeHome Interfaces:
++interface org.jboss.test.perf.interfaces.ProbeHome
++++CodeSource: (file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-3.0.0DR2/tmp/deploy/62.60.perf.jar )
++interface javax.ejb.Handle
++++CodeSource: (file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-3.0.0DR2/tmp/deploy/6.jboss-
j2ee.jar )
PerfTest ProbHome CodeSource:
(file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-3.0.0DR2/tmp/deploy/62.60.perf.jar )
After a new deployment of the perf-service.ear, the proxy
bound in JNDI continues to reference the ProxyHome class
loaded from the original perf.jar, while the PerfTest
service mbean ProbeHome now refers to the new perf.jar
deployment:
ProbeHome Interfaces:
++interface org.jboss.test.perf.interfaces.ProbeHome
++++CodeSource: (file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-3.0.0DR2/tmp/deploy/62.60.perf.jar )
++interface javax.ejb.Handle
++++CodeSource: (file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-3.0.0DR2/tmp/deploy/6.jboss-
j2ee.jar )
PerfTest ProbHome CodeSource:
(file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-3.0.0DR2/tmp/deploy/68.66.perf.jar )
The JNDI bindings of the proxies are not being updated
correctly on redeployment.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-02-13 10:17
Message:
Logged In: YES
user_id=175228
That is correct.
----------------------------------------------------------------------
Comment By: David Jencks (d_jencks)
Date: 2002-02-13 09:12
Message:
Logged In: YES
user_id=60525
I notice that you can redeploy many times successfully as
long as you don't run the test. Once you have run the test,
after redeploying, the test fails.
deploy
redeploy
redeploy
run test (succeeds)
redeploy
run test (fails)
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516684&group_id=22866
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
