[Mailman-Developers] Mysql MemberAdaptor 1.61 and Mailman 2.1.6

[Adrian Wells]

"Adrian Wells" <adrian at whatifnet.com> on Monday, October 24, 2005 at 1:56
PM +0000 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.000000000 -0400
+++ Bouncer.py  2005-10-25 13:21:02.000000000 -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: falseaddresstest at somedomain.net
bounce score: 1.0
Oct 25 11:06:54 2005 (2687) falseaddresstest at somedomain.net: 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. ;)"
<http://www.mail-archive.com/mailman-developers@python.org/msg06810.html>.
 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.000000000 -0400
+++ MysqlMemberships.py 2005-10-25 13:14:41.000000000 -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