Re: [rules-users] Persistence in fireUntilHalt() loop

2012-03-19 Thread Marco Rietveld

  
  
Alberto, 

Sorry to hear that the bug isn't fixed. 

Could you clarify what you mean by these points? 
 - Drools and JBPM have different persistence managers.
 - Drools uses JTA for persistence and JBPM does not.

I was pretty sure you could specify a JTA data source in the
persistence.xml that jBPM uses. 

As for the persistence managers, what do you mean exactly? 

Also, if you could maybe give me a github link referring to the code
you're using, that would be great. 

(Just to make sure, you are referring to jbpm 5, right?)

Thanks,
Marco


03/19/2012 06:23 PM, Alberto R. Galdo:
I'm afraid this bug is not resolved and doesn't have
  nothing to do with lazy evaluation.
  
  We've been able to get to the source of the problem and this are
  the facts:
  
   - Drools and JBPM have different persistence managers.
   - Drools uses JTA for persistence and JBPM does not.
   - When any JPA enabled object is persisted in Drools, a
  transaction begins, it's EntityManager ( Hibernate ) joins the
  transaction and the entity gets persisted. 
   - When any JPA enabled object ( in this case a
  ProcessInstanceInfo ) is persisted in JBPM, there are no
  transactions involved, and so the EntityManager ( Hibernate )
  decides to delay the insert ( queuing it as there's no transaction
  in progress ). Then the processId never gets updated and the NPE
  arises.
  
  The problem here seems to be that both Drools and JBPM manage
  persistence in different and incompatible ways. We've been able to
  modify jbpm-persistence-jpa to open a JTA transaction before
  persisting ProcessInstanceInfo, getting the EntityManager joining
  that transaction and using the current Bitronix implementation
  already running in Drools ( to assist persistence for their
  objects ) .. like so:
  
   public void setKnowledgeRuntime(InternalKnowledgeRuntime
  kruntime) {
   this.kruntime = kruntime;
   Environment env = kruntime.getEnvironment();
   Object tm = env.get( EnvironmentName.TRANSACTION_MANAGER
  );
   if (!(tm instanceof javax.transaction.TransactionManager))
  {
try {
//  get Bitronix instance inside ...
 java.lang.reflect.Field field =
  tm.getClass().getDeclaredField("tm");
   // who says private in Java is really private ...
  xD
 field.setAccessible(true);
 tm = field.get(tm);
} catch (Exception e){
 e.printStackTrace();
}
   }
   this.txm = new JtaTransactionManager( env.get(
  EnvironmentName.TRANSACTION ), env.get(
  EnvironmentName.TRANSACTION_SYNCHRONIZATION_REGISTRY ), tm );
   }
  
   public void addProcessInstance(ProcessInstance
  processInstance) {
   ProcessInstanceInfo processInstanceInfo = new
  ProcessInstanceInfo( processInstance,
  this.kruntime.getEnvironment() );
   ProcessPersistenceContext context =
  ((ProcessPersistenceContextManager)
  this.kruntime.getEnvironment().get(
  EnvironmentName.PERSISTENCE_CONTEXT_MANAGER
  )).getProcessPersistenceContext();
   this.txm.begin();
   context.persist( processInstanceInfo );
   this.txm.commit();
  
  
  
  I think we can agree that the previous lines of code are not the
  most elegant solution ( at least not for me ).
  
  So, Is there any timeline for merging DROOLS and JBPM 5
  persistence managers? 
  
  If someone gives me advice and architectural hints ( and if it is
  doable in a reasonable ammount of time ) I would be eager to
  submit a patch for this 
  
  
  Alberto R. Galdo
  arga...@gmail.com
  
  
  On Wed, Mar 14, 2012 at 13:56, Alberto R.
Galdo arga...@gmail.com
wrote:
Great news!
  
  We were in the process of debugging JBPM trying to find the
  source of the bug ... and maybe days away from the solution
  ...
  
  Is there any bug report in Jira and/or a patch we can apply
  without having to wait for the next release so we can
  quick-patch our systems?
  
  
  Alberto R. Galdo
  arga...@gmail.com
  

  
  
  On Wed, Mar 14, 2012 at 13:09,
    Marco Rietveld mriet...@redhat.com
wrote:

   
Hi Alberto, 

This is a bug that has been fixed in jBPM. It had to
do with lazy initialization of a JPAProcessInstanceManager
field. 

We'll be releasing a new jBPM version som

Re: [rules-users] Persistence in fireUntilHalt() loop

2012-03-19 Thread Marco Rietveld

  
  
Sorry, to be clear: a github link to the code you quoted is what I
was after. 

03/19/2012 10:33 PM, Marco Rietveld:

  
  Alberto, 
  
  Sorry to hear that the bug isn't fixed. 
  
  Could you clarify what you mean by these points? 
   - Drools and JBPM have different persistence managers.
   - Drools uses JTA for persistence and JBPM does not.
  
  I was pretty sure you could specify a JTA data source in the
  persistence.xml that jBPM uses. 
  
  As for the persistence managers, what do you mean exactly? 
  
  Also, if you could maybe give me a github link referring to the
  code you're using, that would be great. 
  
  (Just to make sure, you are referring to jbpm 5, right?)
  
  Thanks,
  Marco
  
  
  03/19/2012 06:23 PM, Alberto R. Galdo:
  I'm afraid this bug is not resolved and doesn't have
nothing to do with lazy evaluation.

We've been able to get to the source of the problem and this are
the facts:

 - Drools and JBPM have different persistence managers.
 - Drools uses JTA for persistence and JBPM does not.
 - When any JPA enabled object is persisted in Drools, a
transaction begins, it's EntityManager ( Hibernate ) joins the
transaction and the entity gets persisted. 
 - When any JPA enabled object ( in this case a
ProcessInstanceInfo ) is persisted in JBPM, there are no
transactions involved, and so the EntityManager ( Hibernate )
decides to delay the insert ( queuing it as there's no
transaction in progress ). Then the processId never gets updated
and the NPE arises.

The problem here seems to be that both Drools and JBPM manage
persistence in different and incompatible ways. We've been able
to modify jbpm-persistence-jpa to open a JTA transaction before
persisting ProcessInstanceInfo, getting the EntityManager
joining that transaction and using the current Bitronix
implementation already running in Drools ( to assist persistence
for their objects ) .. like so:

 public void setKnowledgeRuntime(InternalKnowledgeRuntime
kruntime) {
 this.kruntime = kruntime;
 Environment env = kruntime.getEnvironment();
 Object tm = env.get( EnvironmentName.TRANSACTION_MANAGER
);
 if (!(tm instanceof
javax.transaction.TransactionManager)) {
  try {
  //  get Bitronix instance inside ...
   java.lang.reflect.Field field =
tm.getClass().getDeclaredField("tm");
 // who says private in Java is really private
... xD
   field.setAccessible(true);
   tm = field.get(tm);
  } catch (Exception e){
   e.printStackTrace();
  }
 }
 this.txm = new JtaTransactionManager( env.get(
EnvironmentName.TRANSACTION ), env.get(
EnvironmentName.TRANSACTION_SYNCHRONIZATION_REGISTRY ), tm );
 }

 public void addProcessInstance(ProcessInstance
processInstance) {
 ProcessInstanceInfo processInstanceInfo = new
ProcessInstanceInfo( processInstance,
this.kruntime.getEnvironment() );
 ProcessPersistenceContext context =
((ProcessPersistenceContextManager)
this.kruntime.getEnvironment().get(
EnvironmentName.PERSISTENCE_CONTEXT_MANAGER
)).getProcessPersistenceContext();
 this.txm.begin();
 context.persist( processInstanceInfo );
 this.txm.commit();



I think we can agree that the previous lines of code are not the
most elegant solution ( at least not for me ).

So, Is there any timeline for merging DROOLS and JBPM 5
persistence managers? 

If someone gives me advice and architectural hints ( and if it
is doable in a reasonable ammount of time ) I would be eager to
submit a patch for this 


Alberto R. Galdo
arga...@gmail.com


On Wed, Mar 14, 2012 at 13:56, Alberto
  R. Galdo arga...@gmail.com
  wrote:
  Great
news!

We were in the process of debugging JBPM trying to find the
source of the bug ... and maybe days away from the solution
...

Is there any bug report in Jira and/or a patch we can apply
without having to wait for the next release so we can
quick-patch our systems?


Alberto R. Galdo
arga...@gmail.com

  


On Wed, Mar 14, 2012 at 13:09,
  Marco Rietveld mriet...@

Re: [rules-users] Persistence in fireUntilHalt() loop

2012-03-14 Thread Marco Rietveld

  
  

Hi Alberto, 

This is a bug that has been fixed in jBPM. It had to do with lazy
initialization of a JPAProcessInstanceManager
field. 

We'll be releasing a new jBPM version sometime soon (synchronous
with Drools, I think). The bug is fixed in there. 

Regards,
Marco

03/08/2012 11:32 AM, Alberto R. Galdo:

Hi,


 We're running an application that uses Drools + JBPM 5 +
  Drools integration our set-up can be seen as:

  

 Some rule fires and creates a JBPM process ( a fact gets
  inserted into drools using
  "kcontext.getKnowledgeRuntime().startProcess("testProcess")"
  ). We have a problem with the persistence of this processes.
  Persistence is implemented with JPA and JTA. Our application
  runs with fireUntilHalt() and when a process is launched from
  the consequence of any of the rules the persistence of the
  process fails. If the application runs with fireAllRules(),
  the persistence works like a charm.

 The error shown is as follow:

 Exception in thread "Thread-5" Exception executing
  consequence for rule "Run Process" in com.sample:
  java.lang.NullPointerException
 at
org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
 at
  org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1101)
 at
  org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1029)
 at
  org.drools.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1229)
 at
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:754)
 at
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:730)
 at
