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

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

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?

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?

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

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.

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