Hi all,
My team and I are having an issue where our front-end test server is unable to run multiple instances of the same timer, or two different timers concurrently.
We have an OS11 Traditional Web application where users can upload Excel files in a specific format. The application processes these uploaded files using two timers:
During our testing we've noted that for larger Excel files both timers can take multiple hours to complete. Unfortunately, when such a file is busy processing we're unable to process another file until the first file finishes processing. The same issue occurs when a file is being processed with the second timer, but we try to process a new file with the first timer.
The weird thing is that according to the front-end's Configuration Tool's Scheduler tab the Max. Concurrent Timers value is the default value of 3, so we don't expect this issue to occur.
What could be the potential reasons for this issue? If we need to provide additional infra- or other specific details we will do our best to do so.
Hello @Lloyd Philbert,
Here is all I know: Yes, you’re right, timers in OutSystems can run up to 3 threads, meaning 3 timers can be dispatched and run concurrently. But the important part is what “dispatched” actually means.
The scheduler can start the timers at the same time, but something in the logic itself can still cause one timer to block the others. For example, if a timer runs a server action that starts a transaction and there is no commit until the very end in other words session transaction, then a database lock might be held for the whole duration of that logic. In this case, when timer 2 starts, it does initiate its logic, but once it reaches a database operation that conflicts with timer 1 on the same table for example, it will wait until timer 1 finishes and commits. This usually happens when the logic is committed all at once instead of being processed in chunks, which can also cause all the work to be rolled back if a failure happens.
Another scenario could be related to timer priority, where multiple timers with the same high priority are running at the same time and timer 2 has a lower priority, so it gets delayed.
Finally, timer 2 might depend on some logic from timer 1, like a status update, but it cannot see it yet because the transaction is still open or the record is still being processed.
All of these are scenarios you can look into, it might be one of them. Hope it helps you.
Hi @Lloyd Philbert,
not being able to run the same timer in parallel is not a problem, that's a feature. Why you can't start 1 when 2 is still running, that's a question, maybe answered by what @Sherif El-Habibi is saying, some database lock or other. That could easily be tested by logging at start and end of al your timers.
But if you are talking about multiple hours to validate a single excel file, that sounds enourmous. Are these files extremely big ?? Or are you calling several slow api's or something ?
Having a single piece of logic trying to process all of this, might not be the solution, even if it is inside a timer. (Maybe that's why you have split it up in 2 steps, in an attempt to keep the work smaller ??)
Also, listening to your story, you are talking about processing taking hours, that doesn't sound like you are currently applying best practices like making your timer take a breather every x minutes or every x rows processed and start itself over ??
It is very hard to say what you should do without knowing more about the functionality and complexity and workload of these validations, and without knowing how many rows in an excel file, but I will still suggest this as a possible avenue to explore :
Make use of a staging table
Dorine
I think @Sherif El-Habibi and @Dorine Boudry have shared the main parts of the approach. For the timer, just keep in mind:
Hi @Sherif El-Habibi, @Dorine Boudry and @Shingo Lam,
Thank you all for your helpful suggestions. Based on what I can gather, I highly suspect the timer blocks are caused by ongoing server action transactions in both timers which need to be completed before they are committed.
Our team will analyze the underlying logic this week to find ways how to best implement your suggestions. I'll update this post if we experience any further roadblocks.
You’re very welcome.
Glad to support