Hello,
I’m now sure how to setup Queue Trigger on Orchestrator for 1 process.
I’d like it to trigger extra job for each 10 new items, so:
10 items in queue - 1 job
20 items in queue - 2 jobs
30 items in queue - 3 jobs, etc…
And up to maximum of 8 jobs running at the same time.
I have carefully read section “Queue trigger processing algorithm” in UiPath Documentation and I think it should run as I have just described it with example.
At the screenshot I have attached my queue trigger setup and how jobs were started with it.
Initially queue had 6 items, so one job “1. Process_A” started.
During this job, if items went with failed application status, it sets current queue item with Failed status, then it re-populates queue item with Higher priority (up to 3 retries) as new queue item, but total of “New” queue items is not changing, so it is always max 6.
Next item taken into processing is always this repopulated, as it has higher priority.
Aftertime, second Job has started processing queue items (I don’t know why, there was max 6 New items in queue or less).
After 4 minutes, third job has started and proceed with items too.
Next, another 3 jobs (!) started, but there were no more items in queue so they just stopped.
Queue stared with 6 New items.
Never during processing number of New items exceeded 6.
Queue at the end (with all retries) had 11 queue items (failed,retried,etc…).
Why 6 jobs spawned? Did I setup Queue Trigger wrongly? Please help me understand how does this field “Another job is triggered for each X new items” works, as clearly either I don’t get it, or documentation is not self-explanatory.
I thought that with my attached queue trigger setup, maximum of 1 Job should start in total, but 6 jobs started.
As per documentation, The number of new queue items (on top of the number configured for the Minimum number of items that trigger the first job option) to trigger a new job.
here you have set the Minimum number of items that trigger the first job to 1. So it is count over that 1
You have set max process count to 8 so it will created 8 jobs until unless Queue is empty
You cant allow job to run for only 10 items from orchestrator,
you need to add this logic in your process code.
if Transaction Number > 10 the end process
in this case if any transaction fails and its being retried then it will use same transaction number to process retried queue item.
OR
Instead of trigger, You can create a Dispatcher which gets count of queue item and creates jobs for each 10 items
Just to analyse the scenario - Try changing the Minimum number of items to trigger the first job as 5 and see how it is behaving
Does all the 6 process were running at the same time or one after other?
If it ran one after the other - during retry there could be some delay and that could be the reason. See the behaviour closely after changing the count as 5 and let us know the details
Hello @Darshan_Sable
I’m still confused. Let’s have an example with my data.
N = 6, “number of New queue items”, x = 1, “minimum number of items that triggers the first job”, y = 8, “max number of sim. jobs”, z = 10, “Another job is triggered for each…new items”.
This means that 1 job is started if x is reached. For the remaining N-x queue items, we will try to start (N-x)/z jobs. If this were to surpass y, we create just enough jobs to reach y in total.
Using my example data we have:
"For the remaining (6-1) queue items, we will try to start (6-1)/10 jobs. "
so:
“For the remaining 5 queue items, we will try to start (0.5) jobs.”
So if logical algorithms gives half job → doesn’t it mean that no extra job should be started?
Changing the minimum number of items to trigger the first job (to something else that 1) will create risk of not processing items, if there are less than 5 to process. And they should be processed as well.
So it’s not an option to me in general, but I will try to see what happens in this scenario to figure out what is happening…
One thing that can wffect is the default interval check for the unprocessed items in rhe queue…generally it is set to 30 minutes it a tenant level setting you see under tenanrs → settings…if you would have lower it to less than 1 minute or less than 5 minutes these things might happen…can you check on the same
Ideally as per given scenario 3 jobs makes sense as one for 10 minutes check with new items present and other for 10 items as total items exceeded 10. but 6 looks little different.and also as far as the pattern is concerned I see two robots start at same time…which is little different as at any given point of time two would not start at once
let me try some testing from my end too and if you could try any other possible combination by changing unprocessed time check to 30 …that might help in understanding better
prashant1603765
V_Roboto_V
ashokkarale
arivu96
sharazkm32
Anil_G
pikorpa
postwick
jaswanthvarma.gottumukkal
adi.mehare