The aggregator is the join, but the 'concept' is non-blocking in the technical level. The thing is that when you start a process, it continues to the first node that is a waitstate and returns the control to the user then. In normal cases this is the jBPM fork. In your cases you'd want that to be the join, or even the 'leaving the join (e.g. the end node) In general it is an interesting question, although we should not try to duplicate things that are already in JBoss ESB. Since afaik a blocking scatterer/gatherer is available in the ESB. Implementing a custom join (look at the source of the JoinActivity.java (http://fisheye.jboss.org/browse/~raw,r=5490/JbpmSvn/jbpm4/trunk/modules/j...) with e.g. a Thread.sleep(..) and removing the 'waitForSignal()' would make it blocking but could have other implications. So in the end, I think you implementing a Thread.sleep(..) for now is best I think. But do not forget to e.g. implement timer like in the link I gave you. For this specific use-case, jBPM does not provide what you need out of the box and in the end you have to do some similar things like you would with old-school multi-threading or using jms for this (http://www.ibm.com/developerworks/websphere/library/techarticles/0802_nas...) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255519#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...