[JBoss JIRA] Created: (JASSIST-30) Memory Leak - failure to clean up javassisst instances after EJB3 remote calls
by Grant Quimby (JIRA)
Memory Leak - failure to clean up javassisst instances after EJB3 remote calls
------------------------------------------------------------------------------
Key: JASSIST-30
URL: http://jira.jboss.com/jira/browse/JASSIST-30
Project: Javassist
Issue Type: Bug
Environment: JBoss 4.0.4.GA, Windows Xp
JBoss 4.0.4.GA, LInux (Debian)
JBoss 4.0.4.GA, Solaris
Reporter: Grant Quimby
Assigned To: Shigeru Chiba
Priority: Blocker
Quote from related JIRA issue EJBTHREE-736
PermGen in EJB3 client aplication by remote interface.
The application is as sample as it can be:
-get remote interface of stateless EJB3 (by JNDI)
- ask 1000 times to get a Collection (List) of 10 EntityBeans.
After 255 there is OutOfMemory: PermGen.
JVM options changes nothing (eventualy more PermSpace => longer run).
The reason looks like the Javassist create lazyinitializer classes for every EntityBean retrived from the server.
So: When I debug on server-side, I got before sending Entity to client:
I got:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_7> 13434
...
myEntity[0].user=<UserEntity_$$_javassist_15>...
myEntity[0].stage=<StageEntity_$$_javassist_17>...
And every remote call the class names (name)_$..._javassist_(index) got the same
indexes (7,15,17) on server side (end every entity in returned collections of entities)
But when I debug on client site - after return from remote call - the indexes of
all returned entities are different (Each next increments index).
So after first call I got:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_0>...
...
myEntity[0].user=<UserEntity_$$_javassist_1>...
myEntity[0].stage=<StageEntity_$$_javassist_2>...
...
myEntity[1].id=143534
myEntity[1].flow=<FlowEntity_$$_javassist_3>
...
myEntity[1].user=<UserEntity_$$_javassist_4>...
myEntity[1].stage=<StageEntity_$$_javassist_5>...
...
After secund call:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_6>...
...
myEntity[0].user=<UserEntity_$$_javassist_7>...
myEntity[0].stage=<StageEntity_$$_javassist_8>...
...
myEntity[1].id=143534
myEntity[1].flow=<FlowEntity_$$_javassist_9>
...
myEntity[1].user=<UserEntity_$$_javassist_10>...
myEntity[1].stage=<StageEntity_$$_javassist_11>...
...
And so on... ... and permGen after 260 iterations...
--
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
18 years
[JBoss JIRA] Created: (JASSIST-28) javassist enhancement failed on deserializing hibernate proxies
by Armin Haaf (JIRA)
javassist enhancement failed on deserializing hibernate proxies
---------------------------------------------------------------
Key: JASSIST-28
URL: http://jira.jboss.com/jira/browse/JASSIST-28
Project: Javassist
Issue Type: Bug
Environment: hibernate 3.2.0GA, javassist 3.3, jboss 4.0.4GA
Reporter: Armin Haaf
Assigned To: Shigeru Chiba
on deserializing objects load by hibernate on a jbossas with uninitialized proxies we the following exception on a performance/concurrent testing:
Exception in thread "Thread-7" org.hibernate.HibernateException: Javassist Enhancement failed: de.mueller.wms.base.model.impl.StorageImpl
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(JavassistLazyInitializer.java:88)
at org.hibernate.proxy.pojo.javassist.SerializableProxy.readResolve(SerializableProxy.java:54)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1033)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1728)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279)
at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
at org.jboss.remoting.Client.invoke(Client.java:525)
at org.jboss.remoting.Client.invoke(Client.java:488)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
at $Proxy2.executeCommand(Unknown Source)
at de.mueller.wms.base.service.JndiRemoteLookupDelegateImpl$CommandExecutionInvocationHandler.invoke(JndiRemoteLookupDelegateImpl.java:57)
at $Proxy1.changeStock(Unknown Source)
at de.mueller.wms.base.TestJBossPerformance$1.run(TestJBossPerformance.java:58)
Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate class definition: de/mueller/wms/base/model/impl/StorageImpl_$$_javassist_1272
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(JavassistLazyInitializer.java:79)
... 44 more
Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicate class definition: de/mueller/wms/base/model/impl/StorageImpl_$$_javassist_1272
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:167)
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:170)
... 45 more
Caused by: java.lang.LinkageError: duplicate class definition: de/mueller/wms/base/model/impl/StorageImpl_$$_javassist_1272
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159)
... 46 more
The performance is also very bad in comparison with cglib proxies (in our performance test with cglib proxies the test runs 3x faster)
--
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
18 years
[JBoss JIRA] Created: (JBCACHE-811) Use InvocationContext to avoid multiple searches for a node
by Brian Stansberry (JIRA)
Use InvocationContext to avoid multiple searches for a node
-----------------------------------------------------------
Key: JBCACHE-811
URL: http://jira.jboss.com/jira/browse/JBCACHE-811
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Manik Surtani
When an interceptor finds a node, why not throw it in the InvocationContext or something similar and pass it through the stack that way? Subsequent calls to find the node can check the context first before walking the cache tree. Saves redundant walking of the tree.
We'd need to think very carefully about this, as it exposes 2 paths to access a node -- from a thread's context and from the tree. Need to ensure concurrent threads always access the same node object for a given Fqn.
(Side thought -- perhaps disable this for weak isolation levels where the locking behavior in the interceptors make it possible to end up w/ 2 concurrent nodes for the same Fqn).
--
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
18 years
[JBoss JIRA] Created: (JBCLUSTER-150) CNFE issues with Hibernate and JBoss Cache
by Brian Stansberry (JIRA)
CNFE issues with Hibernate and JBoss Cache
------------------------------------------
Key: JBCLUSTER-150
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-150
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: Q4Y6
Hibernate w/ JBC as 2nd level cache can potentially place instances of custom user classes in the cache. Can happen if the query cache is used, since instances of custom classes can be parameters to queries.
This leads to replication or state transfer problems like the following if the custom classes are not visible to JBC's classloader (i.e. the custom classes aren't in server/all/lib). For regular entity caching, Hibernate stores primitives in the cache, so this is less of an issue. Problem is more with the query cache.
java.lang.ClassNotFoundException: No ClassLoaders found for: services.entities.ProductDemandPK
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:511)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:585)
at org.jboss.invocation.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.j
ava:109)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.cache.Fqn.readExternal(Fqn.java:355)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.cache.loader.NodeData.readExternal(NodeData.java:59)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:241)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:271)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:271)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:271)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateTransientState(StateTr
ansferIntegrator_140.java:222)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateTransientState(StateTr
ansferIntegrator_140.java:97)
at org.jboss.cache.TreeCache._setState(TreeCache.java:2640)
at org.jboss.cache.TreeCache.access$000(TreeCache.java:86)
at org.jboss.cache.TreeCache$MessageListenerAdaptor.setState(TreeCache.java:5306)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:614)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:331)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:55
4)
at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
at java.lang.Thread.run(Thread.java:595)
JBC's region-based marshalling API is meant for dealing with this kind of thing. Need to see how Hibernate can be configured to work with this API. Expect this will lead to JIRAs in the Hibernate and possible EBJ3 project.
--
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
18 years
[JBoss JIRA] Created: (JBAS-3426) Fix org.jboss.test.jacc.test.WebIntegrationUnitTestCase in HEAD
by Anil Saldhana (JIRA)
Fix org.jboss.test.jacc.test.WebIntegrationUnitTestCase in HEAD
---------------------------------------------------------------
Key: JBAS-3426
URL: http://jira.jboss.com/jira/browse/JBAS-3426
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security, Web (Tomcat) service
Environment: org.jboss.test.jacc.test.WebIntegrationUnitTestCase(JACC)
as well as org.jboss.test.jacc.test.WebIntegrationUnitTestCase
Reporter: Anil Saldhana
Assigned To: Scott M Stark
Fix For: JBossAS-5.0.0.Beta
There is privileges related exception that is showing up in HEAD whereas in Branch_4_0, does not show up.
=======================================================================================
10:37:07,843 INFO [ENCServlet] InitialContext.env:
10:37:07,843 INFO [ENCServlet] Key: java.naming.factory.initial, value: org.jnp.interfaces.NamingContextFactory
10:37:07,843 INFO [ENCServlet] Key: java.naming.factory.url.pkgs, value: org.jboss.naming:org.jnp.interfaces:org.jboss.naming:org.jnp.interfaces
10:37:07,890 ERROR [[invoker]] Allocate exception for servlet invoker
java.lang.SecurityException: Servlet of class org.apache.catalina.servlets.Invok
erServlet is privileged and cannot be loaded by this web application
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.
java:1114)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:784)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:174)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
=========================================================================================
Something changed in TC6 as to how web apps can invoke the container servlets?
--
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
18 years, 1 month