March 2010 - jboss-user - Jboss List Archives

[Performance Tuning] New message: "JMS Message Queueing bottleneck"

by Sudarshan Sharma

User development, A new message was posted in the thread "JMS Message Queueing bottleneck": http://community.jboss.org/message/529324#529324 Author : Sudarshan Sharma Profile : http://community.jboss.org/people/sks4jboss Message: -------------------------------------------------------------- We are using jboss-4.0.2. I have around 1500 queues into my application. There are seperate threads for each queues. All thread dumps have the usual pattern that most of threads are waiting for the following lock. Even the threads that work on seperate Queues have to wait for the same lock. Is there anyway, I can prevent this locking/bottleneck ? Atleast it will be great if threads working on different queues don't have to wait for the same lock. Application will then be able to scale well. "MessageProcessor1" prio=5 tid=0x03ea7a38 nid=0xee4 waiting for monitor entry [4fdde000..4fddfc30] at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getPool(JBossManagedConnectionPool.java:660) - waiting to lock <*0xb5c6d410*> (a java.util.HashMap) at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:514) at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:395) at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:297) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:447) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:874) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:103) at org.jboss.mq.pm.jdbc2.PersistenceManager.getConnection(PersistenceManager.java:1368) at org.jboss.mq.pm.jdbc2.PersistenceManager.loadFromStorage(PersistenceManager.java:1176) at org.jboss.mq.server.MessageCache.loadFromStorage(MessageCache.java:402) at org.jboss.mq.server.MessageReference.makeHard(MessageReference.java:350) - locked <0xd8cc50c8> (a org.jboss.mq.server.MessageReference) at org.jboss.mq.server.MessageReference.getMessage(MessageReference.java:155) - locked <0xd8cc50c8> (a org.jboss.mq.server.MessageReference) at org.jboss.mq.server.MessageReference.getHeaders(MessageReference.java:248) at org.jboss.mq.server.BasicQueue.receive(BasicQueue.java:508) - locked <0xc239efd0> (a java.lang.Object) - locked <0xc239f000> (a org.jboss.mq.server.ReceiversImpl) at org.jboss.mq.server.JMSQueue.receive(JMSQueue.java:136) at org.jboss.mq.server.ClientConsumer.receive(ClientConsumer.java:222) at org.jboss.mq.server.JMSDestinationManager.receive(JMSDestinationManager.java:656) at org.jboss.mq.server.JMSServerInterceptorSupport.receive(JMSServerInterceptorSupport.java:226) at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:100) at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:570) at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226) at org.jboss.mq.il.jvm.JVMServerIL.receive(JVMServerIL.java:244) at org.jboss.mq.Connection.receive(Connection.java:909) at org.jboss.mq.SpyMessageConsumer.receive(SpyMessageConsumer.java:398) - locked <0xd8d43620> (a java.util.LinkedList) ......... ......... Many thanks in Advance. Any input will be greatly appreciated. Regards, Sudarshan -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529324#529324

14 years, 9 months

1
0
0 / 0

[JBoss Web Services] New message: "Re: Unable to verify SOAP packet encryption"

by Keshav Savant

User development, A new message was posted in the thread "Unable to verify SOAP packet encryption": http://community.jboss.org/message/529323#529323 Author : Keshav Savant Profile : http://community.jboss.org/people/kcsavant Message: -------------------------------------------------------------- Yes Peter, I have tried with both the options but no luck. I did this by commenting the code lines that are setting the properties. I already posted my client setup above. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529323#529323

14 years, 9 months

1
0
0 / 0

[jBPM] New message: "Re: How to create a graphical collection of already defined tasks?"

by Robert Weissmann

User development, A new message was posted in the thread "How to create a graphical collection of already defined tasks?": http://community.jboss.org/message/529318#529318 Author : Robert Weissmann Profile : http://community.jboss.org/people/wir33658 Message: -------------------------------------------------------------- Hm, a fair statement "exotic process". I work in the semiconductor industry an we have tons of so called operations (tasks if you want) at the production level which will be reused again and again (just with different parameters). -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529318#529318

