Queue Trigger: About delay time

Feedback Orchestrator
, , ,
1

In guideline of Queue Trigger (Orchestrator - About triggers), i found below description

Once every 30 minutes a check for new, unprocessed items is performed, and whenever such items exist, the target process is triggered.

Does it mean sometime my job have to wait 30mins for trigger after queue data adding?
If yes, i think 30 minutes is too long. Should UiPath reduce this time, or allow Orchestrator’s admin setting this time by himself?

2

Agreed - 30 minutes is way too long considering that Transactions could be process in minutes of not seconds. This will cause a backlog in Queue Transactions. This should be configurable based on needs.

1 Like
3

Ok, found the solution to adjusting the Interval Time.
There is a property in the Orchestrator Web.Config File.

Here is the response from Support Team:
Yes, the “Queue.ProcessActivationSchedule” key can be used to adjust the Queue Trigger time.

Modify the “30” value and pass any value between “0-59” and then restart the IIS.

5 Likes
4

Great!
It’s better if we can change this setting via Orchestrator’s web layout but it seems impossible 'cause IIS restarting required

5

Please note that the trigger works instantly with new added items. That timeout applies only to unprocessed items like retried transactions… or, for example, if you disable a trigger and at some point you re-enable it. If there are already X items in queue the trigger will fire when a new item is added or at the specified interval.

1 Like
6

I would suggest that UiPath add this clarification to the documentation page for Qeuue Trigger because people will think that new job will start when there are new items in the queue, when in fact, it starts when a new item is ADDED or at the specified interval.

7

Looks like we have a performance issue with the queue triggers and sometimes they are not firing in the community cloud. Hopefully they are cleared in maximum 30 mins. We aim to fix it in 20.5.

8

@badita - some times queueu based triggers are not processing in Enterprise on-prem version also.
Scenario -
If we add multiple items (ex - added 3 items to a queue with in a delay of 2 seconds for each item) -
In this case queue based trigger will create job only for 1st queue item and it will not create jobs for second & third items.
eighter we need to wait for 30mins/defined time or add another item (4th item) into the queue to process remaining items.

1 Like
9

Seems strange. Please open a support ticket.

10

Changing of Queue.ProcessActivationSchedule has no effect. I always waits 30minutes

1 Like
11

Same happens to me, with orchestrator 2020.4.3: @badita is that property Queue.ProcessActivationSchedule working on newer versions of orchestrator?

12

Seems not. I opened a ticket. But they are not so fast.

1 Like
13

The solution is:
• Change the config to the expected interval
• Restart IIS
• Delete the existing queue trigger and recreate it again (This is mandatory).

This works

1 Like
14

I have started experiencing this. Why I haven’t noticed this until today? I have run 1.6K tests and in the last couple of days it started to do this odd behavior.

15

@badita
Has there been a solution for this? With 2021.4 Community version as well, the job only seems to be created for the 1st item added to the queue. As the GetTransactionItem only retrieves 1 transaction at a time, the 1st transaction is processed whereas no jobs after that. It triggers after 30 mins and then it processes another transaction from the queue. I am unable to process all items from the queue without adding a loop in the process. Any solutions please?

16

Hi, any updates about it ? Can we change the interval through the orchestrator web in the future ?

17

@Stephu config for what please can you explain more?

18

Hi, Dinesh

You can use RE Framework for getting all the items at one single job. It has a loop, yes, but it is very easy to adapt any process to it.

If the item is processed too quick (like, quicker than the new items is added to the queue) you can add a delay before the “get transaction data” workflow. So the first item will be processed quick but the job will wait for the new items to process.

Give it a try