Orchestrator 2019.10: Do failed transactions kill Queue Triggers? Something starts them up again

Help
, ,
1

Dealing with an odd situation.

Our Orchestrator Queue Trigger is set to trigger another job for every 1 new item.
It’s set to have a maximum number of pending a running jobs allowed simultaneously = 2

It picks up pending jobs when there are multiple items in the queue, however it stops running when a transaction fails. The other new items do not get picked up. If you wait for a short time, it will seemingly randomly start processing jobs again.

Question 1: Do failed transaction items kill the Queue Trigger?

Question 2: Is there something like a cron job in configs that restarts the Queue trigger after an interval of time? Is this cronjob configurable?

We looked in the web.config and found this:

<add key="SystemJobs.JobTriggersFallback.Cron" value="0 0/10 * 1/1 * ? *" />
<add key="SystemJobs.JobTriggersTimerCheck.Cron" value="0 0/1 * 1/1 * ? *" />

IS this that configuration?

The documentation on this topic is a bit confusing and I am not certain about the settings. Any help is very appreciated. Goal is to get the trigger picking up new jobs as quickly as possible no matter what the transaction status is.

2

took this to tech support. turns out having failed high priority transactions in a queue can disable the trigger.

3

Seems to be an issue with the “consumer” process. Check the REFramework. When a transaction fails the job should not end but it should continue with the next item in queue.

1 Like
4

in our case we were not using the REFramework actually…

5

Nevermind. Normally you should process transactions within a loop. When an item fails the robot should perform some clean-up and move to the next.

However, if you have one job per transaction set correctly the parameters for the queue trigger: max_no_of_jobs should a high number.

6

Thanks, this is true. Another way to handle above issue is to set up a separate queue for failed transactions.