[EJB/JBoss] - Help configure MDB threads
by gturner
Under JBoss 4.0 and earlier versions I had an MDB with the following jboss.xml deployment descriptor:
| <jboss>
| <enterprise-beans>
| <message-driven>
| <ejb-name>LoggingMDB</ejb-name>
| <destination-jndi-name>queue/loggingQueue</destination-jndi-name>
| <configuration-name>LoggingMDB Message Driven Bean</configuration-name>
| </message-driven>
| </enterprise-beans>
| <container-configurations>
| <container-configuration extends="Standard Message Driven Bean">
| <container-name>LoggingMDB Message Driven Bean</container-name>
| <container-pool-conf>
| <MinimumSize>1</MinimumSize>
| <MaximumSize>100</MaximumSize>
| <strictMaximumSize>false</strictMaximumSize>
| </container-pool-conf>
| <depends>xo.services:service=ConfigurationManager</depends>
| </container-configuration>
| </container-configurations>
| </jboss>
|
It worked, the MDB would scale up to 100 threads.
However now we've upgraded our servers to JBoss 4.2.3, and the MDB seems to be limited to 15 threads.
As a first step in fixing this, I updated the MDB code/packaging to EJB3 with annotation such as:
| @MessageDriven
| (activationConfig={
| @ActivationConfigProperty(propertyName="destinationType",
| propertyValue="javax.jms.Queue"),
| @ActivationConfigProperty(propertyName="destination",
| propertyValue="queue/loggingQueue"),
| @ActivationConfigProperty(propertyName = "maxSession",
| propertyValue = "100")})
|
However it still seems to be limited to 15 threads.
Reviewing random bits of unorganized wiki documentation I found the answer may be in deploy/ejb3-interceptors-aop.xml:
| <domain name="Message Driven Bean">
| ...
| <annotation expr="!class((a)org.jboss.annotation.ejb.PoolClass)">
| @org.jboss.annotation.ejb.PoolClass (value=org.jboss.ejb3.StrictMaxPool.class, maxSize=15, timeout=10000)
| </annotation>
| </domain>
|
Could somebody please explain to me whether it's possible to:
| * Configure these annotations in a separate file, preferably bundled in the EJB jar/ear?
|
| * Affect the pool size of this particular MDB, rather than the default which would affect other MDBs?
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247710#4247710
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247710
16 years, 8 months
[JBoss jBPM] - TaskQuery w/ ProcessInstanceId possible?
by hrworx
I've tried everything I can think of to query tasks by ProcessInstanceId but no matter what, if you put a ProcessInstanceId on a TaskQuery, you get back zero results. The test below runs fine until the last line, when the assertion fails. I have tried substituting different ids in the query, including processInstance.getProcessInstance.getId(), processInstance.getExecutions() and iterating over all the executions and using their ids, and various other attempts without success.
Is it even possible? If anybody can do it, how about pasting a code snippet?
| @Test
| public void testTaskQueryByProcessInstanceId()
| {
|
| TaskQuery taskQueryBefore = getTaskService().createTaskQuery();
| List<Task> taskListBefore = taskQueryBefore.list();
| Assert.assertEquals(0, taskListBefore.size());
|
| ProcessInstance processInstance = createProcessInstance();
| TaskQuery taskQuery = getTaskService().createTaskQuery();
|
| List<Task> taskList = taskQuery.list();
| Assert.assertEquals(2, taskList.size());
|
| TaskQuery taskQuery2 = getTaskService().createTaskQuery();
| taskQuery2.processInstanceId(processInstance.getId());
| List<Task> taskList2 = taskQuery2.list();
|
| Assert.assertEquals(2, taskList2.size());
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247700#4247700
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247700
16 years, 8 months
[JBoss Messaging] - Re: JMSServerControl.createQueue() fails when there are any
by clebert.suconic＠jboss.com
On the JMS example, the only bug I found was the second destination didn' t enter into page mode right away. What should be fixed. But that will mean the destination will enter into page mode right away, so it should fail at the first time.
In your case.. you have the server full. We can't route any more messages until DestinationA had messages being consumed and Acked.
So... what's happening is:
Client sends messages to destinationA.
At this point the server is Full.
Client sends messages to destinationB.
(At this point the server should still be full. DestinationB should page right away, and the consumer shouldn' t receive anything until messages from destinationA were received).
For the management case.. I was suggesting to never page anything. But there is a risk of OME. (If we don't protect it). But as far as I know.. management destinations will aways be consumed or dropped. So.. I guess it would be ok to ignore paging on Management. Maybe the same would apply to temporary queues.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247699#4247699
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247699
16 years, 8 months