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.

Boundary Timer event - couldn't instantiate class

satramalin

We have a scenario where we have a service task(Polling task) which polls a mailbox at constant intervals. We have to enable the polling through timers.We tried the following scenarios and ended up with 'Couldn't instantiate class' error.
- We have the service task and then an user task with a boundary timer event attached to it. The timer is set to PT1M. The timer is connected to the service task so that the polling happens again after the sepcified time.
(Attached is the xml content for this scenario)
- TimerCatchEvent which is next to the service task and the TimerCatchEvent is again connected to the service task

Polling bpd.txt.zip

Find more posts tagged with

Comments

martin_grofcik

Hi,

What was the reason for 'Couldn't instantiate class' error?

I would use cycleTimer or multiinstance task for this case .

Regards
Martin

satramalin

Hi Martin,
Thanks for the response. We found the issue. It was because of 2 process engines running on same database and both process engines were picking up the timers randomly. Say, Appln A picked the timer for Appln B and executed it. Is there any way to prevent this in a common database?

frederikherema1

You can only use one node that executes jobs (disable job executor on second engine). This way, only one instance will pick up the jobs. This requires the job-executor engine to have all needed classes on the class path.

However, your question raises a red flag in my head. The same can happen when executing a process, not by the job-executor (eg. completing a task on engine 1 when it needs classes, present on engine 2). Either use 2 different databases or make your service-logic smart enough to only use processes that are guaranteed to work on the engine instance the API-call is done to…

satramalin

Thanks for your response. Please let me understand this issue. Now we have a plan of running 4 different applications with Activiti workflow on different application servers to use common Activiti tables in a shared database. Is your question (the same can happen when executing a process, not by the job-executor?) related to this scenario? In this case, if I understand correctly Appln A may consume not just the timers for Appln B but also the tasks. Please let me understand the risk in this architecture?

frederikherema1

Timers are all stored in the ACT_RU_JOB table, to ensure no jobs are lost when the JVM goes down, for example. Any job-executor in any engine can lock/aquire a job from that table and start executing it.

So if you have 4 different apps running against the same database, jobs for app A could be execute on B, C or D's engine and visa-versa. Having this architecture is bound to get you in trouble (not only job-related). Any specific need to have all data in the same tables? If you want to have it all in the same schema/database, you can always use a table name prefix for each of the apps (eg. job table will be APP1_ACT_RU_JOB for app 1).

The prefix can be configured in the processEngineConfiguration, but table creation needs to be done manually, as the db-scripts we have contain the non-prefixed version. It's a matter of doing a search/replace on all the db-create-scripts…