Kaleo workflowContext should be a unmodifiable map

Michael Chen
Michael Chen
Less Than a Minute Read

The design of workflowContext in KaleoInstance is not fork/thread/cluster safe. There is no database row level locking to prevent dirty reads from and competing writes to workflowContext as a Map or as a string. This also applies to Java code and KaleoTaskInstanceToken.workflowContext and KaleoTimerInstanceToken.workflowContext.

I propose this change, which prevents developers from putting custom values in "workflowContent" in one <script> block, hoping another <script> block can retrieve them:

https://github.com/liferay/liferay-portal/pull/3795/commits/2e4c855964564bdc5e2ad8f8d09d1e41f37b827d

The problem is most obvious when there are forks in the workflow. Each path of the fork will be "walked" by a separate Kaleo thread or even in a different JVM of a Liferay cluster. There is no proper concurrency implementation to support that.

Liferay should add explicit declaration of this design and behavior in documentations like https://help.liferay.com/hc/en-us/articles/360028818852-Leveraging-the-Script-Engine-in-Workflow

Page Comments
thumbnail
Jorge Díaz
5 Years Ago

Hi Michael Chen, Instead of writing this blog post or sending a pull request, it is better to create a bug issue in https://issues.liferay.com

 

You have also information about how to contribute here: https://github.com/liferay/liferay-portal/blob/master/CONTRIBUTING.markdown

Please sign in to reply.
Michael Chen Jorge Díaz
5 Years Ago - Edited

Some may not consider this a bug. It's more like declaring a Java parameter final to prevent its value being changed. It's nice to have but not a must. But thanks for the suggestion.

The more important point is for Liferay to acknowledge this and inform developers.

Please sign in to reply.
thumbnail
Javier Moral
5 Years Ago

Hi Michael Chen,

Since  https://issues.liferay.com/browse/LPS-104523 kaleo nodes are walked in a single thread so I think it might address at least some of your concerns

Please sign in to reply.
Michael Chen Javier Moral
5 Years Ago - Edited

Hi Javier,

LPS-104523 consumes one KALEO_GRAPH_WALKER message payload in one thread, but what about the producer(s)?

Will similar Kaloe messages be produced in quick successions, creating a scenario that cannot be solved by LPS-104523? For example, wouldn't parallel tasks in sibling fork paths produce independent messages?

Also, what about other code that writes to KaleoInstance, like DefaultWorkflowEngineImpl, which competes with PathElementMessageListener?

Thanks

--Michael

Please sign in to reply.

Related Assets...

No Results Found

More Blog Entries...