-
1. Re: Asynchronous processing future
tom.baeyens Feb 17, 2006 9:54 AM (in response to jimrigsbee)these things would indeed make sense.
currently there is a simplistic asynchronous messaging system build-in into jbpm. it is replacable with JMS.
the next thing is a command framework. commands can be sent to the command executor. the command executor runs in a different thread and listens to the commands that are send on the asyncronous messaging system. When a command arrives, the command executor just executes it.
In the current implementation, only 2 commands are used
1) ExecuteNodeCommand: this command is sent when an asynchronous node is about to be executed. The command will invoke the execute method on the node and that will resume the execution asynchronously. That is to support asynchronous continuations.
2) ExecuteActionCommand: this command simple executes an action.
Other commands are envisioned, but not yet completed. Sending signals, updating variables, finishing tasks, ... most of the jbpmContext operations should be offered as commands so that they can be executed asynchronously.
Does this answer your question ?
regards, tom. -
2. Re: Asynchronous processing future
jimrigsbee Feb 17, 2006 11:41 AM (in response to jimrigsbee)Yes, thanks. That matches what I saw in the source code. Do you have a timeframe in mind for this?
Thanks, Jim -
3. Re: Asynchronous processing future
jimrigsbee Feb 28, 2006 10:36 PM (in response to jimrigsbee)Tom,
Can I pursue this for 3.2?
Jim -
4. Re: Asynchronous processing future
tom.baeyens Mar 1, 2006 4:23 AM (in response to jimrigsbee)Absolutely !
I'm interested to hear your thoughts on where you want to get started.
This is where i think the first work needs to be done:
* get the JmsMessageServiceFactoryImpl working. i just wrote it against the javadoc APIs... probably it is not yet complete.
* also an MDB is lacking to execute the commands
* then we should find out and document what has to be changed in the configuration to replace the default message service with the JMS based message service.
* then a few test cases with the JMS message service
* then adding/finishing some org.jbpm.command.* commands for sending signals and finishing tasks.
what are your ideas ?
regards, tom. -
5. Re: Asynchronous processing future
jimrigsbee Mar 1, 2006 7:16 AM (in response to jimrigsbee)Tom,
You pretty much hit all the points. We need to make sure we deal with transactions with JMS the way you did with DB messages. Might need a JTA transaction for this so that the DB and JMS message sources are dually committed.
I would like to refactor the command thread so that the core logic can be shared by this thread and the MDB. The main control structure of how the thread works and gets invoked, etc. don't need to change.
Looks like we need to add a few commands for initiating a process instance, but otherwise looks like that most of the items are there.
I'll create a JIRA issue as a feature.
My company is really interested in these features to save them big $$$ by switching to jBPM.
Regards, Jim -
6. Re: Asynchronous processing future
jimrigsbee Mar 1, 2006 7:19 AM (in response to jimrigsbee)Need to clarify one point from previous post: dual commit is for taking the message off the queue and committing the work done by hibernate to persist the graph.
Jim -
7. Re: Asynchronous processing future
edgarpoce Mar 1, 2006 7:37 AM (in response to jimrigsbee)Great to hear the JMS stff is moving!!!. I'll be happy to test it ;)
br,
edgar -
8. Re: Asynchronous processing future
jimrigsbee Mar 1, 2006 9:16 AM (in response to jimrigsbee)Edgar,
Great I'll take you up on that...stay tuned to this post.
Regards, Jim -
9. Re: Asynchronous processing future
tom.baeyens Mar 1, 2006 9:29 AM (in response to jimrigsbee)"jimrigsbee" wrote:
Might need a JTA transaction for this so that the DB and JMS message sources are dually committed.
yes, exactly my thoughts too."jimrigsbee" wrote:
I would like to refactor the command thread so that the core logic can be shared by this thread and the MDB. The main control structure of how the thread works and gets invoked, etc. don't need to change.
Not sure about this. I was thinking of throwing runtime exceptions in the MDB was the way to go. The the message queue could be configured to put the message in the error queue after x number of retries.
Then you leave the transaction rollback and the moving of the message to the error queue to the JMS implementation.
Within this approach, parts of the command executor might still be reusable. It would be great if you refactor to allow reuse for those parts.
I was thinking of serializing the commands to a binary message. I think that would require a readResolve implementation on the commands to rebind the persistent objects to the new persistence session."jimrigsbee" wrote:
Looks like we need to add a few commands for initiating a process instance, but otherwise looks like that most of the items are there.
FYI: only the ExecuteNodeCommand and the ExecuteActionCommand are tested. The others show the ideas that i got in mind but are still untested."jimrigsbee" wrote:
My company is really interested in these features to save them big $$$ by switching to jBPM.
that's the idea :-)
regards, tom. -
10. Re: Asynchronous processing future
ralfoeldi Mar 1, 2006 3:16 PM (in response to jimrigsbee)Hi guys,
Tom asked my to write up my experience with jBPM and JMS. It's still in a rough version. I hope I'll get around to documenting / explaining more during the next days.
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBPMJMS
Any comments welcome.
Greetings
Rainer