Source string Read only

Template: AdminGenericInterfaceErrorHandlingRequestRetry
22/220
Context English State
Define if processing should be stopped after module was executed, skipping all remaining modules or only those of the same backend.
Default behavior is to resume, processing the next module.
This module allows to configure scheduled retries for failed requests.
Default behavior of GenericInterface web services is to send each request exactly once and not to reschedule after errors.
If more than one module capable of scheduling a retry is executed for an individual request, the module executed last is authoritative and determines if a retry is scheduled.
Request retry options
Retry options are applied when requests cause error handling module execution (based on processing options).
Schedule retry
Should requests causing an error be triggered again at a later time?
Initial retry interval
Interval after which to trigger the first retry.
Note: This and all further retry intervals are based on the error handling module execution time for the initial request.
Factor for further retries
If a request returns an error even after a first retry, define if subsequent retries are triggered using the same interval or in increasing intervals.
Example: If a request is initially triggered at 10:00 with initial interval at '1 minute' and retry factor at '2', retries would be triggered at 10:01 (1 minute), 10:03 (2*1=2 minutes), 10:07 (2*2=4 minutes), 10:15 (2*4=8 minutes), ...
Maximum retry interval
If a retry interval factor of '1.5' or '2' is selected, undesirably long intervals can be prevented by defining the largest interval allowed.
Intervals calculated to exceed the maximum retry interval will then automatically be shortened accordingly.
Example: If a request is initially triggered at 10:00 with initial interval at '1 minute', retry factor at '2' and maximum interval at '5 minutes', retries would be triggered at 10:01 (1 minute), 10:03 (2 minutes), 10:07 (4 minutes), 10:12 (8=>5 minutes), 10:17, ...
Maximum retry count
Maximum number of retries before a failing request is discarded, not counting the initial request.
Example: If a request is initially triggered at 10:00 with initial interval at '1 minute', retry factor at '2' and maximum retry count at '2', retries would be triggered at 10:01 and 10:02 only.
Note: Maximum retry count might not be reached if a maximum retry period is configured as well and reached earlier.
This field must be empty or contain a positive number.
Maximum retry period
Maximum period of time for retries of failing requests before they are discarded (based on the error handling module execution time for the initial request).
Retries that would normally be triggered after maximum period is elapsed (according to retry interval calculation) will automatically be triggered at maximum period exactly.
Example: If a request is initially triggered at 10:00 with initial interval at '1 minute', retry factor at '2' and maximum retry period at '30 minutes', retries would be triggered at 10:01, 10:03, 10:07, 10:15 and finally at 10:31=>10:30.
Note: Maximum retry period might not be reached if a maximum retry count is configured as well and reached earlier.
Add Invoker
Edit Invoker

Loading…

User avatar None

New source string

OTRS 6 / ((OTRS)) Community EditionEnglish

New source string a year ago
Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
Template: AdminGenericInterfaceErrorHandlingRequestRetry
Flags
read-only
String age
a year ago
Source string age
a year ago
Translation file
i18n/otrs/otrs.pot, string 643