[BPM] Custom Workflow inconsistencies

Hello,

Few days ago, I found out one really annoying bug that kept happening when I tried to complete a workflow. The annoying part is that it was really hard to reproduce and even harder to debug. I uploaded some log files and the workflow that I was trying to complete.

The problem:
Sometimes, when I was advancing through the workflow, let’s say I was advancing on the “Product Attached” path, the item kept appearing as being in the same state, making me believe that it had not transitioned in the next state. After, I re-did the process to change it’s state, this time leading to a complete application hang. This behaviour was not consistent. Sometimes, I was able to complete the workflow without any problems.

I came to a solution, the solution being putting a half-second Thread.sleep() call in the service methods called by the state changes. Despite this solution actually working, it is an “ugly” approach to solving, what I think, an internal concurrency problem.

If the info I brought is not sufficient for you to investigate, I am waiting for some follow-up as to what further information you need.

Thank you!

ProductSourcingLogsBeforeHanging.log (945 Bytes)
ProductSourcingErrorStackTrace.log (20.9 KB)
ProductSourcingFlow

1 Like

Hi,
usually, it’s very hard to say anything about problems like “sometimes something hangs up”. The suspicious thing I see in the logs is the line:

2018-02-08 16:28:05.197 DEBUG [http-nio-8080-exec-19/scope-fb-core/leclerc] com.haulmont.cuba.core.app.RdbmsStore - loadList: metaClass=bpm$ProcAttachment, view=com.haulmont.bpm.entity.ProcAttachment/procAttachment-browse, query=select e from bpm$ProcAttachment, max=10000

The query select e from bpm$ProcAttachment os weird. Platform screens limit the attachments list by the process instance. Where was this query invoked from?

From Process Instance Edit default screen i guess… we don’t use ProcAttachments for now.

21 PM