[jboss-jira] [JBoss JIRA] Commented: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).

[Adrian Brock (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-3198?page=comments#action_12347276 ] 
            
Adrian Brock commented on JBAS-3198:
------------------------------------

The above analysis is incorrect.

The comment in the pooled invoker just says that something else sets the classloader,
which is true, it is set during this method in the above stacktrace:

at org.jboss.ejb.Container.invoke(Container.java:873) 

Since this is a remote invocation, the unmarshalling is done lazily
i.e. when somebody invokes PooledMarshalledInvocation.getArguments()

   public Object[] getArguments()
   {
      if (this.args == null)
      {
         try
         {
            this.args = (Object[]) pooledMarshalledArgs.get();
         }
         catch (Exception e)
         {
            e.printStackTrace();
         }
      }
      return args;
   }


The most obvious problem is that this shares the same bug as JBAS-1911

i.e. the problem is that the arguments could not be unmarshalled due to missing classes,
but instead of throwing an error, it is eating the error and returning an empty array.

It is also not clear to me why this PooledMarshalledInvocation overrides
this and other methods anyway?

For the return type, the PooledInvoker is missing the code that wraps the
result in a MarshalledObject, i.e.

         // The cl on the thread should be set in another interceptor
         Object obj = serverAction.invoke(mbean, "invoke",
               new Object[] { invocation }, Invocation.INVOKE_SIGNATURE);

-          return obj;
+         return new MarshalledObject(obj);

Compare with the JRMP invoker.


> 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.3 SP1
>         Environment: Windows XP, HP-UX 11, JDK 1.4.2 and 1.5
>            Reporter: Eric Hambuch
>         Assigned To: Scott M Stark
>
> 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