I can't comment without looking in detail to what you are doing.
One of my reasons not to use it was exactly this, for every job fired you need to load the entire framework again.
In the end we decided to turn it around, and have a task that fires the queue worker (which is then a resident process, but running from the framework through oil), the queue worker can then call classes within the application (our modules have a classes/jobs folder for that) that have full framework access.
#!/bin/bash # # Queue manager script, to make sure the required number of worker instances # are running. Schedule this in cron to make sure any crashed workers will # be restarted. #
# Get the full path to ourselfs SCRIPTPATH="$( dirname "$( which "$0" )" )"
# how many workers do we need to start? if [ $# -gt 0 ]; then WORKERS=$1 else WORKERS=1; fi
# where does the php binary live? PHP=`which php`
# command that starts the worker COMMAND="$SCRIPTPATH/../../../oil refine queueworker"
# loop to process the worker instantiation while : do # bail out if we have started enough workers PROCESS_COUNT=`pgrep -f "$COMMAND" | wc -l` if [ $PROCESS_COUNT -eq $WORKERS ]; then exit 0 fi
# too many workers running? if [ $PROCESS_COUNT -gt $WORKERS ]; then # kill a worker off nicely PROCESS=`pgrep -f -n "$COMMAND"` kill -15 $PROCESS sleep 1 else # start a new worker $PHP $COMMAND & fi done
This script is called from cron every minute, the parameter comes from a file that the application admin can update from the app, so changing it (or disabling all queueworkers) will change the number running within a minute...
Our code is a bit different, but the principle is the same, yes.
It basically checks the queue for a job to run, a job being a static class method with some additional parameters. When a job is found, it's static method is called, so it's executed within the task context setup by oil when it called the run method of the queueworker, which means the method has full access to the framework.