nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

TimerBoundaryEvent - Not recognizing Spring Bean in Loop

tidetom

Hi all,

I have a tricky problem that I've been trying to solve all day, and can't seem to figure out. Hoping you can help…

I have a TimerBoundaryEvent placed on a Java Receive Task in my process flow. The flow itself is somewhat of a loop. The way that my process flow works is as follows: (simplified for forum purposes):

1. Start Task2. Service Task (invokes Spring Bean "myAdapter.doSomething()" in an expression)3. XOR Gateway (checks whether we have what we need. If not, continues to java receive task. If so, goes to the End Task)4. Java Receive Task (waits indefinitely, until interrupted by Timer Boundary Event)5. Timer Boundary Event (interrupts Java Receive Task)6. XOR Gateway (Determine whether we've reached a maximum number of loops. If not, continue back up to the Service Task in step #2. If so, goes to the End Task)7. End TaskThe problem that I'm having is that sometimes when looping back to the service task, the Job fails because it doesn't recognize "myAdapter" (my Spring bean). Note that this is <i>very</i> inconsistent. From execution to execution, it might change. On one execution, it will recognize the adapter the first time it enters the service (before looping the first time) and then will fail on the second loop. The next time I run my unit test, it will succeed on the first and second loop, but fail on the third loop, etc. I have not yet seen it get to a fourth loop.

The error that I receive is a standard one I'd expect to see when not properly specifying the bean:

Caused by: org.activiti.engine.impl.javax.el.PropertyNotFoundException: Cannot resolve identifier 'myAdapter'
        at org.activiti.engine.impl.juel.AstIdentifier.eval(AstIdentifier.java:83)
        at org.activiti.engine.impl.juel.AstMethod.invoke(AstMethod.java:79)‍‍‍

But note that this error DOES NOT OCCUR the first time I enter the Service Task wherein "myAdapter.doSomething()" is invoked … only on subsequent calls after looping back to that Service Task.

I was thinking that it had something to do with the loop itself … maybe looping back to a task that has already been created, used, and completed is not allowed? Maybe I should pull the "looping" out into it's own Spring Bean, use my own threading/executor, and not use the TimerBoundaryEvent at all?

Any advice or comments would be very much appreciated. I can provide more information on this issue if needed.

Thanks,
Tom

Find more posts tagged with

Comments

frederikherema1

Tom,

The bean you are referring to, is this a Session-scoped bean or just a regular one? Perhaps something to do with the fact the job's are executed in another thread.

Can you create a simple test-case with a process that shows the bug you are describing?

tidetom

Hi Frederik,

Thanks so much for getting back…

The bean you are referring to, is this a Session-scoped bean or just a regular one?

This is just a standard Spring bean.

Perhaps something to do with the fact the job's are executed in another thread.

Yeah, I was kind of thinking the same thing. It's almost like the reference to the Spring context is getting put up for garbage collection on the original thread, given the inconsistency across executions. If the original context was tied to the process execution prior to the job, then if that process execution goes away, the context would, potentially, do the same? But then I suppose this would likely be seen in other scenarios that didn't involve looping. Hmmm….

Can you create a simple test-case with a process that shows the bug you are describing?

No problem, I'll put something together and reply to this post with the sample. It would probably be good for me to dial down my process into the essential elements causing this anyways. I'll post back soon.

Thanks again,
Tom