How it Works: Cron Job in Magento 2

How it Works: Cron Job in Magento 2

For the purpose of speeding up Magento front end performance, some tasks are executed in separate processes in the background. Stock updating, cache flushing, catalog updating, product price calculating: these are very heavy and time-consuming processes, that’s why as general they are executed in the background and usually by Cron. The description of how to add 3 processes in Cron you can find in Magento 2 Developer Documentation.

The first command is primary, it initializes Cron in Magento 2 configuration. The second and the third are used for Magento 2 and its components updating. It’s enough to add only the first command in Cron for the basic work with it.

By the way, you can specify in the admin panel on what stage index execution should be done.

System->Index management.

How it works: Cron Job in Magento 2

On the current page you are able to choose indexing mode. There are 2 available modes in Magento 2:

  • Update on Save;
  • Update by Schedule.

When selecting the first mode: indexing is executed by saving the product, category, etc. But this method has some disadvantages: saving process takes much more time than usual, but all the changes are applied immediately.

When selecting the second mode: everything goes conversely. It doesn’t affect to saving process, and all changes are applied after saving. As a rule, the second mode is preferred. So let’s consider indexing process exactly in this mode.

So what happens when we launch the following command:

After this command is launched we are getting into object class

Magento\Cron\Console\Command\CronCommand into the execute method which is inherited from Symfony\Component\Console\Command\Command, as well as all console commands in Magento 2.

Initialization of input variables is performed in Magento\Cron\Console\Command\CronCommand::execute(), as well as process status check. If the check result is positive, then Magento\Framework\App\Cron object class is created and launch() method is called. Establishing of area code, configuration loading and calling to “default” event are executed in Magento\Framework\App\Cron::launch() method. Any modules and classes can subscribe to this event and all subscribed classes will be executed when the cron:run command is running. Here is the syntax that describes how it is possible to subscribe to this event:

It bears noting, that the event is called in areaCode=’crontab’, that’s why events.xml file should be placed in crontab directory of your module. This event is called anytime when cron:run command is launched, therefore you should not write here long-time execution commands because it can be the cause of blocking commands stack that Cron launches.

And Magento_Cron – Magento\Cron\Observer\ProcessCronQueueObserver modules observer is subscribed to this (“default”) event. The algorithm of Cron-tasks queгe is executed in particular object of the following class in the execute method. And for example this is how the Cron-task should be scheduled (the file must be placed in etc/crontab.xml folder):

This Cron-task will be processed in the object of class Magento\Cron\Observer\ProcessCronQueueObserver::execute().

Additionally, all the Cron groups that are specified in order of Cron-tasks creating in your module, are being chosen in the current method. For example, this is  id=”default” group. Initially, there are 4 groups are created in Magento 2: default, staging, index, catalog_events.

You can find these groups in  Stores->Configuration->Advanced->System.

How it works Cron Job in Magento

You are able to set up logs storage, the frequency of queue creating for the certain group and other parameters for each group. One of the most important property is “Use Separate Process”. It creates a new separate process for the certain group when you flag the “true” field.

If for some reasons, already existing groups don’t suit you, you can create a new one. For that, you should create a file with cron_groups.xml name in etc/ directory of your module and declare default parameters for this new group:

After you chose a group in execute method of Magento\Cron\Observer\ProcessCronQueueObserver class object, a call to shell command is happening, which is the launch of cron:run command with parameters for certain group.

The command is running with the following parameters:

As you can see, this command is running for index group tasks and the flag –bootstrap=standaloneProcessStarted=1 means that any child process has not been created, otherwise there could happen that each command creates Crons for all the groups and the process would enter an infinite loop.

Basically, there is no problem to launch this command by yourself in the console, and then tasks only from one group will be processed. But you have to be very careful and let the process be finished.

It is important because in case of incorrect stop, the current tasks would not switch their status from running to success (or error). And then, by the next call to task, we will always get the result that the command is in progress. Basically, it will lead to task call failure. There is only one way how to solve this problem: you have to delete “freezed” tasks manually from cron_schedule table.

It should be noticed, that for each group there is a Cron task created. That’s why the groups of tasks are executed individually. At the same time, these groups are executed consecutively, and the blocking could happen when the execution of some tasks takes too much time. Therefore, it is much better to create a new group for heavy tasks. Then this group would be called in a separate process, that wouldn’t lead to blocking other tasks.

In summary, we have just got acquainted with the Cron job in Magento 2. And you can note that Cron job in Magento 2 is pretty simple, logical and flexible.

1 comment

Post a new comment

BelVG Newsletter
Subscribe to our mailing list and get interesting stuff and updates to your email inbox.
Email *