org.drools.command.runtime.rule.FireUntilHaltCommand$1.run(FireUntilHaltCommand.java:50)
 at
  java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
 at
org.jbpm.persistence.processinstance.JPAProcessInstanceManager.addProcessInstance(JPAProcessInstanceManager.java:44)
 at
org.jbpm.process.instance.AbstractProcessInstanceFactory.createProcessInstance(AbstractProcessInstanceFactory.java:36)
 at
org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:182)
 at
org.jbpm.process.instance.ProcessRuntimeImpl.createProcessInstance(ProcessRuntimeImpl.java:154)
 at
org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:135)
 at
org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:130)
 at
org.drools.common.AbstractWorkingMemory.startProcess(AbstractWorkingMemory.java:1074)
 at
org.drools.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:301)
 at
  com.sample.Rule_Run_Process.defaultConsequence(Rule_Run_Process.java:9)
 at
  com.sample.Rule_Run_ProcessDefaultConsequenceInvoker.evaluate(Unknown
  Source)
 at
  org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1091)
 ... 6 more
 
 The problem is
  in this function:
 
 public void
  addProcessInstance(ProcessInstance processInstance) {
ProcessInstanceInfo processInstanceInfo = new
  ProcessInstanceInfo( processInstance,
  this.kruntime.getEnvironment() );
ProcessPersistenceContext context
  = ((ProcessPersistenceContextManager)
  this.kruntime.getEnvironment()
  .get(
  EnvironmentName.PERSISTENCE_CONTEXT_MANAGER ))
  .getProcessPersistenceContext();
// @PrePersist added to ProcessInstanceInfo because
  of this
context.persist( processInstanceInfo );
((org.jbpm.process.instance.ProcessInstance)
  processInstance).setId( processInstanceInfo.getId() );
processInstanceInfo.updateLastReadDate();
internalAddProcessInstance(processInstance);
  }
 
 We think after
  that persist sentence, the entity manager would have to run a
  flush sentence for the process instance is inserted into
  database and get the ID.
 
 Greets.
  
  
  
  
  ___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users




