[Mailman-Developers] Here's a little issue with the news gatewaying: If the n
Jay R. Ashworth
jra@baylink.com
Fri, 16 Mar 2001 00:38:26 -0500
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