On a site where I use your notification module to send out notifications, your module stopped working suddenly. I will describe my observations below, hoping that it will allow us to find out why this might be happening.
- Site with 53 users of which 2 are blocked.
- Only 1 content type gets notification mails sent out.
- Maximum number of notifications to send out per cron run: 50.
- Send out new notifications: each cron run.
- Last notification timestamp: 2017-05-05 18:01:01
- Status:
There are 1 node and 0 commentaire created between 05/05/2017 - 18:01 and 05/05/2017 - 20:01. No unpublished items. No notifications queued. No item is flagged for skipping. Batch not yet complete. So far 1 e-mail has been sent (1 failure, 1 utilisateur to go). The next notification is scheduled for the next cron run. Default MailSystem: system default.
Given these settings I observe that with each cron job run:
- variable notify_users contains 1 user, thus $batch_remain is "true" in _notify_select_content()
- _notify_select_content() does not return any content or comment that needs a notification for the period between 2017-05-05 18:01:01 and 2017-05-05 20:01:01
- Thus $count = 0 in _notify_send(), thus variable notify_users does not get reset (no call to variable_set()).
- Thus !$rest evaluates to false, thus variable notify_send_last does not get updated.
So it looks like there is no longer any advance in sending out notifications. When I deleted the variable notify_users on my test site, the status now becomes:
There are 6 nodes and 2 commentaires created depuis 05/05/2017 - 18:01.
No unpublished items.
Notifications about at least 8 items are queued.
No item is flagged for skipping.
No e-mails were sent.
The next notification is scheduled for the next cron run.
Default MailSystem: system default.
I cannot fully explain how notify_users got set in a time frame that has no notifications to sent, though it might be that content got deleted between the 2 cron jobs needed to sent out the 51 mails. So I think you'd better reset the variable notify_users also if $count = 0.
Does this make sense?
Comment | File | Size | Author |
---|---|---|---|
#2 | notify_remains_in_batch-2882664-2.patch | 410 bytes | fietserwin |
Comments
Comment #2
fietserwinThis is how I solved it for now(I will test further to see if this indeed solves the problem).
Comment #3
fietserwinOn the live site I did not manually delete the notify_users variable but installed the given patch and ran the batch manually once and indeed the status changed to indicate about new notifications to be sent out. Thus for me the patch works fine.
Comment #4
gisleThis situation should not happen (and it hasn't happened to me yet).
But looking at the code, it is clear that the module will get stuck if
notify_users
exists and there is nothing to send (i.e.$count
is 0). It also seems safe to delete the DB variable in this situation.So, without being able to reproduce, I've decided to move this to RTBC based on #3.
Comment #6
gislePatch committed in most recent snapshot of the 7.x-1.x branch
Comment #8
5f32525e CreditAttribution: 5f32525e as a volunteer and at CGI commentedWe had the same issue, which started to occur when sending notifications to _too much_ users using a cron run launched with wget. The time took by Drupal to lanch 500 e-mails is longer than the life span of an HTTP request, and wget ended up with « 504 Gateway Timeout ».
* To remove that variable, we used « drush config:edit notify.settings » and manual removal.
* We now moved to a crontab script that runs « drush core:cron »