Activated JobExecutor, but still not active/working while using MariaDB (Docker)?


#1

Hi,

actually I’m developing a Camunda Spring Boot application (Kotlin instead of Java). My problem is, that my “async before” tasks wont be executed by the job executor.

I am using following version:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.0.2.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <java.version>1.8</java.version>
    <maven.compiler.source>10</maven.compiler.source>
    <maven.compiler.target>10</maven.compiler.target>
    <maven.compiler.release>10</maven.compiler.release>
    <kotlin.version>1.2.41</kotlin.version>
    <dockerfile.version>1.4.4</dockerfile.version>
</properties>
   
 <dependency>
        <groupId>org.camunda.bpm.springboot</groupId>
        <artifactId>camunda-bpm-spring-boot-starter</artifactId>
        <version>3.0.0</version>
    </dependency>

In my application.properties I have set (should be the default value)
camunda.bpm.job-execution.enabled = true

When I start my spring boot application, the log tells me:

2018-10-07 22:33:45.070  INFO 5289 --- [ost-startStop-1] org.camunda.bpm.spring.boot              : STARTER-SB040 Setting up jobExecutor with corePoolSize=3, maxPoolSize:10
2018-10-07 22:33:45.079  INFO 5289 --- [ost-startStop-1] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService  'camundaTaskExecutor'
2018-10-07 22:33:45.208  INFO 5289 --- [ost-startStop-1] org.camunda.bpm.engine.cfg               : ENGINE-12003 Plugin 'CompositeProcessEnginePlugin[genericPropertiesConfiguration, camundaProcessEngineConfiguration, camundaDatasourceConfiguration, camundaJpaConfiguration, camundaJobConfiguration, camundaHistoryConfiguration, camundaMetricsConfiguration, camundaAuthorizationConfiguration, failedJobConfiguration, disableDeploymentResourcePattern]' activated on process engine 'default'
2018-10-07 22:33:45.211  INFO 5289 --- [ost-startStop-1] org.camunda.bpm.spring.boot              : STARTER-SB020 ProcessApplication enabled: autoDeployment via springConfiguration#deploymentResourcePattern is disabled
2018-10-07 22:33:47.349  INFO 5289 --- [ost-startStop-1] org.camunda.bpm.engine                   : ENGINE-00001 Process Engine default created.

2018-10-07 22:33:50.894  INFO 5289 --- [           main] org.camunda.bpm.engine.jobexecutor       : ENGINE-14014 Starting up the JobExecutor[org.camunda.bpm.engine.spring.components.jobexecutor.SpringJobExecutor].
2018-10-07 22:33:50.895  INFO 5289 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14018 JobExecutor[org.camunda.bpm.engine.spring.components.jobexecutor.SpringJobExecutor] starting to acquire jobs

So the Job Executor should be active. But my delegate code isn’t executed. If I will make the task “sync (async before is false)”, the delegate will be executed.

Is there some other configuration, that I have to set?

Cheers!
Christian


#2

So, I have found more details but not a solution for my problem.

I started to create a simple tiny sample project with the base of my real one. And there it works… (Hmmm) So I have started to compare both projects.
It wont longer work, if I change the datasource from embedded h2 to mariadb (is running inside a docker container)

This is my application.properties file using maria db:

# ===============================
# SPRING
# ===============================

spring.datasource.url = jdbc:mariadb://localhost:8889/databasename
spring.datasource.username = username
spring.datasource.password = secret
spring.datasource.driver-class-name = org.mariadb.jdbc.Driver

spring.jpa.show-sql=true
spring.jpa.hibernate.ddl-auto=update
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MariaDBDialect

# Relevant fuer "UPPER_CASE" Schreibweise - aber es muss dann mit @Table/@Column gearbeitet werden
spring.jpa.hibernate.naming.physical-strategy = org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl

spring.servlet.multipart.max-file-size = 8MB
spring.servlet.multipart.max-request-size = 8MB


# ===============================
# CAMUNDA
# ===============================
camunda.bpm.database.type = mariadb
camunda.bpm.job-execution.enabled = true
camunda.bpm.job-execution.active = true


