Scheduler Service: Error dequeuing events


I'm looking at Service Center trying to triage some overall environment performance issues, and seeing the following error occurring quite frequently:

"Scheduler Service: Error dequeuing events"

The stack trace always shows a SQL timeout error, which sometimes starts with:

"Scheduler Service: Error dequeuing events
Transaction (Process ID XXX) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction

Is anyone familiar with this error? I'm wondering if it's just a red herring, occurring because our environment has multiple front end servers all sharing a single database server, and if therefore deadlock scenarios are inevitable? Or if this is perhaps a legitimate issue that might be inducing the environment performance issues I'm seeing?



Hi Kirk,

My production server also encountered this recently. I think some scheduler service is not up properly in one of the front end server.

I managed to clear this error by rebooting all the front end server. I think if we let the error running, the scheduler in the enviroment health will eventually flag as warning and some of the timer processes like sending of emails may get affected

Hello, any update on this issue? We also have this error in Production server only.

Not always resulting to a timeout, but most of the time occurs within a business Action.


I am not familiar with the scheduler. But I think you should start investigate the deadlock issue.

A deadlock is when two processes tries to use the same resources, but in different orders.
Most likely the resource is a database record.

Outsystem protects all processes as a complete transaction. Which means data records that are updated will be locked until either commit / rollback. This occurs at a record level. If any two process updates multiple records in the same table, this may occurs. Imagine any two record A and B in the same table, Process ID 1 first updated record A, then it tries to update record B. Before it does, Process ID 2 is already running and has already updated record B, and then process ID 2 tries to update record A. This means, both of the process is locking the record the other is trying to update. This results in a deadlock. And one of them has to be terminated and rolled back.

The main issue with deadlock is that it require two process to trigger, and often needs to be triggered in the exact same time. So it is rather difficult to test and debug.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.