Symfony Swiftmailer stop sending process to show status - php

Question

In our application, for some actions we send out notifications and emails to a rather large number of users (several hundred to thousand). For some purposes we have to send these emails/notifications separately which I did, using a foreach loop.
For about 200-300 users, that's working fine, but as soon as there are more users to be notified, we get a timeout after a while.
What I was now thinking to do, is redirect to a new page, after e.g. a document is created, and handle the email/notification send out there by sending out let's say 20 emails, then display an update like "20 out of xxx emails/notifications have been sent out", then continue sending the next 20, displaying an update and so on.
Is there any body who already did something like this or has ideas on that?
Here is my code so far:
{
document gets created...
$em->persist($document);
$em->flush();
$this->addFlash(
'success',
'Your document has been created!'
);
return $this->redirectToRoute('documentBundle_document_send_notifications', array('id' => strtok($document->getId(), '_')));
}
/**
* #Route("/document/sendNotifications/{id}", name="documentBundle_document_send_notifications", requirements={"id" = "\d+"})
*/
public function sendDocumentNotifications($id){
$em = $this->getDoctrine()->getManager();
$document = $em->getRepository('DocumentBundle:Document')->findOneById($id);
$statusRepository = $em->getRepository('DocumentBundle:Status');
/*
* NOTIFICATION MANAGEMENT
*/
//Users
$user = $em->getRepository('UserBundle:User');
$user = $user->findByDocumentAgency($user, $document);
$users = array_unique($user->getResult());
if(count($users)>0){
/*
* SEND NOTIFICATION
*/
foreach ($users as $user){
$manager = $this->get('mgilet.notification');
$notif = $manager->generateNotification('A Document has been created!');
$manager->addNotification($user, $notif);
}
/*
* SEND EMAIL
*/
foreach ($users as $user){
$recipient = $user->getEmail();
$this->get('MailerHelper')->sendMessage($recipient,...);
}
}
}
return $this->redirectToRoute('documentBundle_document_list');
}
EDIT
added a console command to run as a background process
/**
* #Route("/document/sendNotifications/{id}", name="documentBundle_document_send_notifications", requirements={"id" = "\d+"})
*/
public function sendDocumentNotifications($id){
$em = $this->getDoctrine()->getManager();
$document = $em->getRepository('DocumentBundle:Document')->findOneById($id);
$process = new Process('php app/console app:send-notifications', $id );
$process->run();
dump($process);
return $this->redirectToRoute('documentBundle_document_bulkDeactivate');
}
when dumping the process, I get the correct commandLine and the input is the correct document Id, but it says:
Process {#1539 ▼
-callback: null
-commandline: "php app/console app:send-notifications"
-cwd: "/srv/http/sp/web"
-env: null
-input: "320"
-starttime: 1511378616.9664
-lastOutputTime: 1511378616.9852
-timeout: 60.0
-idleTimeout: null
-options: array:2 [▼
"suppress_errors" => true
"binary_pipes" => true
]
-exitcode: 1
-fallbackStatus: []
-processInformation: array:8 [▼
"command" => "php app/console app:send-notifications"
"pid" => 29887
"running" => false
"signaled" => false
"stopped" => false
"exitcode" => 1
"termsig" => 0
"stopsig" => 0
I then tried it with
$process->mustRun() and gut the following error:
The command "php app/console app:send-notifications" failed.
Exit Code: 1(General error)
Working directory: /srv/http/sp/web
Output:
================ Could not open input file: app/console
Error Output:
500 Internal Server Error - ProcessFailedException

Answer 1

TL;DR: to prevent time-outs, offload your process to a background process.
First step: use a spool
A quick win would be to Spool Emails:
When you are using the SwiftmailerBundle to send an email from a
Symfony application, it will default to sending the email immediately.
You may, however, want to avoid the performance hit of the
communication between Swift Mailer and the email transport, which
could cause the user to wait for the next page to load while the email
is sending.
The actual mails will be sent by a command line script:
php bin/console swiftmailer:spool:send --env=prod.
Next step: create a command that handles notifications
Learn how to create a console command. Something like this (not tested, just as an example):
class NotificationCommand extends ContainerAwareCommand
{
protected function configure()
{
$this
// the name of the command (the part after "bin/console")
->setName('app:send-notifications')
// the short description shown while running "php bin/console list"
->setDescription('Send notifications to information users about a new document.')
->addArgument('document', InputArgument::REQUIRED, 'The ID of the new document.')
;
}
public function execute(InputInterface $input, OutputInterface $output)
{
$em = $this->getContainer()->get('doctrine')->getManager();
$document = $em->getRepository('DocumentBundle:Document')->findOneById($input->getArgument('document'));
$statusRepository = $em->getRepository('DocumentBundle:Status');
/*
* NOTIFICATION MANAGEMENT
*/
//Users
$user = $em->getRepository('UserBundle:User');
$user = $user->findByDocumentAgency($user, $document);
$users = array_unique($user->getResult());
if(count($users)>0){
/*
* SEND NOTIFICATION
*/
foreach ($users as $user){
$manager = $this->get('mgilet.notification');
$notif = $manager->generateNotification('A Document has been created!');
$manager->addNotification($user, $notif);
}
/*
* SEND EMAIL
*/
foreach ($users as $user){
$recipient = $user->getEmail();
$this->get('MailerHelper')->sendMessage($recipient,...);
}
}
}
}
}
To execute this, run bin/console app:send-notifications 1 on your command line.
Schedule your command
I guess you don't want to log into the server manually to send the notifications, so instead you can create a general 'send notifications if needed' command that can scheduled by a cron job.
As a next step you can take a look at a way to queue your commands. Take JMSJobQueueBundle for example.
Bonus tip: start by making your controllers thinner
Try to make your controllers thinner. Read this old, but still interesting blog. If you create services and call them from the controller (instead of having a fat controller), the 'refactoring' job of removing code from controller to background job (and maybe visa versa) is much easier.