OroCRM Job Queue

Once you have OroCRM installed, if you navigate to

System -> Job Queue

you'll see OroCRM features a job queue. You won't, however, find a lot of explanation about what this is.

If you're not familiar with the concept, a job queue is a way for a programmer to say

Hey, I want this to happen, but it can happen later, so don't stop doing what you're doing

Job queues became popular in web programming when everyone realized it was probably a bad idea to have users wait for some long running thing to finish before showing the next page, and also realized that threads were a two edged sword — with both edges on the handle.

In keeping with lessons learned from Magento, the OroCRM team didn't reinvent the wheel when it came to job queues. They use the popular JMSJobQueueBundle for their implementation. Johannes site contains almost all the documentation for running the job queue you'll need.

I say almost, because there's a few things about the Oro UI implementation you'll want to be aware of.

First — you can start processing jobs in JMSJobQueueBundle by running the following app/console command

$ app/console jms-job-queue:run --max-concurrent-jobs=5 --env='prod'

This process will stick around for 15 minutes and run though any jobs in the queue. This is how I'd recommend you run these jobs as a developer working with OroCRM. (The instalation instructions recommend using something like supervisord for production systems).

What I wouldn't recommend is the "Run daemon" button. This launches an ajax request that attempts to start the job queue using a Symfony Process object. Running system processes from PHP is always a dodgey proposition, especially when the generated command line string looks like this

$ nohup php app/console jms-job-queue:run --max-runtime=999999999 --max-concurrent-jobs=5 --env='prod' > /dev/null 2>&1 &

Any output (standard or error) is redirect to /dev/null. Also, the use of the nohup utility from a web context is a problematic. The nohup command behaves different under different unixes and different shells. Add in the non-privlaged PHP/Apache user problem and you're in for some fun times. My attempts to get this feature to work from my local development Mac have met with failure, and the opaque nature of shell processes from PHP mean it's pretty hard to debug why.

So, skip the Run daemon button, and just run the job queue yourself from the command line.