JBPM 6.4 Clustering and Asynchronous Execution

[jproj...@gmail.com]

Dear All,

I've playing around with JBPM 6.4 trying to achieve real parallel execution of process instances in a clustered environment (currently only two nodes).

To start, i was trying with a multiinstance subprocess with a reutilizable inside, marked as "is async", but this lead into a OptimisticLockException, row was updated or deleted, when (i guess), child processes were returning their results to parent multiinstance.

The second try was using AsyncProcessCommand to launch subprocesses asynchronously from the multiinstance and wait for the results from a intermediate signal event, and this works smoothly in a single node scenario but,

My problem now is that, when deploying in a cluster environment, everything works as expected (parent process starts all children, the children are dispatched by both servers in the cluster --wildfly 8.2.1, but, at the moment of returning results to parent process, it seems that theres no way (or at least i havent found it), to synchronice the reception of the signals.

As you know, this asynchronous scenario forces to setup the signal MDB in a single session manner to avoid optimistic lock exceptions but, how to achieve the same in a cluster by, for example, allowing only one node to get/handle those signals?

Maybe its a matter of changing the code to use a pessimistic lock to use database level lock also for updating parent process but...

Have tried with different Runtime Strategies but i guess these has nothing to do with this behaviour.

Anyone has had a similar issue?

Thank you very much (and Merry Christmas to all ;))

Best Regards,
JP

[jproj...@gmail.com]

Just to be more clear, the error that arises in clustered mode is also an OptimisticLockException when updating ProcessInstance Info:

Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : [org.jbpm.persistence.processinstance.ProcessInstanceInfo#8326]
        at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:2541) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
        at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3285) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
        at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3183) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
        at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3525) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
        at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:159) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]

Thanks again!
JP

[Maciej Swiderski]

the only thing that comes to my mid is to setup the MDB to receive singals after completion only on one node.

Other than that don’t think there is any other way than lock it pessimisticly. Which in the end might not be so bad..

Maciej

--
You received this message because you are subscribed to the Google Groups "jBPM Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jbpm-usage+...@googlegroups.com.
To post to this group, send email to jbpm-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jbpm-usage/4b4c8843-7fb4-421c-828c-6dcfd0348f3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jproj...@gmail.com]

Indeed, the option of locking at database level doesnt look so bad.
Will try to dig deeper in that line and update with the results. Have seen in code a property:

org.kie.api.persistence.pessimistic

Thay may do the trick...

Will let you know if it works or not.

Thanks for the reply! And Merry Christmas!
JP

[Yvonne Ye]

Hi, have you tried using the org.kie.api.persistence.pessimistic and does it work? Thanks for sharing1


在 2016年12月23日星期五 UTC+1下午8:00:07，jproj...@gmail.com写道：

[Juan Pablo Rojas]

Hi Yvonne,

Yes, we finally included the "org.kie.api.persistence.pessimistic=true" in the deployment descriptor and seems to work (at least no more OptLockExceptions...

Now we have and issue on the balancing.. (one node seems to receive much more work that the other in the cluster), but guess it might be becouse of the queue's configuration at hornetq level... still havent stopped deeply at this point, and not sure if the pessimistic=true has anything to do with it.

Sorry didnt update the post before!

Regards!

JP

[Yvonne Ye]

Hi Juan Pablo, 

Thank you for sharing, by the way, does the performance affected a lot when using pessimistic locking, I am thinking the pessimistic locking would involve more DB operations, the performance might be affected. 

Thanks!

Yvonne

在 2017年7月26日星期三 UTC+2下午3:30:18，Juan Pablo Rojas写道：

[Elia Saba]

Hi Juan,

can you share more details about how you set the "org.kie.api.persistence.pessimistic=true" options in the deployment descriptor. Did you added the properties in the kie-deployment-descriptor.xml ??

Thank you in advance,

Elia