-- 
jBPM/Drools developer
Utrecht, the Netherlands
  

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] jbpm 3.2.x verssion .....

2011-11-14 Thread Marco Rietveld

  
  
Hi Summeet, 

jbpm 3.2.x works with jBoss AS 5.1 -- and obviously also with Drools
5.3, since there's no overlap between those two versions of jbpm and
drools. 
I'm not sure if Drools 5.3 works with jBoss AS 5.1, although I think
it does. 

There is adifference between jbpm 3.2.8 and the supported
version of jbpm 3.2. It's hard to quantify the difference exactly,
but since late 2009 when 3.2.8 was released, a number of bugs have
been fixed in the supported version. 

. Marco


11/11/2011 10:39 AM, Sumeet Karawal:

  Thanks Thomas

No, I am a little confused which version to use. I visited the site
http://sourceforge.net/projects/jbpm/files/jBPM%203/. Here the maximum
downloads are for v 3.2.2  and the latest among these is v3.2.8. It would
be very helpful if you could suggest me which one to use among the versions
3.2.x. As my requirement is to use jbpm v3.2.x with Drools and Jboss AS,
and later on Mule ESB v3.1 will also be used. So I am thinking of
installing jbpm among v3.2.x with Drools v5.3 Final and JBoss AS v 5.1.
Will these components work together?

