[jBPM] New message: "configuring Job Executors in Jbpm4"
by Tony D
User development,
A new message was posted in the thread "configuring Job Executors in Jbpm4":
http://community.jboss.org/message/529326#529326
Author : Tony D
Profile : http://community.jboss.org/people/tony2010
Message:
--------------------------------------------------------------
Hi,
I have added following job executor configuration in jbpm.cfg.xml.
* <process-engine-context>
<job-executor nbrOfThreads="4" idleMillis="15000" idleMillisMax="60000" lockMillis="3600000" />
</process-engine-context>*
But whenever i get an object of job executor and get the number of threads it gives me as 3 which is the default in JobExecutor.java.
Is this configuration correct or i am missing something. Please let me know if there is any site which give the details about the jbpm configuration and their node names and attributes(XSD)
Any Help would be highly appreciated.
Thanks in advance.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529326#529326
16 years, 1 month
[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
16 years, 1 month
[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
16 years, 1 month
[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
16 years, 1 month
[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
16 years, 1 month