Concurrent childnodes: how to create multithreaded nodes in

[rasun]

Hi there,

As I'm kinda new on this jBPM happening, I'm struggling with a specific way of implementation. I'm not using the GPD, only the PVM. The processdefinition is build in a Java file, no XML.

This is the situation: currently I'm trying to create a multithreaded process. That is, a node (A) that splits as a fork in three sub-nodes (A1, A2 and A3). All three childnodes need to run at the same time.
After that they need to merge into one node (B), which is the last node of the process.

Now I've been trying to implement the examples I've seen here and there online (forEachForkActionHandler and other global documentation). But they don't seem to work out as I want: no concurrency to be detected (every node has a random generated variable time-out, so childnode A2 could display a message before A1). Every node is executed in the order it is implemented, sequentially not concurrent.

So, now the issue: it looks like PVM doesn't support concurrency threads, which means I have to create my own threads per process by creating Threadable classes the usual way. Is this correct? Doesn't PVM create it's own executable threads when splitting/forking?

If not, anyone got a simple code example of above? I think I've read all possible documentation online about jBPM, but haven't found any solution. And code examples are so much clearer, from time to time :).

Thanks in advance for the help!

[kukeltje]

PVM and jBPM are no threadmanagers. concurrency has to be achieved by making the actions in the childnodes async and processed in parallel by other mechanisms (e.g. jms or more simple in the jobscheduler). This all is in the docs.

[rasun]

Thanks for your reply.

Still I keep asking myself; if the docs mention concurrency amongst processes and it is possible to use forks (like forEachForkActionHandler), which look like they are based on the same principle (of using concurrency/threads), then why not having the option of creating threaded forks/transitions?

I mean, if a fork splits in three transition/nodes that can be executed parallel and join into one node finally, then that would be quit a nice feature if it were implemented in jBPM, not?

[kukeltje]

no it would not. The reason is quite simple... threadmanagement is not allowed in JEE and JEE has way better options to do things async (building your own configurable threadmanager with pooling etc is quite difficult). For plain tasks jBPM works fine but for longer running actions or parallel running actions use the jBPM async option that makes use of jms or the jobscheduler (which is a kind of basic threadmanager)

[kukeltje]

so concurrent paths of execution != multiple threads

[rasun]

Thanx for your info, I'm gonna check out the docs about the jBPM option and see whether I can make something out of it ;).

Else, I just implement a simple Threadable node to spawn threaded childnodes and hope jBPM will be able to cope with it.

[kukeltje]

"Rasun" wrote:
Else, I just implement a simple Threadable node to spawn threaded childnodes and hope jBPM will be able to cope with it.

Hmm... I'd strongly advise against this. Many other issues can arise since jBPM was not developed to be used in this way. Might be very difficult to get any help in these circumstances, certainly if it is known by other people in this forum that jBPM is used in a 'wrong' way.

[rasun]

Though your vision might be just and correct, I managed to implement it as a simple app: I defined one class which creates threadable processes. Each process that has to be started will be fired as a new thread. This works quite safe as each new thread starts a new execution, though it isn't within the main process anymore. The basic idea was to create 'subprocesses' (splitted multiple transitions/nodes that work on a specific task and then merge into one node afterwards). As I want to keep the whole thing plain simple, I won't make use of Hibernate, databases or Job Executor. So I guess I'm forced to create my own implementation then.

Perhaps in the future, someday a simple fork will be available where each splitted transaction is a thread just for one transition :).

Thanks for your input anyway!