Aaryan Bhagat writes: > - In the case of `Send_Warnings` function if the same approach was > followed, meaning it would take one by one the `Address` instances, > check tuples in the `bounce_info` attribute ( see the pr for this ) > and see whether to send a warning mail or not to can be a slow > method. > > - Let's suppose the `Addresses` list is very long, then an `Address` > instance in the very bottom of the list whose subscription has been > disabled and some warning emails send, now waits to receive another > mail as the interval is more than > `bounce_you_are_disabled_warnings_interval`. > > - If the function is enumerating from the top then in order to take > action first it has to reach this `Address` instance but the > interval is already crossed. This can cause slow performance as the > `warning mail` will be sent way late than it actually should have > been sent.
I assume that what you mean here is that this process is executed perhaps once per day and probably takes a few minutes at most in processing. Then we have 300s/86400s = 1/288 of a day = probability that during the interval that address's timer expires, and the message is delayed until the process triggers again, hypothetically a full day. The odds that this happens is quite small unless you have a humongous list. Furthermore, the probability that the mail will go through this time if the account has disabled due to bouncing is presumably way less than 1. So my first-order response is this is a non-problem. Note that you have basically the same problem if the Address's timer expires a few seconds after the send_warnings process finishes. My second-order response is if you still care given that this is rarely going to happen, and even more rarely will it generate a message that reaches the user who reactivates the subscription, you can arrange to have an index on the Addresses (or a separate queue) which has the earliest timer first, and then process the Addresses in that order. You'll still have the same problem if the timer expires a few picoseconds after you start processing the particular address. :-) Basically the way to deal with this is to adjust the `bounce_you_are_disabled_warnings_interval`. If you do implement the queue, another possibility comes up, which is that you process the queue continuously, with a process (a runner, I guess) that sleeps until it's time to process the next send_warning. This would have the advantage that if there were another "DMARC event" that caused large number of bounces, you wouldn't have a flood of warning messages are a particular time of day. > - Also if I am implementing 2 functions `process_bounces` and > `send_warnings` what if both of them attempted at the same > `Address` instance? What about it? This is even more unlikely, and I assume that process_bounces will have a read-write lock that prevents reading (and writing) while it's writing, while send_warnings will have a read lock that prevents writing while it's reading. I think all of the databases we support have such locks. _______________________________________________ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
