Campaign emails stuck in outbound queue

SuiteCRM 7.8.2; Windows 10 Pro, V1803, Build 17134.228
Campaign emails successful for past week until (approx.) mid-day Sep 10, suddenly won’t exit outbound queue. No changes made to OS or SuiteCRM.
Logged in as SuiteCRM user on Firefox 58.0.2; populated/configured each Launch Wizard tab, then pushed ‘Send Mail at Scheduled Time’.
At same time on Chrome 68.0.3440.106 was logged into SuiteCRM as Admin; Email Queue shows the campaign email(s); pushed ‘Send Queued Campaign Emails’ but no longer sends them out (never needed to check their boxes but also tried it with no change).
Read through some other users’ web posts and made these changes with no effect:
• Activated ‘Run Nightly Mass Email Campaigns’ Scheduler event (this had not been active previously)
• Extended its interval period to ensure the actual time I was testing was within it.
• Reconfigured ‘EmailManDelivery.php’, line 225,
“if ($outboundEmailAccount->mail_sendtype == “smtp”)” to “if ($outboundEmailAccount->mail_sendtype == “SMTP”)”

This is the busiest time of year for my email campaigns; any help is urgently appreciated.

There’s something I don’t understand about your description. If your Scheduler Job was inactive, how did the Campaigns go out when it was working? Did you always go into the Mail Queue and press “send” manually?

The first thing I would advise is to check your logs, see what’s in there at the time of the failed send.

Make sure you check both:

php_errors.log (or whatever your web server log is called… on Windows, this might be inside Event Viewer, not sure).

Hi PGR, thanks for stepping in. Yes, I always send via the manual button, primarily because my email provider limits messages to 100/hr, which is ok for my scale. I tried this change just because another post said it helped their problem and didn’t think there was anything to lose.

I did check the log(s) each time and didn’t see anything that seemed related to this failure. A recurring message is “Using row number in fetchByAssoc is not portable and no longer supported. Please fix your code.” I don’t know if this is related.

In the meantime I upgraded from 7.8.2 to 7.8.20 hoping that it might reset any erroneous values to default but no luck. Then, as a shot in the dark based on another post where a user of cron scheduler reduced the default 500 'Number of emails sent per batch to 50 and had success. I have just reduced mine from 500 to 100 and the single contact campaign email was sent. So I will try a larger batch of emails and will report back here. I’m still pretty sure I never changed any Suite or Windows configuration.

Lowering the email batch limit value from (default) 500 that I’ve never changed (since March 2017 installation) to 100 is allowing me to send batches of emails. I’d be interested to understand how this came about.
PGR - thanks for following up.

It’s always possible that your provider has changed its policy, and now enforces a stricter limit.

Another possibility is that something else is breaking the process when it needs to handle larger amounts. Something as simple as running out of memory could be happening (memory_limit in php.ini). But this would leave a message in your php_errors.log.

Any way: SuiteCRM is ready to handle such SMTP provider limits. If you set the scheduler once per hour, and use the batch limit of whatever they say (for example, 100), then you can simply schedule when your Campaigns start and SuiteCRM will take care of everything, in batches.

For those who are still checking this thread. The way I did it was to select the emails in the queue and do a Mass Update. Set the “In Process” : No and
“Send Date”: any date in the past and save
Now click “send queued campaign emails”

1 Like

@jmathew, I am still checking this thread. I had difficulty understanding why I could send queued campaign emails for one campaign and not another. After a bit of stress and reading through the forum multiple times, it became clear to me that;

The " send queued campaign emails" button ONLY works for emails scheduled in the past. Thanks a bunch!