Also, jbpm Enterprise Supports v3. So is there much difference between the
enterprise version of jbpm v3 and the community versions of v3.2.x

Thanks  Regards,
Sumeet Karawal
Mailto: sumeet.kara...@tcs.com





-- 
jBPM/Drools developer
Utrecht, the Netherlands
  

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] jbpm 3.2.x verssion .....

2011-11-14 Thread Marco Rietveld

  
  
Summeet (and others), 

As mentioned, this is indeed a drools (user) mailing list. 

The proper mailing lists for jbpm (3, 4 or 5) are: 

jbpm-us...@lists.jboss.org  (for these types of questions)
jbpm-us...@lists.jboss.org  (for developers and people who look
at jbpm code/internals) 


Most of the jbpm core developers monitor both lists. 


Thanks,
Marco

11/14/2011 02:00 PM, Marco Rietveld:

  
  Hi Summeet, 
  
  jbpm 3.2.x works with jBoss AS 5.1 -- and obviously also with
  Drools 5.3, since there's no overlap between those two versions of
  jbpm and drools. 
  I'm not sure if Drools 5.3 works with jBoss AS 5.1, although I think
  it does. 
  
  There is adifference between jbpm 3.2.8 and the supported version
  of jbpm 3.2. It's hard to quantify the difference exactly, but
  since late 2009 when 3.2.8 was released, a number of bugs have
  been fixed in the supported version. 
  
  . Marco
  
  
  11/11/2011 10:39 AM, Sumeet Karawal:
  
Thanks Thomas

No, I am a little confused which version to use. I visited the site
http://sourceforge.net/projects/jbpm/files/jBPM%203/. Here the maximum
downloads are for v 3.2.2  and the latest among these is v3.2.8. It would
be very helpful if you could suggest me which one to use among the versions
3.2.x. As my requirement is to use jbpm v3.2.x with Drools and Jboss AS,
and later on Mule ESB v3.1 will also be used. So I am thinking of
installing jbpm among v3.2.x with Drools v5.3 Final and JBoss AS v 5.1.
Will these components work together?

Also, jbpm Enterprise Supports v3. So is there much difference between the
enterprise version of jbpm v3 and the community versions of v3.2.x

Thanks  Regards,
Sumeet Karawal
Mailto: sumeet.kara...@tcs.com



  
  
  -- 
jBPM/Drools developer
Utrecht, the Netherlands



-- 
jBPM/Drools developer
Utrecht, the Netherlands
  

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] ksession.insert() executes sequentially in multithreaded StatefulKnowledgeSessions

