[jBPM] - Task Service - large number of generic listeners
by Harjot Narula
Harjot Narula [http://community.jboss.org/people/harjotnarula09] created the discussion
"Task Service - large number of generic listeners"
To view the discussion, visit: http://community.jboss.org/message/594621#594621
--------------------------------------------------------------
I have been playing around with user tasks in jBPM using the default implementation of user tasks. When I close the task, it seems that task service looks for all listeners on that task and sends some messages ..... Now this is what is happening, if I have 2 completed tasks in my DB and I am closing the 3rd task, I see 3 statements on task service console which suggest that possibly the listener on tasks which are closed is still hanging around and listening to task closure events. This thing becomes very annoying when you have a large number of tasks, basically you see a number of statements on console and it seems like it takes more time to complete the task. Has someone else also faced a similar issue?
[java] [2011:03:80 16:03:379:debug] Message receieved on server : Operation
Request
[java] [2011:03:80 16:03:380:debug] Arguments : [Complete, 4, krisv, null,
null]
[java] [2011:03:80 16:03:380:debug] Command receieved on server was operati
on of type: Complete
[java] MessagingTaskEventListener.taskCompleted 4
[java] Found generic listeners: 4
[java] [2011:03:80 16:03:393:debug] Message receieved on server : QueryTask
sAssignedAsPotentialOwner
[java] [2011:03:80 16:03:393:debug] Arguments : [krisv, en-UK]
[java] [2011:03:80 16:03:397:debug] Message receieved on server : GetTaskRe
quest
[java] [2011:03:80 16:03:397:debug] Arguments : [4]
[java] [2011:03:80 16:03:403:debug] Message receieved on server : GetTaskRe
quest
[java] [2011:03:80 16:03:404:debug] Arguments : [4]
[java] [2011:03:80 16:03:412:debug] Message receieved on server : GetTaskRe
quest
[java] [2011:03:80 16:03:413:debug] Arguments : [4]
[java] [2011:03:80 16:03:418:debug] Message receieved on server : GetTaskRe
quest
[java] [2011:03:80 16:03:418:debug] Arguments : [4]
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/594621#594621]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years
[JBoss Messaging] - Configuring ClusteredConnectionFactory on heterogeneous cluster
by Ryan Hochstetler
Ryan Hochstetler [http://community.jboss.org/people/ryanhos] created the discussion
"Configuring ClusteredConnectionFactory on heterogeneous cluster"
To view the discussion, visit: http://community.jboss.org/message/594555#594555
--------------------------------------------------------------
We have a 40+ node JBoss cluster with 4 distinct +server types+ in the cluster (for simplicity, assume 4 types * 10 instances each). The server types all handle different jobs, but need to share some queues, so we have JMS clustered between them. Last week, we exhausted the JMS client pool (*JBM_clientMaxPoolSize*) on one of the servers, so wrote some logic in our provisioning software that builds the 40 nodes to calculate the exact number (plus a margin) needed by each server type, and substitute that value in remoting-bisocket-service.xml.
Server Type A:
<attribute name="JBM_clientMaxPoolSize" isParam="true">235</attribute>
Server Type B:
<attribute name="JBM_clientMaxPoolSize" isParam="true">180</attribute>
..and so forth.
The next time I booted, I got this error from ConnectionFactoryJNDIMapper:
"[ERROR] [org.jboss.messaging.util.ExceptionUtil] - org.jboss.jms.server.connectionfactory.ConnectionFactory@a605722 startService
java.lang.IllegalArgumentException: The remoting locator configuration for a particular clustered connection factory must be the same on each node in the cluster. We have detected that the configuration differs on this node. Please correct and redeploy the connection factory"
This indicates to me that the invoker locator string for a clustered connection factory must be the same throughout the cluster (I imagine because this aids in providing failover to a matching locator elsewhere in the cluster. The JBM_clientMaxPoolSize is part of the invoker locator string because JBoss Messaging ships remoting-bisocket-service.xml with the +isParam+ attribute set to true on that particular XML element.
So, my question is this: How do I tune the JBM_clientMaxPoolSize for the non-clustered connection factory per server type, and at the same time allow the clustered connection factory to still function? Do I set isParam="false" on that attribute so that it doesn't end-up in the invoker locator string (why does the client need this information anyway)? Do I add annother identical, but differently-named org.jboss.remoting.transport.Connector MBean configuration, with the same value for JBM_clientMaxPoolSize across the entire cluster, and then modify the jboss.messaging.connectionfactory:service=ClusteredConnectionFactory MBean configuration in connection-factories-service.xml to point at the new homogenous Connector? I assume that the new connector would require it's own port and binding-service information; is this correct?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/594555#594555]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years