Stephen Writes:
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.
I understand your point.
Stephen writes:
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.
This looks fine as of now but I do not know exactly how long or how it will implement, also creating a new runner is also very resource-consuming so I think I will be stick to straightforward implementation as of now. I basically did not realize the type of organizations using Mailman ( especially if they have very large size Mailing List or not so I presumed this problem's existence ). I suggest we can actually see the feedback of customers regarding problems arising in this area and depending upon that we can choose to modify/not-modify this. If we choose to modify it, maybe we can integrate it some of next year's GSoC project.
Stephen writes:
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.
I do not understand this part, send_warnings has to increment the bounce_you_are_disabled_warnings of the Address and the process_bounce will have to set the processed attribute of BounceEvent after completely processing that entry to True and save it again. Both of them have to write after reading a single entry so I do understand the reason of the lock.