I discovered a similar issue as described in this post, but think I figured out why behind the scenes
http://www.jomsocial.com/forum/technical-issues/23385-purging-the-mail-queue
The problem started when the queue gets large (over 10,000 records) and hasn’t been purged. In theory, a similar issue could also happen if your ‘totalemailpercron’ is set to be to high in your default.ini settings. The frustrating part about this issue is that you may never realize there is a problem as the email queue in backend reports everything as OK; when in reality your messages may not have been sent.
I can’t give you guys an easy way to replicate this because I have since purged my queue, and in addition the only way I knew there was a problem was when I didn’t get an email in my inbox. As mentioned, the queue said things were fine; and I don’t want too accidently send my users a million test messages debugging this
So since I can’t really show you the problem on my site (because of what I describe above) but I can show you the problem in the code. Are you guys hiring lol? I have now discovered and provided fixes to a few bugs at my own expense here ☺
When examining the cron task, there is function that called _sendEmails which does what it sounds like. This file calls a send function located here:
/components/com_community/libraries/mailq.php
The send function is located on line 19, and the problematic function call is located on line 23:
public function send($total = 100) {
$app = JFactory::getApplication();
$mailqModel = CFactory::getModel('mailq');
$userModel = CFactory::getModel('user');
$mails = $mailqModel->get($total, true);The problem arises in this call: $mails = $mailqModel->get($total,true). The second argument here refers to MarkedAsSent and is set to true. Therefore, as soon as any amount of messages are fetched from queue they are immediately marked as sent in the model. This happens regardless of whether the becomes blocked, or the script fails, times out etc…
So behind the scenes my cron task was timing out, but I would have never known because the emails were being marked as sent; everything seemed fine.
To fix this I would recommend setting that argument to false, and marking the items in the queue as sent after the "foreach" code when everything is processed. The interesting (or silly thing is) is that they are being marked as sent at the bottom of the function after everything goes through on line 107:
if (!$validate) { //email is blocked by user settings
$mailqModel->markEmailStatus($row->id, 2);
} else {
$mailqModel->markSent($row->id);
}So things are already being marked as sent in the appropriate spot once the messages have actually processed; so why do it at the top of the function on line 19? On line 19 we don't know if it sent successfully. Why not just let it set the status on line 107 alone? (doing same thing twice probably creates even more overhead).
I haven’t really discovered why it timed out, but probably just because the DB table was so big. I think that trying to send fewer emails at once will help. Fetching all the template content for each email is server intensive. It looks like this happened to someone else (post in first sentence) so doubt i'm the only one... it meant that many of our members didn't get notifications for almost a month which is unacceptable.
If the status is left alone until the email actually sends, at least people know there could be a problem. Next time the cron job goes it will try again where it left of when it timed out.
I can fix it on my end, however any changes I make may get wiped out with an upgrade, so this is why I’m suggesting it here (so maybe it gets changed in the core).
