[JBoss JIRA] Created: (JBWEB-94) JBoss Web 2.1.0
by Remy Maucherat (JIRA)
JBoss Web 2.1.0
---------------
Key: JBWEB-94
URL: http://jira.jboss.com/jira/browse/JBWEB-94
Project: JBoss Web
Issue Type: Release
Security Level: Public (Everyone can see)
Reporter: Remy Maucherat
Assigned To: Mladen Turk
Based on Apache Tomcat 6.0.x, with the following changes:
- Swicth to JBoss logging from Apache Commons Logging.
- Remove Tomcat standalone session clustering.
- Add a system property to delay startup of connectors for JBoss.
- Add context listener configuration.
- Expanded Comet API as a separate package.
- Remove user database functionality (no development of it since Tomcat 4.1).
- Add rewrite valve and PHP servlet from JBoss Web 2.0.
- Use a system property for the session cookie name.
- Remove HTTP NIO connector.
- Remove legacy org.apache.jk AJP connector and utility components.
--
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
16 years, 3 months
[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
16 years, 3 months
[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
16 years, 3 months
[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
16 years, 3 months
[JBoss JIRA] Created: (JBAS-4287) run.sh can consume 100% single CPU resources on Solaris
by Quenten Alick (JIRA)
run.sh can consume 100% single CPU resources on Solaris
-------------------------------------------------------
Key: JBAS-4287
URL: http://jira.jboss.com/jira/browse/JBAS-4287
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: JBossAS-4.0.5.GA
Environment: Solaris on SPARC (version 9 & 10)
Reporter: Quenten Alick
When shutting down jboss the run.sh script remain alive and consumes 100% of a single CPUs resources. run.sh needs to be killed off.
To trigger the bug, you need to
1) set LAUNCH_JBOSS_IN_BACKGROUND
2) start the jboss server normally
3) Once it's started stop the server
At this point the JVM stops, however the run.sh script remains running consuming 100% of a single CPUs resources.
The problem seems to be this bit of script, plus the fact that the script shebang is #!/bin/sh
while [ "$WAIT_STATUS" -ne 127 ]; do
JBOSS_STATUS=$WAIT_STATUS
wait $JBOSS_PID 2>/dev/null
WAIT_STATUS=$?
done
On Solaris, /bin/sh is *real* bourne shell and the wait shell-built-in for /bin/sh on Solaris returns 0 (not 127) if the PID (passed as an argument) doesn't exist. The man page for wait states that this is the correct behaviour. Therefore wait returns 0 and the while loop continues forever burning up CPU resources (until you kill it with one of the signals not being trapped).
Here's a link to the patch that may have introduced the bug.
http://jira.jboss.com/jira/browse/JBAS-3748
--
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
16 years, 3 months