"JRA" == Jay R Ashworth <jra@baylink.com> writes:
JRA> I shouldn't think so... and it's not like this list has been
JRA> swamped with traffic... I *still* haven't gotten an answer to
JRA> *my* first question, asked last Friday... :-}Right at the tail end of IPC9, so that's not too surprising. Do you mean
JRA> The doco says the site password will work anywhere... but it
JRA> doesn't seem to work as the "old password" for changing a
JRA> list password, and I can't find anywhere *else* to do that
JRA> either. Am I missing something, or is that really a bug?
JRA> I'm gonna check Jitterbug for that, too, during my search.I definitely can't reproduce this in 2.0.3 or 2.1. Works for me. Are you sure you've got the crypt module installed in your Python executable?
Or was it
[w.r.t. max chunks per day hack]
JRA> Will this approach cause locking problems, etc?It worries me because you're basically freezing all mail delivery on all lists for some fraction of an entire day. So while people will still be able to hit the cgi for this list (since the list is unlocked), no mail will flow through the system at all while you're in that sleep(). Note that while SMTPDirect for the actual mail delivery task can be configured to run multiple threads, qrunner itself is single threaded, and the message pipeline will block at SMTPDirect until it's done with its work.
Your qrunner lock could be broken during that time. Qrunner's lock by default is 10 hours, so say you only deliver one chunk per day. 10 hours from now cron will start another qrunner, the lock will get broken, and now you've got two qrunners stomping on each others toes. Badness.
[Aside: your bare "except:" isn't good Pythonic form. You should adorn that except with the most specific exception you expect to get. In this case AttributeError. Bare excepts should be reserved for the (very) rare case of framework wrappers, a la scripts/driver.]
A slightly different approach to take would be, if you exceed your max chunks per day threshold, break out of the deliver() function, setting the refused dictionary to contain all the recipients in chunks that are deferred. Set the error code to something in the 400 range (to indicate a temporary failure), and this will cause a SomeRecipientsFailed exception to be signaled to the delivery pipeline.
Then you should add a timestamp to the msgdata for when you processed this chunk and at the top of SMTPDirect.process(), simply return if the timestamp is less than your delay period.
Without testing it, that approach (or something like it) ought to work better.
I'd also suggest adding this as a feature request to the SourceForge feature request tracker, so it doesn't get lost.
Cheers, -Barry