Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.2.7

Bug #16995 mail stops sending from queue intermiddently
Submitted: 2010-01-14 16:45 UTC
From: spitfire Assigned: till
Status: Closed Package: Mail_Queue (version 1.2.3)
PHP Version: 5.2.5 OS: Linux
Roadmaps: 1.2.4    
Comments Add Comment Add patch

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 43 - 15 = ?

 [2010-01-14 16:45 UTC] spitfire (David Cooper)
Description: ------------ I want to start out by saying how much I like this package. I have the mail sent on a cron and it will work for while then stop. The script returns then the error message below. This is not continuous which makes it harder to detect. The only way to restart it, that I have found it to empty to the mail_queue table at which point it works fine for several runs until it stops again. Any help would be greatly appreciated. Test script: --------------- include('mail_queue.config.php'); /* How many mails could we send each time the script is called */ $max_amount_mails = 75; /* We use the db_options and mail_options from the config again */ $mail_queue =& new Mail_Queue($db_options, $mail_options); /* Really sending the messages */ $mail_queue->sendMailsInQueue($max_amount_mails); ?> Actual result: -------------- Fatal error: Call to undefined method Mail_Queue_Error::getRecipient() in /usr/local/php5/lib/php/Mail/Queue.php on line 433


 [2010-01-14 16:47 UTC] bate (Marco Kaiser)
-Status: Open +Status: Feedback
can you please try your code without the & in $mail_queue =& new Mail_Queue ie. $mail_queue = new Mail_Queue
 [2010-01-14 17:14 UTC] spitfire (David Cooper)
Taking the & out didn't seem to make any difference. What I have noticed however is that when it stops sending the message in the queue with the lowed id has a number between 0 and 25 for tries sent. That is to say it didn't send on the first time but didn't try 25 times when it passes over.
 [2010-01-14 17:21 UTC] bate (Marco Kaiser)
Can you please provide smallest running example code so that i can reproduce that? Try without database stuff ...
 [2010-01-14 17:26 UTC] spitfire (David Cooper)
Do you mean this? include('mail_queue.config.php'); /* How many mails could we send each time the script is called */ $max_amount_mails = 100; /* We use the db_options and mail_options from the config again */ $mail_queue = new Mail_Queue($db_options, $mail_options); /* Really sending the messages */ $mail_queue->sendMailsInQueue($max_amount_mails);
 [2010-01-14 17:31 UTC] till (Till Klampaeckel)
No, please include your "mail_queue config". Also, are you using the latest version? (I'm just making sure) :)
 [2010-01-14 20:47 UTC] spitfire (David Cooper)
Many thanks for your help on this. I did an update on the library earlier, to ensure it the current version. It hung again, this time a message with 18 tries was the cause, once this was deleted, it started again. Here is the file, with passwords etc xxxxed out: // Pear library: require_once ('Mail/Queue.php'); // Options for storing the messages // Type is the container used, currently there are 'creole', 'db', 'mdb' and 'mdb2' available $db_options['type'] = 'mdb2'; // Database access: $db_options['dsn'] = 'mysql://mail_queue:xxxxxxxxx@localhost/midas_local'; $db_options['mail_table'] = 'mail_queue'; // Here are the options for sending the messages themselves // These are the options needed for the Mail-Class, especially used for Mail::factory() $mail_options['driver'] = 'smtp'; $mail_options['host'] = ''; $mail_options['port'] = 25; $mail_options['localhost'] = 'localhost'; //optional Mail_smtp parameter $mail_options['auth'] = true; $mail_options['username'] = 'xxxxxxxx'; $mail_options['password'] = 'xxxxxxxx';
 [2010-01-14 21:00 UTC] till (Till Klampaeckel)
Ok, first off, thanks for staying with us. :D Then, I just realized the error is simple. But probably not something you can fix. I'm assuming that the error is from your database connection, or something -- maybe it times out, etc.. Give me an hour or so and I'll have a patch for you to try.
 [2010-01-14 21:11 UTC] till (Till Klampaeckel)
-Assigned To: +Assigned To: till
Hey David, here's the commit: r1=288406&r2=293549 Please let me know if this helps your situation. It should improve error handling in Mail_Queue and at least help you debug why there is an error. Btw, I noticed that the line where the error occurs is different from trunk, but who knows why that is the case. Trunk might contain other bugfixes. Cheers, Till
 [2010-01-14 21:36 UTC] spitfire (David Cooper)
Thank you Till - I have installed the patch and set it running again - its sending okay, I'll watch and see if it stops and let you know. Very grateful for your help!
 [2010-01-14 22:07 UTC] spitfire (David Cooper)
Different error now - I got several lines of Notice: Error in sending mail: Mail Queue Error: db query failed in /usr/local/php5/lib/php/PEAR.php on line 896 followed by: Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 32 bytes) in /usr/local/php5/lib/php/PEAR.php on line 872
 [2010-01-14 22:58 UTC] till (Till Klampaeckel)
Do you use any PEAR error configuration? It sounds like you loose the db connection, and the memory limit is hit. The thing is that re: the db connection, you could up the mysql timeout and as for the memory_limit, it looks like you have a limit of 32 MB? Which is not too much and pretty conservative. I know people generally hesitate to up that, but on the other hand the standard PHP install comes with 128 MB at least. To track memory usage, do the following: In Mail_Queue::sendMailsInQueue() (Mail/Queue.php), there is a while() loop, feel free to var_dump(memory_get_usage()); inside of it. If it grows, I'm guessing we could improve memory handling there. How large are your emails?
 [2010-01-14 23:07 UTC] till (Till Klampaeckel)
Nevermind my PEAR Error config question -- we issue an E_NOTICE ourselves. Not the most pretty way to display/handle an error, but I guess the objective is to not "cancel" the process just because a single message fails. Also, please try this "patch": r1=293549&r2=293552
 [2010-01-15 17:46 UTC] till (Till Klampaeckel)
Any updates? Let me know, I'd like to pronounce this bug as fixed. :)
 [2010-01-15 17:51 UTC] spitfire (David Cooper)
Unfortunately not - the problem pesists
 [2010-01-15 21:02 UTC] till (Till Klampaeckel)
Which one exactly? The E_NOTICE hints that something with the db failed. Or is the memory_limit still being hit? If this is the case, can you increase it?
 [2010-01-15 21:24 UTC] till (Till Klampaeckel)
Made another commit to improve error "handling", this should allow you to see what your DB error is: .php?r1=288376&r2=293586
 [2010-01-20 17:41 UTC] till (Till Klampaeckel)
-Status: Feedback +Status: Closed -Roadmap Versions: +Roadmap Versions: 1.2.4
This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. David, I'm gonna pronounce this fixed. Thank you very much for your bug report and feedback. If this happens to be still an issue, feel free to re-open. I'll see if I can roll a release by next week. Till