#management.trace. TODO...

# ===============================
# LOGGING
# ===============================
logging.level.root = INFO
logging.level.org.springframework.security = DEBUG
logging.level.org.springframework.web = DEBUG
logging.level.de.sample = TRACE

This is my docker-compose.yml (part with mariadb)

maria:
image: mariadb:10.2
environment:
MYSQL_ROOT_PASSWORD: secret
MYSQL_DATABASE: databasename
MYSQL_USER: username
MYSQL_PASSWORD: secret
logging:
driver: syslog
ports:
- “8889:3306”
restart: on-failure # always
volumes:
- /ct_home/_TMP_DATA/docker/volumes/maria:/var/lib/mysql

My JpaRepositories and Camunda itself are able to write to the mariadb.

I have changed the log level of the job executor category to trace:

018-10-08 13:33:01.178  INFO 6328 --- [           main] org.camunda.bpm.engine.jobexecutor       : ENGINE-14014 Starting up the JobExecutor[org.camunda.bpm.engine.spring.components.jobexecutor.SpringJobExecutor].
2018-10-08 13:33:01.180  INFO 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14018 JobExecutor[org.camunda.bpm.engine.spring.components.jobexecutor.SpringJobExecutor] starting to acquire jobs
2018-10-08 13:33:01.246 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14022 Acquired 0 jobs for process engine 'default': []
2018-10-08 13:33:01.247 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14011 Job acquisition thread sleeping for 4933 millis
2018-10-08 13:33:06.180 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14012 Job acquisition thread woke up
2018-10-08 13:33:06.188 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14022 Acquired 0 jobs for process engine 'default': []
2018-10-08 13:33:06.188 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14011 Job acquisition thread sleeping for 9992 millis
2018-10-08 13:33:16.181 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14012 Job acquisition thread woke up
2018-10-08 13:33:16.189 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14022 Acquired 0 jobs for process engine 'default': []
2018-10-08 13:33:16.189 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14011 Job acquisition thread sleeping for 19992 millis
2018-10-08 13:33:36.181 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14012 Job acquisition thread woke up
2018-10-08 13:33:36.187 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14022 Acquired 0 jobs for process engine 'default': []
2018-10-08 13:33:36.188 DEBUG 6328 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14011 Job acquisition thread sleeping for 39994 millis

0 jobs are acquired, but the datatable ACT_RU_JOB has job entries:

ID_ REV_ TYPE_ LOCK_EXP_TIME_ LOCK_OWNER_ EXCLUSIVE_ EXECUTION_ID_ PROCESS_INSTANCE_ID_ PROCESS_DEF_ID_ PROCESS_DEF_KEY_ RETRIES_ EXCEPTION_STACK_ID_ EXCEPTION_MSG_ DUEDATE_ REPEAT_ HANDLER_TYPE_ HANDLER_CFG_ DEPLOYMENT_ID_ SUSPENSION_STATE_ JOB_DEF_ID_ PRIORITY_ SEQUENCE_COUNTER_ TENANT_ID_
c9cab3dd-caeb-11e8-bf10-82c6c157f354 5 message 2018-10-08 13:39:16 12cb3b49-40fb-468b-9e37-eb1200d6f7b7 1 c9c92d35-caeb-11e8-bf10-82c6c157f354 c9c92d35-caeb-11e8-bf10-82c6c157f354 Process_Bestelleingang:1:c9bbe6c2-caeb-11e8-bf10-82c6c157f354 Process_Bestelleingang 3 async-continuation transition-create-scope c9b249d0-caeb-11e8-bf10-82c6c157f354 1 c9bbe6c3-caeb-11e8-bf10-82c6c157f354 0 1
e991da80-caed-11e8-bcdc-82c6c157f354 2 message 2018-10-08 13:38:01 12cb3b49-40fb-468b-9e37-eb1200d6f7b7 1 e99053d8-caed-11e8-bcdc-82c6c157f354 e99053d8-caed-11e8-bcdc-82c6c157f354 Process_Bestelleingang:1:c9bbe6c2-caeb-11e8-bf10-82c6c157f354 Process_Bestelleingang 3 async-continuation transition-create-scope c9b249d0-caeb-11e8-bf10-82c6c157f354 1 c9bbe6c3-caeb-11e8-bf10-82c6c157f354 0 1
f4b8b130-caeb-11e8-b347-82c6c157f354 5 message 2018-10-08 13:40:16 12cb3b49-40fb-468b-9e37-eb1200d6f7b7 1 f4b778a8-caeb-11e8-b347-82c6c157f354 f4b778a8-caeb-11e8-b347-82c6c157f354 Process_Bestelleingang:1:c9bbe6c2-caeb-11e8-bf10-82c6c157f354 Process_Bestelleingang 3 async-continuation transition-create-scope c9b249d0-caeb-11e8-bf10-82c6c157f354 1 c9bbe6c3-caeb-11e8-bf10-82c6c157f354 0 1