14 years, 9 months

1
0
0 / 0

[JBoss Cache] New message: "Re: Weblogic with JBossCache2"

by Galder Zamarreno

User development, A new message was posted in the thread "Weblogic with JBossCache2": http://community.jboss.org/message/529308#529308 Author : Galder Zamarreno Profile : http://community.jboss.org/people/galder.zamarreno@jboss.com Message: -------------------------------------------------------------- If JNDI is giving you issues, why not use the standard multiplexed factory as indicated in http://www.jboss.org/file-access/default/members/jbossclustering/freezone... Instead of giving the JNDI name, use the multiplexed version and and define hibernate.cache.jbc.configs only if you're modifying the default cache configuration. By the way, you should try using Infinispan as 2 level cache provider rather than JBoss Cache since it's faster and consumes a lot less memory . See http://community.jboss.org/docs/DOC-14105 -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529308#529308

14 years, 9 months

1
0
0 / 0

[EJB 3.0] New message: "Re: EJB 2 Deployment issue on JBoss 5"

by Manigandan R

User development, A new message was posted in the thread "EJB 2 Deployment issue on JBoss 5": http://community.jboss.org/message/529307#529307 Author : Manigandan R Profile : http://community.jboss.org/people/manigandan5986 Message: -------------------------------------------------------------- Dileep, I am facing a similar issue. A resource adapter that used to work with JBoss 4 is now not working with JBoss 5.1.1. And I get the error : 16:09:18,221 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:RA-Name-masked-ra.rar/ state=ClassLoader mode=Manual requiredState=PostClassLoader org.jboss.deployers.spi.DeploymentException: Cannot process metadata at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181) .... at org.jboss.Main$1.run(Main.java:556) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: Empty class name '' at org.jboss.classloader.plugins.ClassLoaderUtils.checkClassName(ClassLoaderUtils.java:52) at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:416) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossClientMetaData(OptAnnotationMetaDataDeployer.java:115) at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:82) at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177) ... 32 more Were u able to work around the issue? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529307#529307

14 years, 9 months

1
0
0 / 0

[JBoss Cache] New message: "Re: Flushing data to disk"

by Galder Zamarreno

User development, A new message was posted in the thread "Flushing data to disk": http://community.jboss.org/message/529304#529304 Author : Galder Zamarreno Profile : http://community.jboss.org/people/galder.zamarreno@jboss.com Message: -------------------------------------------------------------- If you want to use even simpler configuration, use http://www.jboss.org/infinispan/ -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529304#529304

14 years, 9 months

1
0
0 / 0

[JBoss Web Services] New message: "Re: Occasional exceptions out of SOAPAddressingPropertiesImpl.writeHeaders"

by Richard Opalka

User development, A new message was posted in the thread "Occasional exceptions out of SOAPAddressingPropertiesImpl.writeHeaders": http://community.jboss.org/message/529290#529290 Author : Richard Opalka Profile : http://community.jboss.org/people/richard.opalka@jboss.com Message: -------------------------------------------------------------- Thanks for pointing out this hot deploy issue Andrew. We will have a look. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529290#529290

14 years, 9 months

1
0
0 / 0

[JBoss Web Services CXF] New message: "Re: : mapped-name is required for cxf of deployment auto-update-ws.war"

by Not available Not available

User development, A new message was posted in the thread ": mapped-name is required for cxf of deployment auto-update-ws.war": http://community.jboss.org/message/529289#529289 Author : Not available Not available Profile : http://community.jboss.org/people/no1one Message: -------------------------------------------------------------- I had similar problem trying to deploy war-in-ear with webservices & (some of) apache CXF jars included in. Similar exception appeared. When I included annotations-api.jar in the war file and turned on classloading isolation, the exception dissapeared and everything worked perfectly. I suspect (not sure) that CXF has it's own mechanism of resource injection which uses @javax.annotation.Resource annotation, and all properties annotated with @Resource aren't supposed to be injected by JBoss in deploytime, but exactly that happens. If annotations-api.jar is present, and classloading isolation is on - then jboss will not detect @Resource annotations in cxf and will not try to inject them (because Resource.class from annotations-api.jar will overwrite Resource.class from jboss in CXF's classloader, and for JVM point of view, CXF's @Resource annotation will be different than jboss'es @Resource annotations). -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529289#529289

