academe / laravel-queue-monitor Goto Github PK

So this also means a configuration file needs to be supported.

List the changes made over the original fork. Includes the additional data that is captured (which could possibly be something we can turn off by configuration).

This is a problem I've not seen on MySQL but am seeing on Azure SQL Server.

If no jobs are processed for some time - in the order of a few hours - then the database connection seems to "go bad". This results in a failure to dispatch any further jobs from the queue, with an error:

[2018-04-17 23:02:17] production.ERROR: SQLSTATE[08S02]: [Microsoft][ODBC Driver 13 for SQL Server]SMux Provider: Physical connection is not usable [xFFFFFFFF]. (SQL: select top 1 * from [queue_monitor] where [job_id] = 66084abc-7654-4b2c-82fa-a66e655eeb6d order by [started_at] desc, [id] desc) {"exception":"[object] (Illuminate\Database\QueryException(code: 08S02): SQLSTATE[08S02]: [Microsoft][ODBC Driver 13 for SQL Server]SMux Provider: Physical connection is not usable [xFFFFFFFF]. (SQL: select top 1 * from [queue_monitor] where [job_id] = 66084abc-7654-4b2c-82fa-a66e655eeb6d order by [started_at] desc, [id] desc) at .../vendor/laravel/framework/src/Illuminate/Database/Connection.php:664, PDOException(code: 08S02): SQLSTATE[08S02]: [Microsoft][ODBC Driver 13 for SQL Server]SMux Provider: Physical connection is not usable [xFFFFFFFF]. at .../vendor/laravel/framework/src/Illuminate/Database/Connection.php:326)

I guess the events are registered in the long-running job worker process, and it is that process that attempts to log the job details, and the database connection does not stay open for long waiting for that to happen.

The exception also does not put the job into the failed jobs queue, so it is effectively lost. This means it is absolutely essential that no event handlers registered against the job dispatcher must throw ANY exceptions. It is very important to catch any kind of error, perhaps log it, but then return to the caller.