Here the ACT_RU_EXECUTION table content:

ID_ REV_ PROC_INST_ID_ BUSINESS_KEY_ PARENT_ID_ PROC_DEF_ID_ SUPER_EXEC_ SUPER_CASE_EXEC_ CASE_INST_ID_ ACT_ID_ ACT_INST_ID_ IS_ACTIVE_ IS_CONCURRENT_ IS_SCOPE_ IS_EVENT_SCOPE_ SUSPENSION_STATE_ CACHED_ENT_STATE_ SEQUENCE_COUNTER_ TENANT_ID_
c9c92d35-caeb-11e8-bf10-82c6c157f354 1 c9c92d35-caeb-11e8-bf10-82c6c157f354 Process_Bestelleingang:1:c9bbe6c2-caeb-11e8-bf10-82c6c157f354 Task_0b60vyi 1 0 1 0 1 4 9
e99053d8-caed-11e8-bcdc-82c6c157f354 1 e99053d8-caed-11e8-bcdc-82c6c157f354 Process_Bestelleingang:1:c9bbe6c2-caeb-11e8-bf10-82c6c157f354 Task_0b60vyi 1 0 1 0 1 4 9
f4b778a8-caeb-11e8-b347-82c6c157f354 1 f4b778a8-caeb-11e8-b347-82c6c157f354 Process_Bestelleingang:1:c9bbe6c2-caeb-11e8-bf10-82c6c157f354 Task_0b60vyi 1 0 1 0 1 4 9

Any ideas why the JobExecutor wont start executing jobs?


#3

I’ve got it working. After downgrading my mariadb from 10.2 to 10.0 the JobExecutor starts acquiring jobs. The documentation shows, that MariaDB 10.2 is supported:

[https://docs.camunda.org/manual/7.9/introduction/supported-environments/#supported-database-products](http://DB Support 7.9)

Is MariaDB 10.2 supported with the community 7.9.0 or only since a 7.9.x patch release?


#4

MariaDB 10.2 is supported with 7.9.0.

Could you please try something on the non-working setup:
setup jdbcBatchProcessing configuration to false
https://docs.camunda.org/manual/7.9/user-guide/process-engine/database/#jdbc-batch-processing


#5

Thank you for your response.

I have configured disabling jdbc-batch-processing

camunda.bpm.database.jdbc-batch-processing = false

and then it works also with the MariaDB 10.2.

Actually this option is missing in the docs:
https://docs.camunda.org/manual/latest/user-guide/spring-boot-integration/configuration/

I have found it reading following ticket:
https://app.camunda.com/jira/browse/CAM-8760

Do you think, the batch processing flag must be set to false also for future versions of MariaDB? I have seen, that camunda will support with 7.10 also MariaDB 10.3.


#6

Hi Christian,

Ideally, we will be able to support batch processing with 10.2 and future MariaDB versions, but first we need to understand the situation better. See https://app.camunda.com/jira/browse/CAM-8891 for our progress on this.

Cheers,
Thorben


UserTasks are created twice times