[JBoss JIRA] Commented: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).
by Tom Elrod (JIRA)
[ 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
19 years, 4 months