[JBoss JIRA] Updated: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).
by Jim Moran (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3198?page=all ]
Jim Moran updated JBAS-3198:
----------------------------
Attachment: example.zip
Example to illustrate bug
You need to set jboss.server.dir build property to point to a standard 'default' server config directory
> 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
17 years, 5 months
[JBoss JIRA] Commented: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-33?page=comments#action_12348148 ]
Bela Ban commented on JGRP-33:
------------------------------
Tony: please use the mailing lists to discuss issue such as these. JIRA should just be used to create issues. If you have a use case (with code) that describes how to get an OOM, that would help. You can turn local messages off through Channel.setOpt(Channel.LOCAL, Boolean.FALSE);
> JGroups throws OutOfMemoryError after running for a few hours
> -------------------------------------------------------------
>
> Key: JGRP-33
> URL: http://jira.jboss.com/jira/browse/JGRP-33
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.2.8
> Environment: SUN JDK 1.4.2_05 & SUN JDK 1.5.0 on Windows & Unix platforms
> Reporter: B.S.Navin
> Assigned To: Bela Ban
> Fix For: 2.2.8
>
> Attachments: fc-fast-udp-tcpping.xml, fc-fast-udp.xml, JGroupsMemTest.java, PublishThread2.java, runj10.sh
>
>
> I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals.
> The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances.
> I have run the program on unix and windows machines with 1G RAM.
> Not able to make much from an HProf output of one of the instances.
> This seems to be the cause for the JBossCache bug "http://jira.jboss.com/jira/browse/JBCACHE-31" too.
> I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases.
--
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
17 years, 5 months
[JBoss JIRA] Commented: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours
by Tony Starks (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-33?page=comments#action_12348138 ]
Tony Starks commented on JGRP-33:
---------------------------------
Bela, i am experienceing a similar problem as the issue author.
Where can one check whether or not the sender ever receives its own messages ?
> JGroups throws OutOfMemoryError after running for a few hours
> -------------------------------------------------------------
>
> Key: JGRP-33
> URL: http://jira.jboss.com/jira/browse/JGRP-33
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.2.8
> Environment: SUN JDK 1.4.2_05 & SUN JDK 1.5.0 on Windows & Unix platforms
> Reporter: B.S.Navin
> Assigned To: Bela Ban
> Fix For: 2.2.8
>
> Attachments: fc-fast-udp-tcpping.xml, fc-fast-udp.xml, JGroupsMemTest.java, PublishThread2.java, runj10.sh
>
>
> I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals.
> The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances.
> I have run the program on unix and windows machines with 1G RAM.
> Not able to make much from an HProf output of one of the instances.
> This seems to be the cause for the JBossCache bug "http://jira.jboss.com/jira/browse/JBCACHE-31" too.
> I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases.
--
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
17 years, 6 months