-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[2.1]: Mail queue not emptying #8314
Comments
It looks like you actually did add code to drop undeliverable email messages, @jdarwood007: SMF/Sources/ScheduledTasks.php Lines 808 to 811 in 938503e
If there is some other code that needs to be added elsewhere, please reopen this issue and add more details. |
I'm still testing another fix. Seems like it sometimes doesn't delete from the queue. In all this is just because I'm trying to fix this without a database change so I'm abusing the unused priority column to try to determine when we need to resend without dos remote mail servers. |
In that case, maybe it would be simpler and easier to base the decision to discard an email on the value of // Old emails should expire
if (!$result && time() - $email['time_sent'] > 86400 * 3) {
$result = true;
} That will give up after three days of unsuccessfully trying to send the email. Meanwhile, your code to adjust the priority will only have to deal with how often to retry and not with when to give up. |
The problem is, that our mail queue process will run as specified, let's say 60 seconds. Every 60 seconds if it's the only mail in the queue, it tries to send it. Which may upset some mail servers. Ideally, we would do something like slowly add more time. Such as every attempt we add something like a 30% increase to the time we next try it. For 3.0 I was thinking we would track a "next try" stamp and "tries". We would slowly add time until we have tried as many times as we think is correct (like 20). |
Sure, but throttling the retry rate is a different task than setting an expiry date. The problem where old messages are never being discarded from the queue is about the latter, not the former. |
Any suggestions? I'm running a test right now where I select (from our $number) 70% from the queue and then the remaining 30% is random, running those and processing them, adding a random check between 0 and 1. Increasing the priority by 1 every time it runs. Should ensure new mail gets selected but also tries randomly to grab older emails and process them. Ensuring that even if the queue gets clogged with bad emails, we still try fairly well to reprocess all of them and not dos. |
Here's a suggestion. Find:
Replace:
Note that I have not tested this on a live server. The bit under the comment The part that figures out As explained by the As I said, I haven't actually tested this on a live server, but it seemed to go pretty well in my mock-ups. |
I'm testing your code, it falls into the same problem I am having with my code. When the queue fills up and more sits in the queue than can be processed in a run, the old stuff never gets ran. If you have your queue setup to process 20 emails a pass and you have 25 emails all sitting in the queue that won't sent, the last 5 are not touched until the others that it keeps trying to send have expired. If you get a new batch, they have a lower priority and even if they get stuck, they are the only ones being attempted, the others stuck in the queue don't get touched. I think it falls into my idea I started to test which is 70% of the $number (in my example here 20*.7) would be the ones it grabs normally and then the last (20*.3) would be random ones it didn't grab. To sort of selectively grab out ones that may be stuck at a higher priority. |
Oh, I see. Then why not just add an extra query at the end that simply deletes queued emails that have expired? |
Basic Information
The mail queue was updated in 2.1.5 to address emails that can't be sent by adding a priority. I missed the code to have it delete emails after they reached the timeout (127). This should be a release blocker and a simple fix.
Steps to reproduce
Expected result
No response
Actual result
No response
Version/Git revision
2.1.5 GIT
Database Engine
All
Database Version
No response
PHP Version
No response
Logs
No response
Additional Information
No response
The text was updated successfully, but these errors were encountered: