6. Command Line¶
The notification bundle comes with one command which will listen to new incoming messages:
1 | 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.
1 2 3 4 5 6 7 | [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.
1 2 3 | 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:
1 2 3 | 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):
1 | 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):
1 | 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):
1 | 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!”}’