Job-execution-rejected

Yes, I patched the MyBatis Query and patched the engine, and compared my adjusted engine with the “normal” one.

I roughly copied your process engine setup:

Every delegate has a logger and a 200ms sleep

I set up a Docker Compose file:

version: "3.2"
services:
  postgres:
    container_name: camunda_db
    hostname: camunda_db
    restart: unless-stopped
    image: postgres:latest
    command: -c 'max_connections=200'
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres
      - POSTGRES_PORT=5432
  camunda_nodes:
    image: operaton-spring-example:0.0.1-SNAPSHOT
    deploy:
      replicas: 10
    restart: unless-stopped
    depends_on:
      - postgres
    environment:
      - SPRING_DATASOURCE_URL=jdbc:postgresql://camunda_db/postgres
      - SPRING_DATASOURCE_USERNAME=postgres
      - SPRING_DATASOURCE_PASSWORD=postgres
  camunda_lead:
    image: operaton-spring-example:0.0.1-SNAPSHOT
    restart: unless-stopped
    ports:
      - "8080:8080"
    depends_on:
      - postgres
    environment:
      - SPRING_DATASOURCE_URL=jdbc:postgresql://camunda_db/postgres
      - SPRING_DATASOURCE_USERNAME=postgres
      - SPRING_DATASOURCE_PASSWORD=postgres

And I stole your config:

bpm:
    job-execution:
      enabled: true
      queue-capacity: 10
      core-pool-size: 3
      max-pool-size: 5
      lock-time-in-millis: 300000
      wait-time-in-millis: 1000
      max-wait: 10000
      max-jobs-per-acquisition: 10

I then sent 1000 message events to the camunda_lead.

Processing with the unchanged engine and 10 nodes: 40 seconds
Processing with the unchanged engine and 5 nodes: 35 seconds
Processing with the adapted myBatis Query and 10 nodes: 22 seconds

This is not representative, of course, but I think it is an interesting experiment.

1 Like