July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBWEB-74) tomcat config files fail to support default sysprop values like other jboss-service.xml type configs

by John Mazzitelli (JIRA)

tomcat config files fail to support default sysprop values like other jboss-service.xml type configs ---------------------------------------------------------------------------------------------------- Key: JBWEB-74 URL: http://jira.jboss.com/jira/browse/JBWEB-74 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Reporter: John Mazzitelli Assigned To: Mladen Turk >From my JBoss forum post and Dimitris' reply: In jboss-service.xml, you can define values via properties like this: ${my.prop:123} where the value will be 123 if and only if my.prop property is not explictly set. However, this syntax does not seem to work on JBossAS 4.0.5 within the jbossweb-tomcat55.sar's server.xml. If I use ${my.prop} in server.xml, it works fine. But if I define a default value like ${my.prop:123}, it doesn't work - the value becomes literally ${my.prop}. Dimitris Andreadis reply: "JBoss uses org.jboss.util.StringPropertyReplacer for substituting variables. Tomcat/jboss-web must be using a different way to do this, so this is really a feature request for jboss-web." -- 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, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-905) Perform code coverage analysis and add missing unit tests

by Manik Surtani (JIRA)

Perform code coverage analysis and add missing unit tests --------------------------------------------------------- Key: JBCACHE-905 URL: http://jira.jboss.com/jira/browse/JBCACHE-905 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Hany Mesha Fix For: 1.4.1.GA, 2.0.0.GA Using a code coverage tool like Clover: 1) Analyse current test suite on Branch_JBossCache_1_4_0 2) Put up results on a wiki page 3) Link wiki page to this JIRA task as well as the JBossCache wiki page 4) Analyse gaps in the test suite and either document (on the wiki) as being too simple/obvious to test or create a unit test for this. Once 2.0.0 reaches CR1, perform the same on HEAD (or Branch_JBossCache_2_0_0 by then...) -- 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, 2 months

6
32
0 / 0

[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, 2 months

4
4
0 / 0

[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, 2 months

5
33
0 / 0

[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, 2 months

2
11
0 / 0

[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

18 years, 2 months

4
16
0 / 0

[JBoss JIRA] Created: (JBCACHE-1151) Switch to using MVCC for locking, drop Pessimistic and Optimistic locking

by Manik Surtani (JIRA)

Switch to using MVCC for locking, drop Pessimistic and Optimistic locking ------------------------------------------------------------------------- Key: JBCACHE-1151 URL: http://jira.jboss.com/jira/browse/JBCACHE-1151 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.4.1.GA, 1.4.0.GA, 2.0.0.GA Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 3.x Forum ref http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064626#4064626 Wiki with design details http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheMVCC -- 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, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-511) FC: dynamically adjust credits

by Bela Ban (JIRA)

FC: dynamically adjust credits ------------------------------ Key: JGRP-511 URL: http://jira.jboss.com/jira/browse/JGRP-511 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 FC currently has a static number of credits (max_credits). It would be beneficial to implement something similar to TCP's exponential backoff and slow start, to take the message loss rate into account. Goal: when there is an overload, we reduce the credits in order to avoid compounding the overload by sending messages. On the other hand, we can send more messages when the receiver(s) have free capacity. To do this, each receiver sends the number of credits it can accept with its responses. By default, this would be the default number of credits (in TCP: size of the sliding window). DESIGN: NAKACK (and/or UNICAST) send the loss rate (rolling average of number of messages missing over number of messages received, per sender) when it exceeds a certain value (defined in NAKACK,UNICAST) up the stack. FC looks at the loss rate and slices the number of credits for that sender in half (exponential backoff). On the next response, it piggy backs the new number of credits, so that sender will block sending messages. When the loss rate drops below a certain (predefined) value, NAKACK sends another event up the stack. FC then increases the credits by a predefined value (slow start). Next time, it increases the value by the predefined value by 2 and so on, until the max number of credits have been reached again. -- 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, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBWEB-68) Servlet.init(ServletConfig) not called

by Thomas Diesler (JIRA)

Servlet.init(ServletConfig) not called -------------------------------------- Key: JBWEB-68 URL: http://jira.jboss.com/jira/browse/JBWEB-68 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler Assigned To: Remy Maucherat <componentref name="apache-tomcat" version="6.0-snapshot"/> [tdiesler@tdvaio trunk]$ svn info Path: . URL: https://svn.jboss.org/repos/jbossas/trunk Repository Root: https://svn.jboss.org/repos/jbossas Repository UUID: 84be2c1e-ba19-0410-b317-a758671a6fc1 Revision: 55837 Node Kind: directory Schedule: normal Last Changed Author: rrajesh Last Changed Rev: 55837 Last Changed Date: 2006-08-11 22:26:36 +0200 (Fri, 11 Aug 2006) <servlet> <servlet-name>TestService</servlet-name> <servlet-class>org.jboss.test.ws.jaxws.endpoint.EndpointServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> -- 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, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-4511) CachedConnectionManager valve needs enabling in JBoss5

by Adrian Brock (JIRA)

CachedConnectionManager valve needs enabling in JBoss5 ------------------------------------------------------ Key: JBAS-4511 URL: http://jira.jboss.com/jira/browse/JBAS-4511 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Adrian Brock Assigned To: Remy Maucherat Fix For: JBossAS-5.0.0.Beta3 The CCM valve needs enabling in JBoss5. However, you can no longer just enable due to the issue described on the forum thread. I've temporarily moved the CachedConnectionManager MBean into deployers so Tomcat can depend it, but Tomcat should not be in the deployers. Once Tomcat is fixed, the file deployers/jca-hack-for-tomcat-service.xml needs removing and the FIXMEs in build/build-distr.xml and jbossjca-service.xml reverting. -- 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, 2 months

2
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2007