[Design of Messaging on JBoss (Messaging/JBoss)] - Adding Ordering Group Features in JBM 1.4
by gaohoward
https://jira.jboss.org/jira/browse/JBMESSAGING-1416
I'm trying to add this feature to JBM 1.4 following the BEA's weblogic Unit Of Order idea. Below is a draft design and I'm considering Tim's suggestion to make changes to our MessagingQueue to implement it. The implementation detail will be posted later as I need more time to understand our code. Please help to review and see if anything is wrong or missing.
I Enable Ordering Group by programming
JBossMessageProducer::setOrderingGroup(); //sys generated name
JBossMessageProducer::setOrderingGroup(String name); //user specified name
The two methods enable/disable the JBossMessageProducer to produce messages that belong to a named ordering group. Messages in a named ordering group will be processed strictly in the order they are produced (sent). Calling setOrderingGroup(null) will reset the producer to be a normal JMS producer.
Once thus set, the producer will set a reserved message property JBM_ORDERING_GROUP_ID to the name of the ordering group on each message sent through it.
JBossMessages that have this property set are treated as ordering group messages and those that have one same value form an ordering group.
Other Processing Rules of Ordering Group Messages
1. The order of delivery will not be affected by sort criteria, priority, or filters.
2. Only if one message has been processed (acked, committed, rolled back, expired) can next message be delivered.
3. Uncommitted or unacked Messages in one ordering group must be within the same JMSSession or same transaction.
4. The processing of ordering group messages applies to both Queues and Topics.
II Enable Ordering Group by Administration
1. A ConnectionFactory can be configured to have ordering group enabled by default, i.e. all producers created from this factory have ordering group enabled. The user can override the default ordering group settings on the producer later by calling setOrderingGroup() methods.
2. A Destination can be configured to have ordering group enabled by default, i.e., any messages sent to this destination will automatically set to belong to the configured default ordering group if they haven't already belonged to one.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180470#4180470
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180470
15 years, 8 months
[Design of JBoss jBPM] - Re: Process/task search based on variables
by brittm
anonymous wrote : Performant? How performat? Can you be concrete? (Total number of process instances/task instances/new task instances per day/number of concurrent users...)I
Well, certainly performant enough for anything that I would consider a typical task management system. Look at the simple query:
--TASK AGING
| select distinct
| pd.name_ AS process,
| ti.id_ AS task_id,
| tsk.name_ AS task,
| ti.actorid_ as assignee,
| ti.create_ as create_date,
| ti.duedate_ as due_date
| from
| jbpm_taskinstance ti,
| jbpm_task tsk,
| jbpm_token t,
| jbpm_processinstance pi,
| jbpm_processdefinition pd
| where
| ti.end_ is null
| and ti.task_ = tsk.id_
| and ti.token_ = t.id_
| and pi.id_ = t.processinstance_
| and pd.id_ = pi.processdefinition_
| ;
This is a very simply query, and limiting results to those tasks assigned to a particular actor or to tasks from a particular processInstance is obviously trivial. There are only four inner joins on columns that can (or should) be indexed. Add in one more inner join to a "Business Keys" table, and you can return all tasks based on any of your business keys.
If a query this simple is a performance concern, it is because you're truly dealing with many millions of rows or you're returning too many rows at once. I haven't seen a use case for a task management system that would really have many millions of rows, and data returned to a UI from the database should be paginated as part of the query (a user can't visually process more than 20 or 30 rows at a time, so don't force the user or the UI to handle much more than that.)
I don't know really how many "transactions" we've got going on in the course of a day, but I do know that with the simple data relationships in jBPM and our business key table and with the relatively small data sets we're consuming, any performance degradation will be the fault of our own business/UI tier design. For a modern data base, stored row count won't be a practical impact.
Our current application is a Seam/JPA app. We have about 70 group queues with maybe 300 users. We have a particular view in which users can see a series of tabs representing each group queue to which they belong or manage. They can select one of the tabs and will see the tasks in that queue. When a manager selects a group queue to view, in the body of the tab they are presented with two lists of the first 10 assigned tasks and the first 10 unassigned tasks in that queue (each listing is sorted by task priority and due date). If necessary, they can page through the tasks 10 at a time (going back to the data base each time). Each row communicates relevant task data from the task table in addition to customer name, account number, order number, and any associated jeopardy data.
For myself, when I look at this screen (being a universal manager in the system) I see all 70 group queues listed in 70 tabs down the left, each displaying how many unassigned tasks are in that queue. Clicking on a queue to view its tasks (the two tables of assigned and unassigned tasks) seems to take just at 2 seconds regardless of how many underlying tasks there are in the queue.
The view of an individual's personal queue (all tasks assigned to that actor) takes just at a second to present.
Of course any "report view" of the data is exactly that--a report--and the user can be expected to wait several seconds.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180373#4180373
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180373
15 years, 8 months
[Design of POJO Server] - Re: Testing Bootstrap Dependencies
by smcgowan＠redhat.com
With the introduction of this new test logic, there are 93 new test failures seen in the AS 5 testsuite. The 93 failures are related to the deployment of two test jars, cmp2-jbas979.jar and cmp2-simple.jar. The deployment fails because the classes
org.jboss.test.deployers.jbas5349.ejb2.DummyStatefulBean and org.jboss.test.deployers.jbas5349.ejb2.SimpleEntityBean
cannot be loaded.
|
| 2008-10-03 15:30:43,835 DEBUG [org.jboss.deployment.MappedReferenceMetaDataResolverDeployer]
| (RMI TCP Connection(4)-127.0.0.1) Processing unit=cmp2-simple.jar, structure: cmp2-simple.jar
|
| +EjbEndpoint:ejbName=SimpleEntityEJB,ejbClass=org.jboss.test.deployers.jbas5349.ejb2.SimpleEntityBean
|
| 2008-10-03 15:30:43,891 DEBUG [org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerEJB]
| (RMI TCP Connection(4)-127.0.0.1) Error during deploy: vfszip:/NotBackedUp/smcgowan/TRUNK/trunk/testsuite/output/lib/cmp2-simple.jar
| java.lang.RuntimeException:
| Failed to load component class org.jboss.test.deployers.jbas5349.ejb2.SimpleEntityBean.
| Loader:BaseClassLoader@ff5996{vfszip:/NotBackedUp/smcgowan/TRUNK/trunk/testsuite/output/lib/cmp2-simple.jar}
| at org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerEJB$WebServiceDeclarationAdapter.getComponentClass(WebServiceDeployerEJB.java:182)
| at org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerEJB$WebServiceDeclarationAdapter.getAnnotation(WebServiceDeployerEJB.java:166)
| at org.jboss.wsf.container.jboss50.deployer.JAXWSDeployerHookEJB3.isWebServiceBean(JAXWSDeployerHookEJB3.java:123)
| at org.jboss.wsf.container.jboss50.deployer.JAXWSDeployerHookEJB3.isWebServiceDeployment(JAXWSDeployerHookEJB3.java:110)
| at org.jboss.wsf.container.jboss50.deployer.AbstractDeployerHookEJB.deploy(AbstractDeployerHookEJB.java:39)
| at org.jboss.wsf.container.jboss50.deployer.AbstractWebServiceDeployer.internalDeploy(AbstractWebServiceDeployer.java:60)
| at org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerEJB.internalDeploy(WebServiceDeployerEJB.java:119)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:169)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1285)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1003)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:944)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:627)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:812)
| at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:587)
|
|
Ivo, did you see this in your local test run?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180363#4180363
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180363
15 years, 8 months
[Design of JBoss jBPM] - Re: Process/task search based on variables
by frantisek.kocun＠gmail.com
"brittm" wrote : I would second what Ronald mentioned earlier about not trying too hard to store business keys in JBPM. We have a need to be able to look up processes (and tasks) very quickly by any one of various business keys: account number, order number, product number, etc. We created a "Business Keys" table that contains a row for each process instance and records any of the appropriate business key data in the appropriate column. All columns are indexed.
Good idea, I will try it out.
"brittm" wrote : This solution is very performant. Because JBPM has some very direct relationships between processInstance, token, and taskInstance, returning the right tasks based on those business keys is performant as well.
|
Performant? How performat? Can you be concrete? (Total number of process instances/task instances/new task instances per day/number of concurrent users...)I am really interested in this,cos I have never seen jBPM in a big application.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180341#4180341
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180341
15 years, 8 months
[Design of JBoss jBPM] - Re: Process/task search based on variables
by brittm
I would second what Ronald mentioned earlier about not trying too hard to store business keys in JBPM. We have a need to be able to look up processes (and tasks) very quickly by any one of various business keys: account number, order number, product number, etc. We created a "Business Keys" table that contains a row for each process instance and records any of the appropriate business key data in the appropriate column. All columns are indexed.
This solution is very performant. Because JBPM has some very direct relationships between processInstance, token, and taskInstance, returning the right tasks based on those business keys is performant as well.
To populate the table, the act of starting each processInstance calls an ActionHandler that looks up all the pertinent business keys based on our business logic and domain model.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180333#4180333
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180333
15 years, 8 months