In our production environment, we have a queue with approximately 1000 transaction items, out of which around 500 are currently in the ‘New’ status.
We have a ‘time-based trigger’ configured to run every 2 minutes, 24/7, and each time only one transaction item is processed.
Due to the high incoming volume, the backlog continues to grow daily.
I have the following questions:
Given that around 500 items are in the ‘New’ status, will switching from a ‘time trigger’ to a ‘queue trigger’ help address the backlog issue?
I understand that a ‘queue trigger’ initiates a job when a new item is added to the queue. In this case, what happens to the existing 500 ‘New’ items?
Will it create 500 jobs at once and potentially overload the system?
Is there a setting in Orchestrator where we can configure - the maximum number of jobs allowed in ‘Pending’ status (waiting for available machines)?
Is there a configuration or timeout setting that determines how long a job can remain in the ‘Pending’ status before it is marked as ‘Faulted’ due to unavailability of machines?
switching to queue trigger will help if robots are free. but i think it won’t process the 500 new items, only new items added after the change.
the 500 new items won’t create jobs all at once. only new items added after the change will trigger jobs. jobs will be processed one by one based on robot availability.
or i think might be you’ll need to either manually start jobs for them or use a time-based trigger alongside the queue trigger temporarily.
there’s no setting to limit jobs in pending,you can control concurrency or robot assignment to manage load.
no timeout for jobs in pending, jobs stay pending until a robot is available.
may I know was this a requirement or were you not letting the bot to process more than one? because if items are present ideally it would continue till all are done or till a fatal exception occurs
This can help ..again the queue trigger for already existing items will check after 30 mins by default it can be adjusted till5 minutes (as recommended) from orchestrator settings.but still once item is processed ideally next item should be picked you might need to work on that first
The job limit can be set
Same as above it triggers when new item is added or check for every specified interval if any new items are present as well..so it would trigger but with a delay.You can use below option as well
In queue trigger you would have an option for this you can configure it
A pending job can be set to timeout, using the ‘stop job after x’ and kill job after y’ settings.
A jobs runtime window starts as soon as the job is created, be it pending or running. So if you set a job to stop after 10 minutes, and it is pending for 5 minutes it only has 5 min runtime left.
Same for no run at all: if it has to stop after 10 minutes, and the pending state reaches 10 minutes this job is canceled as a whole.
Further, a queue trigger does pick up older new items as well. A queue trigger is triggered into 2 ways:
a new queue item arrives - the time trigger will fire immediately.
no new item arrives, but the queue has leftover ‘new’ items. The Orchestrator will check every 30 minutes (I think) and fire if new items are found.
When it comes to performance, time trigger of queue trigger, it won’t solve your capacity problem.
In order to squeeze more potential out of your setup consider processing more than 1 queue item in a row in a single session. (REFramework is ideal for it - out of the box).This will save time in overhead, such as setting up the session, starting and closing applications etc etc.
If this still does not resolve your capacity problem the ony solution would be to aquire and allocate additional licences so you can run more items in parallel.
may I know was this a requirement or were you not letting the bot to process more than one? -
The existing set-up is not letting bots to process more than one. I am surprised and
trying to figure out why it’s made that way during deployment. Due to current set-up - challenge is lot of jobs are failing due to unavailability of machine.
I am Ok if 100-200 jobs keep waiting for machine availability. I want to configure in such a way that - above error never appears.
I mean to say, I am ok if 100-200 jobs are lined up, but they should not time out. (I want to configure the time out as ‘unlimited’ for jobs as well)
This is a kind of solution I want to propose, but I thought of getting it validated by experts from the community.
In queue trigger you can configure simultaneously to 100 then you would have max 100 that can be in running plus pending..after that you would see this error..the above error is not when it timesput..but I believe in time trigger you are giving a specific user and as there is another job already running withsame name it is failing with above error
Please try to fix the bot to pick more items than one..check if there is a condition to stop after first transaction or if it is not created as transactional process at all..
You mean to say, the error is due to same bot simultaneouly trying to login to multiple machines?
When we are using a machine template set-up, unattended license allocation is for a bot, not for machine. In that sense, each bot gets 24 hours of run time.
Please confirm my understanding.
by rule only one pending job can be present for a robot combination..if machines are available and if parallel login is supported and enough licenses are there then ideally it would stay in pending or in running state
if any of the above conditions fail then it would be faulted as already pending job is present for same bot and user combination
ideally having 100 jobs in pending would not clear your issue unless you have 100 machines and licenses…having a queue trigger might clear the issue as even if the job stops or more pending jobs are not created you would still have queue trigger to trigger a job once a job completes and if there are new items present
