You just mean to configure application.yml like
camunda:
bpm:
job-execution:
enabled: false
For testing?
@dan see the specific comment: Timer Execution too slow
and its these settings:
camunda.bpm.job-execution
.wait-time-in-millis Specifies the wait time of the job acquisition thread in milliseconds in case there are less jobs available for execution than requested during acquisition. If this is repeatedly the case, the wait time is increased exponentially by the factor waitIncreaseFactor. The wait time is capped by maxWait. Default: 5000
.max-wait Specifies the maximum wait time of the job acquisition thread in milliseconds in case there are less jobs available for execution than requested during acquisition. Default 60000
.backoff-time-in-millis Specifies the wait time of the job acquisition thread in milliseconds in case jobs were acquired but could not be locked. This condition indicates that there are other job acquisition threads acquiring jobs in parallel. If this is repeatedly the case, the backoff time is increased exponentially by the factor waitIncreaseFactor. The time is capped by maxBackoff. With every increase in backoff time, the number of jobs acquired increases by waitIncreaseFactor as well. Default 0
.max-backoff Specifies the maximum wait time of the job acquisition thread in milliseconds in case jobs were acquired but could not be locked. Default 0
.backoff-decrease-threshold Specifies the number of successful job acquisition cycles without a job locking failure before the backoff time is decreased again. In that case, the backoff time is reduced by waitIncreaseFactor. Default 100
.wait-increase-factor Specifies the factor by which wait and backoff time are increased in case their activation conditions are repeatedly met.
1 Like
It would probably be simpler to just write a small unit test.
Here is a example of how you can test timer expectations:
See the following thread: Timer Evaluation: Unit Testing Timer configurations outside of execution If assuming you have the expected result, you can take the same logic put execute it as part of a actual unit tested execution.
It is using Spock Framework and groovy. But sure you can convert the same logic for kotlin if you like
1 Like
Thanks for the redirect, unit testing would be much more ideal! (Especially since it’d save me time in iterating). I love Spock! I might actually use that for my tests (I’m a big fan of using it when testing Optaplanner rules), since the Kotlin equivalent, Spek, doesn’t have Data Tables to the best of my knowledge. (see: http://engineering.pivotal.io/post/spek-data-driven-tests/)
@dan
Take a look at:
Should have all the spock examples you need 
Can also take a look at: Rebuild alternative using Spock Framework · Issue #32 · camunda-community-hub/camunda-bpm-process-test-coverage · GitHub
Its currently in the bpmn-coverage branch of the camunda-spock-testing repo. Gives you fun coverage reports