Aaryan Bhagat writes:
Stephen writes:
My second-order response is if you still care [...], 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.
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.
That is what I would recommend, too. For future reference:
I basically did not realize the type of organizations using
Mailman(especially if they havevery large sizeMailing List or not so I presumed this problem's existence).
For Mailman 2, there are a number of organizations with lists with 100,000 members, and I think there were one or two claiming a million or more. There are also organizations with tens of thousands of lists, although I don't know what the average number of members is. I don't know of any 100,000+ scale lists using Mailman 3, but I know that there are organizations with large numbers of lists that are converting to Mailman 3.
For the particular issue regarding how long it takes to process disabled warnings for one large list, you can get a lower bound on the time by creating a few large lists (10,000, 20,000, 50,000, and 100,000 subscribers seem like a good selection) and see how long it takes to go through the whole list when *none* are disabled, and do the same with small lists (100, 200, 500, 1000) where *all* are disabled, forwarding the warnings to a local /dev/null address, presuming that as far as the simultaneity problem goes Mailman doesn't care how long the MTA takes to get the messages out, it only cares about how fast the MTA can absorb and queue them. I imagine an MTA with a full queue might be somewhat slower than one with an empty queue, but it shouldn't be very much.
I'm not suggesting that you implement this this summer, although if you have extra time for additional work, it's one idea.
I suggest we can actually see the feedback of customers regarding problems arising in this area
Unfortunately, this kind of feedback is likely to be very rare because neither the subscriber nor the admin is likely to notice that a "you are disabled" warning has been delayed by a day or even a couple of weeks. A very few will, but remember this situation is unlikely to manifest in the first place.
Stephen writes:
What about it? [...] I think all of the databases we support have [the needed] locks.
I do not understand this part,
send_warningshas to increment thebounce_you_are_disabled_warningsof theAddressand theprocess_bouncewill have to set theprocessedattribute ofBounceEventafter 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.
I don't understand why there's any problem here. In what scenario is the database corrupted relative to what is desired? What variables are set differently from desired, and how? What are the user consequences of the incorrect database?
Steve