Job Executor: Custom Retry Configuration

Camunda 7 Topics Discussion & Questions
1

hi,

documentation for BPM 7.7 says you have to enable custom retry configuration by adding FoxFailedJobParseListener and foxFailedJobCommandFactory to the process engine configuration.

With 7.7.4-ee i set a custom retry cyle on a failing service-task and it works without adding this listener to the engine configuration.

Is this feature now enabled by default and the docs are not updated, or am i missing something?

Thx

2

Hello,

Could you please attach your engine configuration file.

Best regards,
Yana

3

hi,

the engine is deployed as a jboss-module on a wildfly-8.2.1.Final in standalone-mode.

Hereā€™s the subsystem-configuration from standalone.xml:

<extensions>
    .
    .
    .
    <extension module="org.camunda.bpm.wildfly.camunda-wildfly-subsystem"/>
</extensions>
<subsystem xmlns="urn:org.camunda.bpm.jboss:1.1">
    <process-engines>
        <process-engine name="default" default="true">
            <datasource>java:jboss/datasources/ProcessEngine</datasource>
            <history-level>full</history-level>
            <properties>
                <property name="jobExecutorAcquisitionName">
                    default
                </property>
                <property name="isAutoSchemaUpdate">
                    false
                </property>
                <property name="authorizationEnabled">
                    true
                </property>
                <property name="jobExecutorDeploymentAware">
                    true
                </property>
            </properties>
            <plugins>
                <plugin>
                    <class>org.camunda.bpm.application.impl.event.ProcessApplicationEventListenerPlugin</class>
                </plugin>
                <plugin>
                    <class>org.camunda.spin.plugin.impl.SpinProcessEnginePlugin</class>
                </plugin>
                <plugin>
                    <class>org.camunda.connect.plugin.impl.ConnectProcessEnginePlugin</class>
                </plugin>
                <plugin>
                    <class>org.camunda.bpm.engine.impl.plugin.AdministratorAuthorizationPlugin</class>
                    <properties>
                        <property name="administratorUserName">
                            admin
                        </property>
                    </properties>
                </plugin>
            </plugins>
        </process-engine>
    </process-engines>
    <job-executor>
        <thread-pool-name>job-executor-tp</thread-pool-name>
        <core-threads>3</core-threads>
        <max-threads>3</max-threads>
        <queue-length>3</queue-length>
        <keepalive-time>10</keepalive-time>
        <allow-core-timeout>true</allow-core-timeout>
        <job-acquisitions>
            <job-acquisition name="default">
                <properties>
                    <property name="lockTimeInMillis">
                        900000
                    </property>
                    <property name="waitTimeInMillis">
                        5000
                    </property>
                    <property name="maxJobsPerAcquisition">
                        3
                    </property>
                </properties>
            </job-acquisition>
        </job-acquisitions>
    </job-executor>
</subsystem>
4

Hi,

Sorry for my late response.
You still need to enable this feature in 7.7 versions. From 7.8 it will be enabled by default and this configuration will be not needed anymore.
It is strange what you experienced. We need to dig into it further:

  • How do you deploy your process?
  • If you are using processes.xml file, please attach it.
  • And also could you please attach the process itself.

Best regards,
Yana

5

Hi,

processes are deployed as part of our process-application (WAR-file). The application extends EjbProcessApplication.

testRetry.bpmn (6.9 KB)
After starting this process and waiting till all retries finished, i checked timestamps of jobs in the database:

select ACT_ID_, TIMESTAMP_ from ACT_HI_JOB_LOG where PROCESS_INSTANCE_ID_='389b18c7-ceaa-11e7-a26d-0a0027000000' order by ACT_ID_ desc, TIMESTAMP_ asc;

with this result:

ACT_ID_                                             TIMESTAMP_                   
---------------------------------------------------------------------------------
taskDefaultRetry                                    2017-11-21 11:53:34.7770000  
taskDefaultRetry                                    2017-11-21 11:53:35.6470000  
taskDefaultRetry                                    2017-11-21 11:53:35.7970000  
taskDefaultRetry                                    2017-11-21 11:53:35.8370000  
taskConfiguredRetry                                 2017-11-21 11:53:34.7800000    
taskConfiguredRetry                                 2017-11-21 11:53:35.6470000  
taskConfiguredRetry                                 2017-11-21 11:55:51.0670000  
taskConfiguredRetry                                 2017-11-21 11:58:06.2170000
6

processes.xml (529 Bytes)

7

Hello,

So basically with this configuration

<camunda:failedJobRetryTimeCycle >R3/PT2M</camunda:failedJobRetryTimeCycle>

you are covering the default behavior when the custom retry configuration is not set up, which is
failed job will be retried 3 times. (read more here) You can test that by changing the failedJobRetryTimeCycle to R5/PT1M and see if it will be retried 5 times or again 3. As I said you still need the configuration for 7.7.

Best regards,
Yana

8

hi,

itā€™t not the amount of retries iā€™m looking at.
it is the wait time for the retry (2 Minutes vs. immediately) that works without the listener configuration in the engine.

9

@radius69 Please check this topic

Custom retry is enabled by default if you are using ā€˜org.camunda.bpm.container.impl.jboss.config. ManagedJtaProcessEngineConfigurationā€™ on a Wildfly/JBoss subsystem.

1 Like
10

thanks syed.
thatā€™s the information i was looking for.
now itā€™s clear.