"Adrian Wells" <[EMAIL PROTECTED]> on Monday, October 24, 2005 at 1:56
PM + wrote:
>I am not proficient in Python and don't completely understand how Mailman
>operates so I'm interested in finding some help to understand how
>information generated by registerBounce in Bouncer.py is supposed to reach
>setBounceInfo in MysqlMemberships.py. Even a general understanding of how
>bounce information is processed in Mailman would be helpful for
>investigating this.
After some time and further testing... it seems that the Mysql
MemberAdaptor maybe OK after all, but it is not being fully utilized (or
any other member adaptor, for that matter)...
The function registerBounce only calls setBounceInfo once (line 116:
"self.setBounceInfo(member, info)"). This occurs after testing whether
"this is the first bounce we've seen from this member". It would seem as
though setBounceInfo should be called a few more times if other conditions
are met, right? For example, after determining that the bounce
information for a member is valid and is not stale?
As a result, I've created a patch that seems to correct the unexpected
behavior mentioned in my earlier message. This patch may not cover
recording when probes occur or how many probes remain (for example in
sendNextNotification).
--- Bouncer.py.10.25.2005 2005-10-25 12:21:57.0 -0400
+++ Bouncer.py 2005-10-25 13:21:02.0 -0400
@@ -137,6 +137,7 @@
if lastbounce + self.bounce_info_stale_after < now:
# Information is stale, so simply reset it
info.reset(weight, day,
self.bounce_you_are_disabled_warnings)
+self.setBounceInfo(member, info)
syslog('bounce', '%s: %s has stale bounce info,
resetting',
self.internal_name(), member)
else:
@@ -144,6 +145,7 @@
# score and take any necessary action.
info.score += weight
info.date = day
+self.setBounceInfo(member, info)
syslog('bounce', '%s: %s current bounce score: %s',
member, self.internal_name(), info.score)
# Continue to the check phase below
Please let me know if this is not good or will otherwise cause problems
down the line.
As a minor side note, I noticed the bounce log receives two different
formatted messages for the first bounce and subsequent bounces. An
example:
...
Oct 25 10:50:51 2005 (2687) samplelist: [EMAIL PROTECTED]
bounce score: 1.0
Oct 25 11:06:54 2005 (2687) [EMAIL PROTECTED]: samplelist
current bounce score: 2.0
...
This is not a major issue but it is inconsistent and it not clear why it
should be this way. Is there reason is should be different?
Finally, the Mysql MemberAdaptor has a __del__() method. However, it
doesn't seem like this is utilized. Searching the Mailman developer's
mailing list archives yielded comments from Barry stating that such a
method is "not a reliable way to free
external resources because you really don't know when Python will call it
it, but in this case it might work okay (and may be the only option
without some hacking. ;)"
.
I'm curious, what kind of hacking would be required to reliably close
connections?
For the sake of full disclosure, I did make a minor change to the
MysqlMemberships.py but this should not have affected the issue concerning
storing subsequent bounce information. Here is a patch containing for the
change made in the adaptor:
--- MysqlMemberships.py.10.25.2005 2005-10-25 12:31:02.0 -0400
+++ MysqlMemberships.py 2005-10-25 13:14:41.0 -0400
@@ -969,8 +969,8 @@
except MySQLdb.Warning, e:
syslog("error", "MySQL update warning setting
Delivery Status info to '%s' for member '%s' in setBounceInfo()" %
(status, member) )
else:
-self._prodServerConnection
try:
+self._prodServerConnection
# Hack the dates to work with MySQL.
lnsql=(info.lastnotice[0],info.lastnotice[1],info.lastnotice[2],0,0,0,0,0,0)
lnsql = time.strftime("%Y-%m-%d", lnsql)
-Adrian
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