2011-10-27 Thread Marco Rietveld
Hi Juan Carlos,

Sorry for the late reply.

Would you mind sending me the Sample.drl en .bpmn files as well?

I happen to have a bit of code that I can use to look into this.

Thanks,
Marco

10/06/2011 01:28 PM, juancarlos.fernandezj:
 Hello,

 I'm having trouble when trying to insert() facts inside parallel
 StatefulKnowledgeSessions. From a main() java program I start multiple
 threads. Every thread creates new KnowledgeBase and every KnowledgeBase
 creates new StatefulKnowledgeSession so I have one StatefulKnowledgeSession
 in every thread. Once StatefulKnowledgeSession has been created, I insert
 lots of facts in each StatefulKnowledgeSession.

 What was expected? I expected to run insert() in parallel, each insert
 inside its thread StatefulKnowledgeSession. 4 threads inserting lots of
 facts inside its own StatefulKnowledgeSession is expected to run in parallel
 and see how CPU usage increases.

 What have I seen? when all threads are inserting facts in its own
 StatefulKnowledgeSession I can see that only one CPU is being used so there
 is no parallel insertion in different StatefulKnowledgeSession.

 Is there a synchronization inside insert() code? It's so strange. Even if i
 try with 12 threads, I can't see a CPU usage increase when executing
 parallel insert() inside different StatefulKnowledgeSession (threads).

 Help please.

 This is my thread code (no static objects):

 public class KnowledgeSessionThread extends Thread {
   
   private StatefulKnowledgeSession session;
   private Message[] facts;
   
  public KnowledgeSessionThread(Message[] facts) throws Exception {
   session = readKnowledgeBase().newStatefulKnowledgeSession();
   this.facts = facts;
  }

  public void run() {
   try {
   for( int i = 0; i  facts.length; i++ ) {
   session.insert(facts[i]);
   }
   session.startProcess(flowId);
   session.fireAllRules();
   session.dispose();
   System.out.println(Thread finished);
   } catch( Exception e ) {
   e.printStackTrace();
   }
  }

  private KnowledgeBase readKnowledgeBase() throws Exception {
  KnowledgeBuilder kbuilder =
 KnowledgeBuilderFactory.newKnowledgeBuilder();
  kbuilder.add(ResourceFactory.newClassPathResource(Sample.drl),
 ResourceType.DRL);
  kbuilder.add(ResourceFactory.newClassPathResource(Sample.bpmn),
 ResourceType.BPMN2);
  KnowledgeBuilderErrors errors = kbuilder.getErrors();
  if (errors.size()  0) {
  for (KnowledgeBuilderError error: errors) {
  System.err.println(error);
  }
  throw new IllegalArgumentException(Could not parse
 knowledge.);
  }
  KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
  kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
  return kbase;
  }
 }

 --
 View this message in 
 context:http://drools.46999.n3.nabble.com/ksession-insert-executes-sequentially-in-multithreaded-StatefulKnowledgeSessions-tp3399339p3399339.html
 Sent from the Drools: User forum mailing list archive at Nabble.com.
 ___
 rules-users mailing list
 rules-users@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/rules-users


-- 
jBPM/Drools developer
Utrecht, the Netherlands

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] Using JBPM 5 with Container Managed Persistence

2011-08-22 Thread Marco Rietveld
Hi Hough, 

Unfortunately, there isn't any documentation on this (Container Managed
Persistence w/ jBPM 5) that I know of. I've asked around a little and
couldn't find any. 

What are you using transactions for in your case? jBPM itself has some
mechanisms that manage transactions. 

Regards, 
Marco


houghvw wrote:
 
 Hi,
 
 Is there any documentation on how to configure JBPM 5 with container
 managed persistence using EJB3. It works using bean managed persistence.
 But would make life much easier if I did not have to manage the tx myself.
 
 Regards
 Hough
 


--
View this message in context: 
http://drools.46999.n3.nabble.com/Using-JBPM-5-with-Container-Managed-Persistence-tp3261549p3274929.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users