6. Command Line

The notification bundle comes with one command which will listen to new incoming messages:

bin/console sonata:notification:start --env=prod --iteration=250

This command must be started in production environment to limit memory usage produced by debugging information.

The iteration option is the number of iterations the command can accept before exiting. This iteration value must be set to avoid memory limitations or other issues related to PHP and long running processes.

6.1. Monitoring process : Supervisord

This command should not be used directly on a production server. The task must be supervised by a process control system. There are many solutions available. The following solution uses supervisord.

Supervisor is a client/server system that allows its users to monitor and control a number of processes on UNIX-like operating systems. Replacing “yourapp” with a short name for your application, create a new file at /etc/supervisor/conf.d/yourapp.conf. Update the paths and names in this example file as is appropriate for your use-case.

[program:yourapp_sonata_notification]
command=/home/org.sonata-project.demo/current/bin/console sonata:notification:start --env=notification --iteration=250
autorestart=true
user=www-data
redirect_stderr=false
stdout_logfile=/home/org.sonata-project.demo/logs/sonata_notification.log
stdout_logfile_maxbytes=10MB

You can check on the status , stop, and start the service with the following respective commands. Read the supervisor documentation for more details.

supervisorctl status yourapp_sonata_notification
supervisorctl stop yourapp_sonata_notification
supervisorctl start yourapp_sonata_notification

If you are deploying with Capistrano, you can restart the supervisor process with a custom task:

after "deploy:create_symlink" do
    run "supervisorctl -u user -p password restart sonata_production_sonata_notification"
end

Note

By default, the Symfony2 provides a cross finger log handler. This handler is not suitable for long run processes as each log entry will be stacked into memory. So the notification process can stop with a memory usage error. To solve this, just create a new env called notification without this handler.

6.2. Clean up messages

You might want to clean old messages from different backend (if ever a backend holds them):

bin/console sonata:notification:cleanup --env=prod

6.3. Restart erroneous messages

In case of getting messages with an erroneous status, you can reset their statuses and they will be reprocessed during the next iteration (this command must be used for the database backend):

bin/console sonata:notification:restart --type="xxx" --max-attempts=10

You can get this command to run continuously with the –pulling option and you can set the delay between the time the message has been set to error and the time the message can be reprocess with –attempt-delay option (in seconds):

bin/console sonata:notification:restart --type="xxx" --pulling --max-attempts=10 --attempt-delay=60 --pause=500000 --batch-size=10

6.4. Create and publish messages

For testing purpose, you might want to manually create and publish messages

… code-block:: bash

bin/console sonata:notification:create-and-publish logger ‘{“level”:”debug”,”message”:”Hello world!”}’