Our mailing list is about 15,000 long, and I have set the php.ini max timeout to 30 seconds because Bluehost clocks their CPU usage, and anything beyond that, they shut down php activity for the day. So we sent out the first issue of our newsletter today, about 100 email addresses at the beginning of the list got the emails - but the rest of the mailing list didn't receive anything. So I ran Cron manually through admin (I set it to 1000 emails per cron run).

Then instead of the normal, blank screen I get after every manual cron run, I got this message for EVERY EMAIL ADDRESS I tried to send:

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '<em>MySQL server has gone away\nquery: SELECT dst FROM url_alias WHERE src = &amp;#039;newsletter/confirm/remove/65015f362687t1&amp;#039;</em> in <em>/home/mizru/public_html/includes/database.mysql.inc</em> on line <em>172</em>.', 2, '', 'http://www.mizru.com/admin/logs/status/run-cron', 'http://www.mizru.com/admin/logs/status', '69.86.247.27', 1186533532) in /home/mizru/public_html/includes/database.mysql.inc on line 172

Is this something Simplenews-related, or Bluehost-related?

Thank you!

Comments

sutharsan’s picture

sutharsan commented

It looks like you lost connection with your MySQL server. The error message is found at MySQL site describes that the server timed out. I do not see how this can be related to simplenews.

mizru’s picture

mizru commented

I was on the phone with Bluehost support for about an hour, and the conclusion they came up with was that during the cron run, Drupal and/or Simplenews was trying to make 650 connections to their database server in one minute, while Bluehost has a 20 simultaneous connection limit. Do you know what could be causing these connections? Thanks!

sutharsan’s picture

sutharsan commented
Status: Active » Closed (fixed)

Please feel free to re-open this issue if you still need support.

eric.verhulst’s picture

eric.verhulst commented
Component: Miscellaneous » Code
Category: support » bug
Status: Closed (fixed) » Needs review

I am having the same problem with about 9000 subscribers. No issues on other customer sites with a feww 100 subscribers.

Going through the code, it looks like simplenews reads the whole subscribers database and then builds for every subscriber a drupal node in memory. There is a lot of going in and out of the databse. It then tries to send and when done it sets the s_status to 1 (send) one by one. This is where it fails (runaway query) and as a result some of the subscribers have received the mail a few 100 times, while the system also keeps retrying sending to invalid addresses.

At the end it resets ll records with s_status to 0 for the next run.

The module is hence not taking into ccount things that coudl you wrong.

e.g. is there enough memory (I am running on a virtual host with 48 MB)?

Would it not be better:

- to have a seperate field in the subscribers_table indicating succes or failure. (f_status)
- the s_status is immediately set to 1 when the mail is generated for the subsriber
- when succes => f_status set to 0, else set to 1

- the subsribers are read one by one from the database and not all at once.
- the s_status is left to 1 and there is a separate command in the newsletter menu to clear it before a new newsletter is sent. This also resets the f_status to 0
- why not add time to the subscribers table. Right now it is guess work to know if a mail was send or not.

This give salso automatic throttling (needed because of anti-spam rules).

Note that I didn't find the limit nuber of mails that CRON can send per run.

(I am not a php programmer, but coudl ask someone else to rewrite the module as above, but would like to know the reaction from the module maintianer first).

please contact me at eric.verhulst (at) openlicensesociety.org

sutharsan’s picture

sutharsan commented
Status: Needs review » Closed (won't fix)

This requires fundamental changes to the way Simplenews sends it emails. These changes have been implemented in 6.x but will not be back-ported to 5.x