Activiti in Tomcat docker container -Issues

[amal_v]

hi all!!

I am a newbie to Activiti

For the past few days i have been trying to set up Activiti in a Tomcat Docker container.My knowledge on the working of activiti and the back-end processes are very limited . But i will try my best to convey my issues.

• I deployed Activiti in 2 different Tomcat's Docker Containers.

                - Activiti_container1 running on port 8080

                - Activiti_container2 running on port 8081

• These Activiti's are connected to an Oracle Database and hosts the work-flows of an application.
• The requests to these containers are distributed via a Load Balancer.
• Everything works fine except for the components in the application that uses signals.These components triggers heavyweight  processes and requires time to execute and hence uses signals to acknowledge the updates of the action at the front end.

Here is the log I get :

10:25:11,500 [pool-2-thread-1] ERROR org.activiti.engine.impl.jobexecutor.ExecuteJobsRunnable - exception during job execution: JobEntity [id=49054095] was updated by another transaction concurrently
org.activiti.engine.ActivitiOptimisticLockingException: JobEntity [id=49054095] was updated by another transaction concurrently
at org.activiti.engine.impl.db.DbSqlSession$CheckedDeleteOperation.execute(DbSqlSession.java:295)
at org.activiti.engine.impl.db.DbSqlSession.flushRegularDeletes(DbSqlSession.java:922)
at org.activiti.engine.impl.db.DbSqlSession.flushDeletes(DbSqlSession.java:888)
at org.activiti.engine.impl.db.DbSqlSession.flush(DbSqlSession.java:613)
at org.activiti.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:212)
at org.activiti.engine.impl.interceptor.CommandContext.close(CommandContext.java:138)
at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:66)
at org.activiti.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:47)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:133)
at org.activiti.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:45)
at org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:31)
at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:40)
at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:35)
at org.activiti.engine.impl.jobexecutor.ExecuteJobsRunnable.handleMultipleJobs(ExecuteJobsRunnable.java:94)
at org.activiti.engine.impl.jobexecutor.ExecuteJobsRunnable.run(ExecuteJobsRunnable.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
1.517394329435E12

People with more expertise say that it might work fine if there is only one Activiti container.

Can anyone help me solve this issue or help me understand the issue??

Thanks a lot !!

[ryandawson]

I don't think we can know whether you could avoid this issue by running just one Activiti without knowing more about the process definition and what it is doing at the point of failure. It is a likely candidate but it might be possible to produce this error with only one Activiti (see   for example). The best way to find out would probably be to try running just one and see if the problem still occurs.  

[amal_v]

Thanks for replying.

I forgot to mention that it works perfectly fine when Activiti is set up not inside containers.

Two Tomcats running on two different ports with Activiti works fine. This problem occurred only when it was containerized.

[ryandawson]

Are there any other differences between the dockerised and not dockerised versions? Is more data going into one than the other? Have you increased the memory and CPU defaults for docker? I am wondering if there are either more transactions in the docker version (would happen if more data) or perhaps they are taking longer to complete.

[amal_v]

Found out that the problem occurs even when only single container is used.

[ryandawson]

I'd certainly like to be able to help more. Is it possible to provide any code snippets or bpmn from the process that is being run? I'm particularly interested in any async behaviour. Are you sure that docker is the only difference between the situation where it works and where it doesn't? If so would you be able to provide any details on how it is containerised? (It might be worth reading Java Memory Consumption in Docker and How We Employed Spring Boot - DZone Performance ) How frequent is the error and does it always affect the same point in the process? It would also be good to know what version of Activiti you are using. (From your description of your achitecture it sounds like Activiti Cloud for v7 might be of interest to you.)

[amal_v]

I really appreciate your interest in solving my issue. I will do my best to give you all details that you need.

Yes Docker is the only difference between the situation where it works and where it doesn't.

And I can't  say that my Activiti is containerized rather it is running in a containerized Tomcat server. Here is how i run my container.

-->docker run --network=host --name Activiti-Container --restart unless-stopped -v /home/amalv/Activiti_Dev_team/webapps/:/opt/tomcat/webapps -v /home/amalv/Activiti_Dev_team/conf/:/opt/tomcat/conf tomcat/oraclejava:8.8

Like I mentioned earlier this problem only occurs with components that makes use of signals.

I will explain what i mean by signals:

In our application we have a process that takes a long time to complete. The process gathers a package that needs to be executed in an Oracle DB. Because this is a long running process in order to avoid user-wait time the user is notified with a pending status while in the background the process executes. At this point a WaitSignalWorkflow is Initiated. When the background process completes at the DB, it initiates a WaitSignalThrowWorkflow.

The process just stops at the WaitforSignal stage. And nothing happens at the DB either. So no communication occurs between the database and the application except for those other components that makes no use of such signals.And that too only when using Containers.

The Activiti version is 6.0.0

[ryandawson]

If difference between working and not working is docker my best guess would be that your tomcats are different in either version or default configuration. Perhaps a different database connection pool size or something similar. Are you using a different tomcat version in docker from the version you run with outside of docker? Also is it the same oracle jdbc driver used in both cases?

I guess you're using an official tomcat image and mounting a volume for the webapps and conf directories. Is the database running separately outside of docker?

A couple of other things you could try would be to dockerise the war file by building a docker image with the war baked in (like ArunJ suggests at Packaging and serving your Java application with Docker | The Geeky Platypus Blog or step 2 at How to Create and Run Apache Tomcat Docker Container – USER MANUALS & FAQS ). I don't expect that to matter but I wouldn't expect it to fail only in docker. You could also try running the database from within the same docker network (see How to Connect Tomcat Docker Container with MS SQL Docker Container – USER MANUALS & FAQS or Connecting to an OracleDB in a docker container from another java docker container - General Discuss... or you could use docker-compose, as is done using Activiti Cloud for Activiti 7 - activiti-cloud-examples/application-docker-compose.yml at 7-201712-EA · Activiti/activiti-cloud-exam... ). It seems you are going for a similar setup to Deploying a Java App with an Oracle Database in a Docker Container - DZone Java  . 

There is an argument for using a base Activiti docker image from the web as then you know you're starting from an image that somebody else has had working.

[amal_v · Accepted solution]

Ryan Dawson! Thanks a lot for your wonderful support.

I figured out that my problem was not actually associated with Activiti itself.

The actual problem here was that there was a database scheduler in use.

And the docker container's default time zone was set to UTC.

Setting the container time zone to local time zone resolved the issue..

[ryandawson]

Cool, glad it got resolved and thanks for posting to say what the cause was.