[JBoss JIRA] Commented: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).
5:20 a.m.
[ http://jira.jboss.com/jira/browse/JBAS-3198?page=comments#action_12349415 ]
Tom Elrod commented on JBAS-3198:
----------------------------------
The bug is actually within
org.jboss.invocation.pooled.interfaces.OptimizedObjectInputStream where is caching loaded
classes using a static map (which does not take into account classloaders).
The fix is to change so has a cache per classloader. This has been checked into the
Branch_4_0 branch and tested manually. Working on automated testsuite test (actually now
have that working, just need to clean up before checkin). Also need to update the checked
in code to use weak references so don't have memory lead on classloaders when
re-deploy.
Problems with separated ClassLoaders for EARs and pooled invoker
(PooledInvokerHA).
-----------------------------------------------------------------------------------
Key: JBAS-3198
URL: http://jira.jboss.com/jira/browse/JBAS-3198
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: ClassLoading
Affects Versions: JBossAS-4.0.5.CR1
Environment: Windows XP, HP-UX 11, JDK 1.4.2 and 1.5
Reporter: Eric Hambuch
Assigned To: Tom Elrod
Priority: Critical
Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.0.CR1, JBossAS-4.0.5.SP1
Attachments: example.zip
When using the pooled invoker (PooledInvokerHA) in the "all" configuration with
separated classloaders for each EAR (as described in Wiki:ClassLoadingConfiguration) an
invocation to a bean causes confusion to the separated classloaders.
More detailed:
I switched from jrmpha-invoker (which creates a new thread for each request which is
really bad) to pooledha invoker in a clustered environment. I have to Stateless Session
Beans that share the same bean interface. Each Session Bean is deployed in a separate EAR.
In "ear-deployer.xml" I switched "isolated" to "true" to
separate the classloaders of the EARs.
When I call the first bean everything works fine. But when I try to call the second bean
(same interface, but different bean!) JBoss throws the following exception:
java.rmi.ServerException: RuntimeException; nested exception is:
java.lang.IllegalArgumentException: argument type mismatch
at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:386)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:196)
at
org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:264)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
at org.jboss.ejb.Container.invoke(Container.java:873)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.invocation.pooled.server.PooledInvokerHA.invoke(PooledInvokerHA.java:146)
at
org.jboss.invocation.pooled.server.ServerThread.processInvocation(ServerThread.java:213)
at org.jboss.invocation.pooled.server.ServerThread.dorun(ServerThread.java:268)
at org.jboss.invocation.pooled.server.ServerThread.run(ServerThread.java:139)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149)
at
org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106)
at
org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:158)
at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62)
at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:154)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:153)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
The IllegalArgumentException comes from the fact that the Method.invoke() is called with
a class of the wrong classloader (class from other EAR).
With jrmpha-invoker everything works fine. Maybe the thread pool causes a mixture of the
classloaders?
I created a minimized example that can be provided if required.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6325
days inactive
6325
days old
0 comments
1 participants
participants (1)
-
Tom Elrod (JIRA)