Handling different retry parameters

[spartan]

Hello,

I have to implement my process taking into account that some services can be retried (example : timeout while calling web services). The maximum number of retries and the delay can be different from a service to another one.

One designer suggested that we design this using the modeler and adding trivial branching/looping/exit. I disagreed because that was just going to make the diagram less readable because of non-business concern. Also Activiti is supposed to provide a retry mechanism, let's just re-use and not re-do.

1) Whats do you think about that ? Better to design it on the diagram or rather handle/hide on in the java side ?

2) How to actually use the retry mechanism provided by Activiti ? By default, there are 3 retries hardcoded. How to make a diffrent number of retries for each of my services ?

Best,
John

[martin_grofcik]

Hi John,

1) Whats do you think about that ? Better to design it on the diagram or rather handle/hide on in the java side ?

I do not know all requirements, but I would vote for now adding additional complexity to process model.

2) How to actually use the retry mechanism provided by Activiti ? By default, there are 3 retries hardcoded.

See job executor configuration

How to make a diffrent number of retries for each of my services ?

In that case you have to add it to the model (I would say as an extensionElement (see examples in the activiti source)).
After that you can hook into process parsing (see doc) to be able to use extension elements from the model during the execution.

Regards
Martin

[spartan]

After that you can hook into process parsing (see doc) to be able to use extension elements from the model during the execution.

Im able to implements a new Parser (extending ServiceTaskParseHandler). I can see the retry values in "ServiceTask.fieldExtensions" then dont know what to do from there…

[martin_grofcik]

Hi John,

I would say that the easiest way how to achieve is to change the behaviour where async tasks are executed. On this place new job is created
and retries are taken from the default values. Instead of default values you can replace them with the values from extension element.

Regards
Martin

[spartan]

I would say that the easiest way how to achieve is to change the behaviour where async tasks are executed

That's what I ended implementing. For the record : it's about writing custom implementation of DefaultFailedJobCommandFactory.

Then after taking a new look, I realized that I could simply set the "failedJobRetryTimeCycleValue" property from a custom parse handler with no need to modify any async task behaviour. That custom handler has been set to the "customDefaultBpmnParseHandlers" conf property. Not sure if "postBpmnParseHandlers" would have been better a better choise. Do you know the purpose of the later ?

[jbarrez]

no … historical reasons most likely…