Hi
There is a part of my workflow as below.
And there is my worker code (springboot)
When the worker is called , the log outputs:
As the log said, the worker has been called twice.The duration between two calling is 30 seconds.
Is this a retry ? why is the retry triggered ?
I don’t see the type of the worker matching with your screenshot… so that is not definitely the same Service Task. “publishSystemService” is not “Resource_DataBase_RNC…”
How many process instances do you have?
The worker will fetch the pending jobs every X amount of time that can be changed via configuration.
Just one instance.
What is the configuration key in spring-zeebe ?
So how many process instances do you have… a Job will be created for each instance that hit that node in the process.
The configuration key is zeebe.client.job.poll-interval.
You can find the default values here: https://github.com/zeebe-io/zeebe/blob/develop/clients/java/src/main/java/io/zeebe/client/impl/ZeebeClientBuilderImpl.java
private Duration defaultJobTimeout = Duration.ofMinutes(5L);
private Duration defaultJobPollInterval = Duration.ofMillis(100L);
private Duration defaultMessageTimeToLive = Duration.ofHours(1L);
private Duration defaultRequestTimeout = Duration.ofSeconds(20L);
@i.m.superman you can print in your worker all the information to make sure that your worker is picking up the correct jobs and for the correct instance… you have all the metadata in the Job to check that…
A retry is triggered if you don’t send back a complete command with the job key.
what if my work is a long term job (1 hour or more ) ?
You need to specify the timeout in the activeJobs command.
I use spring-zeebe-starter 0.6.0.
I set “zeebe.client.worker.poll-interval = 30m“. Does that mean the interval of retry is 30 mintues ?
@i.m.superman that is the polling interval… which means “how often the worker need to go and fetch for new jobs”
No, that means the worker polls every 30 minutes. So, any long poll that lasts 30 minutes will be ended and a new one started. The long poll timer is reset also whenever jobs are streamed to the worker in response to an activateJobs command, and a new long poll is started.
