On Fri, Mar 16, 2001 at 12:21:34AM -0500, Barry A. Warsaw wrote:
"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
Figured.
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?
Nope. I'll check, but while I can *get into8 the list using the site password, *using it as the old password to set a new one* is rejected. *Using the list password* as the old one, however, appears to work.
But no, I meant...
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.
SMTPDirect is called from underneath qrunnner?
<voice tone="small"> Oh. </voice>
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.
Indeed. At what level would it be best to try and fix this? It's actually only one part of "braodcast list handling", but it's probably the most important.
[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.]
Well, yeah, but the try is only 4 lines long, fercrissake... ;-)
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.
Yeah, but *that* required that I understand all kinds of theory of operation that I, well, don't. :-) And it's inelegant, anyway.
Is this the exposing of an architectural deficiency in this part of the system? :-)
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.
Noted. I'll try to figure out what other requirements using it this way engenders, and make it one big request.
Is there at least a call-tree somewhere? Or, alternatively, some code I can run against the system, specifying entry points, to create one?
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015