"Adrian Wells" <[EMAIL PROTECTED]> 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: [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. ;)" <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 _______________________________________________ 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