Posted by mark_anthony on May 19, 2009 at 12:58pm
| Project: | Notifications |
| Version: | 6.x-2.3 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
My site has been running incredibly slow if at all sometimes, The Recent log entries page shows multiple entries of : "Reached processing limit on queue processing: ..."
In Details, the Type is listed as : notifications. Does this mean it is being generated from the Notifications module?
These entries are like a minute apart, if that much.
I have attached a screenshot of the dblog screen.
Comments
#1
#2
My site is not running slow, but my symptoms are similar:
I have emails set to HTML by default.
I'm running:
FreeBSD 6.3, Apache 2.2.11, PHP 5.2.9, MySQL 5.0.75, Drupal 6.12, Notifications/Messaging 6.x-2.0, PHPMailer 5.02
#3
This may happen if you either mess with the process limit options or if you don't run cron often enough.
So, settings? how many rows in queue? how often do you run cron?
Which specific processing limit is hit? (Full message).
#4
I can have 2 short messages, and run cron every 15 minutes, and have virtually nothing else going on on the server. No matter the limits set in the Notifications settings, it still gives this "Reached processing limit" error. In fact, the processing limit can be set for thousands of seconds, and it'll still timeout in about 3 seconds after cron runs.
#5
Hi:
I had the same problem and changed the following line in file notifications.cron.inc and solved the problem.
line 128:
$cronstart = time(); //variable_get('cron_semaphore', time());variable "cron_semaphore" is Boolean. This is correct?
Thanks.
#6
Nope, cron semaphore is numeric (time).
You guys using poormanscron?
#7
I'm using Elysia Cron running every minute with notifications running every 15 minutes and am having exactly the same problem ... the processing limit from the notifications admin page is meaningless on my site, it fails almost immediately after starting regardless of what large value I put there. This is not a case of too many records to review. The "fix" above did not fix my site but setting all notifications limits to 0 did... this will suffice for the time being but, of course, defeats the purpose of having those limits in the first place.
#8
subscribing
#9
Important warning: Using % of cron time won't work.
Drupal 6.14 broke backwards compatibility for this, though that will be fixed in the next release. See http://drupal.org/node/193383
In the meanwhile, don't use % of cron time, use absolute time values instead.
#10
I also see a list of "Reached processing limit on queue processing" messages in my recent log entries page. However, I am using the number of messages limit to *avoid* the manifestation of another problem - namely, my process dying and (what I consider to be much more serious) problem of duplicate messages being sent, which I talk about here: #574974: Multiple copies of the same message sent to the same user
Is this considered an appropriate use of the processing limit field?
#11
It's probably bad form replying to oneself, however....After much searching and having gone outside of Drupal for errors, I found my particular issue and it was related to another with Notifications ... I had removed "mimemail" from the system yet there were still some users that had notification settings to use mimemail. After fixing this, I no longer see any time limit problems. I'm assuming this is more than a coincidence ... essentially the time limit error report is bogus but there was an error to fix so you can't ignore the report.
#12
I see no definitive answer to this. My site recently started having this problem, too. I am getting 3 errors back to back all stating:
Reached processing limit on queue processing: time = 1264901638I have no limits on queue processing set (they are 0).
This set of errors causes another more serious problem: after these are logged, cron no logner runs from my crontab per the system status report (I use regular unix cron):
0,30 * * * * /usr/bin/curl --silent --compressed http://www.sitename.org/cron.php >/dev/null 2>&1When this problem is in effect, curl returns "page not found" as an error when I run it manually from the server command line, and cron.php run remotely from a browser doesn't cause the queue to be processed!
To clear the problem, I have to go into the status report and click run cron manually at admin/reports/status/run-cron - this runs cron and CLEARS the crontab problem!!! The notifications sitting in the queue then drain out, and all's well until is jams up again.
I am using Notifications 6.x-2.x-dev notifications.module,v 1.6.2.9.2.50.2.10 2009/06/16 15:23:09 jareyero
on Drupal 6.13.
Any ideas would be welcome!!!
--glen
#13
Any maintainers out there look at this issue?
The problem is occurring on a site where there are over 600 subscriptions to 5 separate taxonomy terms. The processing seems to run very slowly sometimes (the dequeue is about 10 messages every 5 seconds) perhaps due to server loading, and perhaps the cron thinks that the queue is having trouble due to the amount of time it runs (cron starts at :00, processing limit message comes at :04). There are over 400 messsages left in the queue, which means that it failed the processing only about 1/3 of the way into one of the messages. Everything else is stuck behind it until you force a cron run or process immediate.
The message are being sent through PHPMailer.
-- glen
#14
I've been looking into a similar issue.
We get 'Reached processing limit on queue processing: time' appearing several times on a lot of our cron runs, although we don't have any limits set in the notifications settings. It seems to be when the site gets busy, and if the site gets busy cron can go on for a while..
Notifications cron looks at max_execution_time from php.ini - and I think it triggers 'Reached processing limit..' if cron has already been running for more than max_execution_time.
We're going to raise max_execution_time a bit and see how we get on.
#15
When no time limit is set, the default is max_execution time - 5 seconds. This is needed for a clean stop of processing.
The solution here should be along the lines of:
- Setting limits according to your system load/ performance and max execution time.
- Run cron more often.
Another potential issue is an out of memory error, that will just crash the process without an error message. The memory usage will be much lower if you use the 6.x-2.0-dev package.
But anyway, if you get out of memory errors, you should set some limit for the number of rows processed.
Other option would be sth like #737238: provide a "don't process on cron" feature
Also I invite everybody to give a try to the 6.x-4.x branch which does a much better memory management and optimized queries, which should result in better performance.
#16
Automatically closed -- issue fixed for 2 weeks with no activity.
#17
Although reported "fixed" above, there is no patch and no indication of the location of the fixed version.
#18
This patch corrects the problem for 6.x-2.2.
I'm closing this, presuming it's fixed in the latest dev. Re-open this if it's not.
#19
Since yesterday I have these messages in log:
notificaties 4 Feb 2011 - 10:53 Reached processing limit on queue processing: time = 1296813236
notificaties 4 Feb 2011 - 10:53 Reached processing limit on queue processing: time = 1296813236
notificaties 4 Feb 2011 - 10:53 Reached processing limit on queue processing: time = 1296813236
notificaties 4 Feb 2011 - 09:53 Reached processing limit on queue processing: time = 1296809636
notificaties 4 Feb 2011 - 09:53 Reached processing limit on queue processing: time = 1296809636
notificaties 4 Feb 2011 - 09:53 Reached processing limit on queue processing: time = 1296809636
notificaties 4 Feb 2011 - 09:23 Reached processing limit on queue processing: time = 1296807837
notificaties 4 Feb 2011 - 09:23 Reached processing limit on queue processing: time = 1296807837
notificaties 4 Feb 2011 - 09:23 Reached processing limit on queue processing: time = 1296807837
...
Modules:
Drupal core 6.20
Mail Editor 6.x-1.x-dev (2010-Dec-28)
Messaging 6.x-2.3
Mime Mail 6.x-1.0-alpha7 (alpha7 from yesterday!!!)
SMTP Authentication Support 6.x-1.0-beta5
...