How to get the current try count?

[fml2]

Hello,

for activities with “asyncBefore = true” it is possible to specify the retry behaviour. Only after the max tries have failed will the engine create an incident.

Is it possible, inside a JavaDelegate, to get the number of tries left until the engine will vreate an incident? How?

Thank you for the hints.

[Niall]

Sure, you can specify a retry cycle form the modeler.

That would create a job with a certain retry cycle, why would you want to know within the JavaDelegate how many retries have been attempted?

[fml2]

@Niall

why would you want to know within the JavaDelegate how many retries have been attempted?

I want to know how many tries are left. I’d like to catch any errors if it’s the last try so that no incident is created.

[Webcyberrob]

Hi,
Have a look at this fail fast pattern…

Pattern - Fail Faster, Best Efforts

Hi All, I have a pattern to share based on @Bernd’s recent talks re orchestration across distributed micro-services. Problem Statement Sometimes we want to orchestrate across a remote service as a client of the service. But what happens if that service is down, and/or beyond our control? One option is to wait until the service resumes. Another option could be to continue without the service output. A real world example could be a gecoding validation service. If the service is down, but I alre…

Regards

Rob

[Hammad_Dar]

Probably too late but here is what I used successfully:

Note: ManagementService is ProcessEngine’s ManagementService.

managementService.createJobQuery().activityId(<your activity Id here>)
        .processInstanceId(<your process instance id here>).singleResult().getRetries();

How you can get activity Id and Process Instance Id from within the delegate?, here is how:

String currentActivityId = delegateExecution.getCurrentActivityId();
String processInstanceId = delegateExecution.getProcessInstanceId();

[OnnoH]

Replying to an old thread, so hopefully someone’s still awake

@fml2 I try to do the same, but all I get is the number three (3) even though I’ve set a pattern of R5/PT10S on the service task. Executing it works as expected and the incident is created. But like you, I want to prevent that and take a different route in the process.

This happens both on the JobExecutorContext and ManagementService (as @Hammad_Dar suggested). Also casting the DelegateExecution to a ExecutionEntity (like some examples prescribe) comes up empty.

Using Camunda 7.19 in a Spring Boot fashion.

PS. I guess this one’s still open: https://jira.camunda.com/browse/CAM-9486

Related: Job Executor getRetries() is wrong in some cases?