it's not a problem really.. 2010/4/26 Pedro Maria Buitrago Mantilla <pmbt...@gmail.com>
> > The problem is the multithreading execution. For a "SPLIT NODE" of type > "AND", first, is process one branch, after, the next branch and so on for > each. The execution is sequential. > > PEDRO MARIA BUITRAGO MANTILLA > Bogotá, Colombia > > > > 2010/4/26 rudolf michael <roud...@gmail.com> > > Alan, couldn't you have achieved this using a Split and Join? >> >> 2010/4/26 <alan.gai...@tessella.com> >> >> >>> Interesting. What you've described Pedro is similar to what I'm trying to >>> achieve, and also relates to some earlier posts I made to the list (title: >>> 'Drools Flow: Problem with constraint in (Wait) State node'). >>> >>> I have a process that launches independent sub flows; these independent >>> sub flows execute on separate threads. I then want the original process to >>> "block" until all the subflows have finished, and to then continue. >>> In order to achieve this, I've done the following: >>> >>> - Each process (both the main flow and each sub flow) is executed by a >>> separate stateful knowledge session. >>> - When a sub flow is started, it inserts a fact into the working memory >>> of the session for the original process. >>> - When a sub flow finishes, it updates a fact in the working memory of >>> the session for the original process to "signal" its completion. >>> - After launching the sub flows, the original process contains a (wait) >>> state node; the constraint for this node is designed to block until all >>> facts in its memory are in the "signalled" state. >>> >>> I've attached an example project that illustrates what I'm trying to >>> achieve. The constraint on the wait state node is currently as follows: >>> >>> (and forall(SimpleFact(complete == true)) exists(SimpleFact())) >>> >>> I'd be interested to know from someone who understands rule syntax better >>> than me as to why this seems to work when other attempts (see my earlier >>> posts) failed. >>> >>> I still have two problems though: >>> >>> 1) The above constraint appeared to work OK with an earlier 5.1 snapshot >>> build (from a couple of months back). However, using the latest successful >>> build from trunk (#3845), the Action node after the wait state node isn't >>> executed. Given that 5.1.M2 is supposed to be imminent, I'm worried. Does >>> anyone know why this no longer works? >>> >>> 2) If I try to enable JPA-based state persistence, using the Bitronix >>> transaction manager, then when I try to insert a fact into the working >>> memory of the session for the original process from a separate thread, I get >>> the following error: >>> >>> bitronix.tm.internal.BitronixRollbackException: transaction was marked as >>> rollback only and has been rolled back >>> at >>> bitronix.tm.BitronixTransaction.commit(BitronixTransaction.java:153) >>> at >>> bitronix.tm.BitronixTransactionManager.commit(BitronixTransactionManager.java:96) >>> at >>> org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:258) >>> at >>> org.drools.command.impl.CommandBasedStatefulKnowledgeSession.insert(CommandBasedStatefulKnowledgeSession.java:306) >>> at >>> com.test.InsertWorkItemHandler$1.insertFact(InsertWorkItemHandler.java:52) >>> at >>> com.test.InsertWorkItemHandler$1.run(InsertWorkItemHandler.java:40) >>> at java.lang.Thread.run(Thread.java:619) >>> java.lang.RuntimeException: Could not rollback transaction >>> at >>> org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:283) >>> at >>> org.drools.command.impl.CommandBasedStatefulKnowledgeSession.insert(CommandBasedStatefulKnowledgeSession.java:306) >>> at >>> com.test.InsertWorkItemHandler$1.insertFact(InsertWorkItemHandler.java:52) >>> at >>> com.test.InsertWorkItemHandler$1.run(InsertWorkItemHandler.java:40) >>> at java.lang.Thread.run(Thread.java:619) >>> Caused by: java.lang.IllegalStateException: no transaction started on >>> this thread >>> at >>> bitronix.tm.BitronixTransactionManager.rollback(BitronixTransactionManager.java:103) >>> at >>> org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:278) >>> ... 4 more >>> >>> Any help anyone can provide would be very much appreciated. Thank you. >>> >>> Regards, >>> >>> Alan >>> >>> >>> >>> >>> *Pedro Maria Buitrago Mantilla <pmbt...@gmail.com>* >>> Sent by: rules-users-boun...@lists.jboss.org >>> >>> 23/04/2010 14:38 >>> Please respond to >>> Rules Users List <rules-users@lists.jboss.org> >>> >>> To >>> Rules Users List <rules-users@lists.jboss.org> >>> cc >>> Subject >>> Re: [rules-users] Multithreading work items >>> >>> >>> >>> >>> Each of the sub flows requires final user design. Mauricio thanks very >>> much. >>> >>> PEDRO BUITRAGO >>> Bogotá, Colombia >>> >>> >>> 2010/4/22 Mauricio Salatino <*sala...@gmail.com* <sala...@gmail.com>> >>> yes.. sounds more like a normal java problem than Drools FLow problem. I >>> think that your solution is the correct one because it handle internally the >>> multithreaded requierements and then it continue the business process >>> normally. >>> >>> >>> 2010/4/22 Pedro Maria Buitrago Mantilla >>> <*pmbt...@gmail.com*<pmbt...@gmail.com>> >>> >>> >>> The idea is to run multiple independent sub flows. Each of the sub flows >>> requires approximately 2 minutes to complete, so parallel processing is >>> required. Once all the sub flows have completed their tasks is necessary to >>> collect all the results and process them. This implies that the workflow >>> should not end until it collects all information submitted by the sub flows. >>> >>> For now, I think to create, with JMS, a queue in jboss receive the name >>> of each sub flow, create your own KnowledgeBase run each subflow as a >>> separate workflow and delivers the results. Finally, some components will >>> take all the results (from a database of another jms queue and process and >>> again another component start another workflow to process all results. >>> >>> >>> PEDRO BUITRAGO >>> Bogotá, Colombia >>> >>> >>> 2010/4/22 Mauricio Salatino <*sala...@gmail.com* <sala...@gmail.com>> >>> >>> can you describe a little bit your use case? >>> I'm not sure about what you want to achieve. >>> >>> 2010/4/21 Pedro Maria Buitrago Mantilla >>> <*pmbt...@gmail.com*<pmbt...@gmail.com> >>> > >>> In general, I meet that for resolve the topic of multithreading it's >>> required to implement another thread over a work item. >>> >>> How does the asynchronic task can modified a variable of Knowledgebase? >>> >>> Can you give me an example? >>> >>> Pedro Buitrago >>> >>> >>> >>> _______________________________________________ >>> rules-users mailing list* >>> **rules-us...@lists.jboss.org* <rules-users@lists.jboss.org>* >>> **https://lists.jboss.org/mailman/listinfo/rules-users*<https://lists.jboss.org/mailman/listinfo/rules-users> >>> >>> >>> >>> >>> -- >>> - *http://salaboy.wordpress.com* <http://salaboy.wordpress.com/> >>> - *http://www.jbug.com.ar* <http://www.jbug.com.ar/> >>> - Salatino "Salaboy" Mauricio - >>> >>> _______________________________________________ >>> rules-users mailing list* >>> **rules-us...@lists.jboss.org* <rules-users@lists.jboss.org>* >>> **https://lists.jboss.org/mailman/listinfo/rules-users*<https://lists.jboss.org/mailman/listinfo/rules-users> >>> >>> >>> >>> _______________________________________________ >>> rules-users mailing list* >>> **rules-us...@lists.jboss.org* <rules-users@lists.jboss.org>* >>> **https://lists.jboss.org/mailman/listinfo/rules-users*<https://lists.jboss.org/mailman/listinfo/rules-users> >>> >>> >>> >>> >>> -- >>> - *http://salaboy.wordpress.com* <http://salaboy.wordpress.com/> >>> - *http://www.jbug.com.ar* <http://www.jbug.com.ar/> >>> - Salatino "Salaboy" Mauricio - >>> >>> _______________________________________________ >>> rules-users mailing list* >>> **rules-us...@lists.jboss.org* <rules-users@lists.jboss.org>* >>> **https://lists.jboss.org/mailman/listinfo/rules-users*<https://lists.jboss.org/mailman/listinfo/rules-users> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> _______________________________________________ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
