Re: [Mailman-Developers] VERP_DELIVERY_INTERVAL not yet functional ?
if mm_cfg.VERP_DELIVERY_INTERVAL > 0: if mm_cfg.VERP_DELIVERY_INTERVAL == 1: # VERP every time msgdata['verp'] = 1 elif not int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL: msgdata['verp'] = 1 Other than possible precedence problems in that elif condition, which casual testing seems to disallow (but I'd parenthesize anyway), it seems to me that setting 3 should cause every 3rd message to be VERPed. But in my testing it does not, and adding parentheses fixes it. I'm too lazy to research further, as I believe the parens should be there every time there's potential confusion. Index: OutgoingRunner.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Queue/OutgoingRunner.py,v retrieving revision 2.7 diff -u -r2.7 OutgoingRunner.py --- OutgoingRunner.py 2001/12/27 07:08:00 2.7 +++ OutgoingRunner.py 2002/02/05 23:36:20 @@ -49,7 +49,7 @@ if mm_cfg.VERP_DELIVERY_INTERVAL == 1: # VERP every time msgdata['verp'] = 1 - elif not int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL: + elif not (int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL): msgdata['verp'] = 1 # Fortunately, we do not need the list lock to do deliveries. handler = mm_cfg.DELIVERY_MODULE
what should one set in order to have VERP but not always? If I set VERP_DELIVERY_INTERVAL=3 it never verps. If I set VERP_DELIVERY_INTERVAL=1 it always verps.
Does it apply only to lists not yet created? Did I forget to set one variable?
(I'm using today's CVS version. I had the same trouble a while ago. Personalization and other verp features work correctly.)
-- Fil
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers
@ Dan Mick <dmick@utopia.West.Sun.COM> :
Index: OutgoingRunner.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Queue/OutgoingRunner.py,v retrieving revision 2.7 diff -u -r2.7 OutgoingRunner.py --- OutgoingRunner.py 2001/12/27 07:08:00 2.7 +++ OutgoingRunner.py 2002/02/05 23:36:20 @@ -49,7 +49,7 @@ if mm_cfg.VERP_DELIVERY_INTERVAL == 1: # VERP every time msgdata['verp'] = 1 - elif not int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL: + elif not (int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL): msgdata['verp'] = 1 # Fortunately, we do not need the list lock to do deliveries. handler = mm_cfg.DELIVERY_MODULE
Dan, I have used your patched version for a while, and the result is still very random. Some lists don't ever VERP, some others do. I can't find a reason. How are mlist.post_id modified ? -- Fil
Fil wrote:
@ Dan Mick <dmick@utopia.West.Sun.COM> :
Index: OutgoingRunner.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Queue/OutgoingRunner.py,v retrieving revision 2.7 diff -u -r2.7 OutgoingRunner.py --- OutgoingRunner.py 2001/12/27 07:08:00 2.7 +++ OutgoingRunner.py 2002/02/05 23:36:20 @@ -49,7 +49,7 @@ if mm_cfg.VERP_DELIVERY_INTERVAL == 1: # VERP every time msgdata['verp'] = 1 - elif not int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL: + elif not (int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL): msgdata['verp'] = 1 # Fortunately, we do not need the list lock to do deliveries. handler = mm_cfg.DELIVERY_MODULE
Dan, I have used your patched version for a while, and the result is still very random. Some lists don't ever VERP, some others do. I can't find a reason. How are mlist.post_id modified ?
Well, as I said, I don't use this; I've hacked things so that every message is VERPed by Postfix. So I'm not much of a testbed. post_id is incremented for each post, by Handlers/AfterDelivery.py.
"F" == Fil <fil@rezo.net> writes:
F> Dan, I have used your patched version for a while, and the
F> result is still very random. Some lists don't ever VERP, some
F> others do. I can't find a reason. How are mlist.post_id
F> modified ?I figured out the problem and have a mostly working patch. There's a deeper issue involved that I want to fix before I check everything in. Watch for it later tonight (my time <wink) or tomorrow.
If you're interested: Because OutgoingRunner.py doesn't need a list lock to do its work, it loads the MailList state once the first time it needs that list. It never reloads it, so it never sees the post_id get incremented.
The quick fix is to move the occasional VERP calculation into ToOutgoing.py, which is part of the munge-and-moderate pipeline, and thus will always have the up-to-date list data.
A related, longer term fix is to make sure that OutgoingRunner occasionally reloads the list data, but that's a bit tricky because we can't count on reference counting (maybe we could use Python2.1's weakrefs?) and we don't yet have an API to invalidate the MailList's state.
-Barry
@ Barry A. Warsaw <barry@zope.com> :
I figured out the problem and have a mostly working patch. There's a deeper issue involved that I want to fix before I check everything in. Watch for it later tonight (my time <wink) or tomorrow.
If you're interested: Because OutgoingRunner.py doesn't need a list lock to do its work, it loads the MailList state once the first time it needs that list. It never reloads it, so it never sees the post_id get incremented.
The quick fix is to move the occasional VERP calculation into ToOutgoing.py, which is part of the munge-and-moderate pipeline, and thus will always have the up-to-date list data.
A related, longer term fix is to make sure that OutgoingRunner occasionally reloads the list data, but that's a bit tricky because we can't count on reference counting (maybe we could use Python2.1's weakrefs?) and we don't yet have an API to invalidate the MailList's state.
Is that really necessary? If it imposes some overhead, you could use .... not (int(random() * mm_cfg.VERP_DELIVERY_INTERVAL)): ...
-- Fil
"fil" == fil <fil@rezo.net> writes:
>> The quick fix is to move the occasional VERP calculation into
>> ToOutgoing.py, which is part of the munge-and-moderate
>> pipeline, and thus will always have the up-to-date list data.
fil> Is that really necessary? If it imposes some overhead, you
fil> could use .... not (int(random() *
fil> mm_cfg.VERP_DELIVERY_INTERVAL)): ...That's an interesting idea, but moving the calculation to ToOutgoing.py lets us do it a little more deterministically, with no extra cost.
>> A related, longer term fix is to make sure that OutgoingRunner
>> occasionally reloads the list data, but that's a bit tricky
>> because we can't count on reference counting (maybe we could
>> use Python2.1's weakrefs?) and we don't yet have an API to
>> invalidate the MailList's state.I should mention that this change is really a "makes me feel better about it" kind of change. MM2.1 functionality shouldn't depend on this, but someday, something will and it's better to fix it now than to muddle over it all over again a year or so from now. :) If it's really a performance killer (and I think that it won't be bad given my currently implementation), then we can remove it fairly easily.
-Barry
participants (3)
-
barry＠zope.com -
Dan Mick -
Fil