14 years, 9 months

1
0
0 / 0

[Javassist Development] New message: "A few Javassist proxy patches"

by Mark Struberg

User development, A new message was posted in the thread "A few Javassist proxy patches": http://community.jboss.org/message/529280#529280 Author : Mark Struberg Profile : http://community.jboss.org/people/struberg Message: -------------------------------------------------------------- Hi! I'm working on Apache OpenWebbeans and we use javassist - so first of all thanks for providing it! I found a few issues which are mainly based on the way javassist got used in many projects, which caused loss of permgenspace with every invocation. I tried to address this with a few patches. The problem is caused by the current javassist usage pattern of calling ProxyFactory.createClass().newInstance() which currently (due to the broken cache), always creates a new class for the proxy. And once this class gets classloaded, you cannot easily get rid of it from the ClassLoaders class map. In the worst case the generated proxy class gets registered in the SystemClassLoader and can never get freed again. Another problem is that setting the default method handler with ProxyFactore.setMethodHandler() will store this MethodHandler in a static field, thus the class will hold a reference to this MethodHandler - even if it is not used anymore. Thus the MethodHandler (and all the instances it references) imo can never get garbage collected. There were also a few problems with deserialization, mainly because it did drop the assigned MehodHandler and used the DefaultMethodHandler instead. I added new bytecode to support MethodHandler serialization along with the proxyInstance. To understand my need: instead of creating a fresh proxyClass every time, I switched OWB to use the following pattern 1.) ProxyFactory.useCache = false; since the current implementation fo the internal class cache imo inherently creates mem losses 2.) create the ProxyFactory only once and cache this class in our own code: 2.a) ProxyFactory pf = new ProxyFactory() 2.b) pf.setInterfaces(...); 2.c) pf.setSuperclass(...); 2.d) Class proxyClass = pf.creatClass(); 3.) create a new proxy instance with it's own MethodHandler by always only using the same cached proxy Class for a certain original class Object proxyInstance = proxyClass.newInstance(); + ((ProxyObject)proxyInstance).setHandler(new BeanMethodHandler(beaninfo)); I didn't really need the MethodFilter in my use cases, so we need think about where this fits into the picture. Most foundings are explained in my patches available at github http://github.com/struberg/javassist Those patches are tested with OpenWebBeans and Weld (thanks to David R. Allen), but I'm sure there is still room for improvement One of the areas I'm not 100% sure is deserialization on another VM which may already contain other proxy classes of that kind (with different javassist name). I now check if the interfaces and the superclass is the same if I found a javassist proxyClass with Class.forName on deserialization, maybe there is something missing still. This szenario mainly may concern replication in big clusters, and the behaviour of the patched version is of course heavily improved at least. Oh yes, we should really cleanup the pom.xml! I can volunteer with all the maven stuff too if needed. txs and LieGrue, strub -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529280#529280

14 years, 9 months

1
0
0 / 0

[JBoss Tools] New message: "Re: working with XDoclet at JbossTools 3.0.3GA"

by Kobi Ianko

User development, A new message was posted in the thread "working with XDoclet at JbossTools 3.0.3GA": http://community.jboss.org/message/529277#529277 Author : Kobi Ianko Profile : http://community.jboss.org/people/kobiianko Message: -------------------------------------------------------------- So, I'm guessing I'll have to work manually with the xdoclet-build.xml file, if I want to update the xdoclet configuration -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529277#529277

14 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-user March 2010