aboutsummaryrefslogtreecommitdiffstats
path: root/messages/hu/UPGRADING.hu
diff options
context:
space:
mode:
authormsapiro <>2006-07-22 01:53:41 +0000
committermsapiro <>2006-07-22 01:53:41 +0000
commitb89f016fd9e853ebd7d1f03fd62327cc2be83f76 (patch)
tree19029eb178b95db3af2dca5f155f2a0e2f72a0ae /messages/hu/UPGRADING.hu
parentc837367f2365d261d00dda2215804da481f8facc (diff)
downloadmailman2-b89f016fd9e853ebd7d1f03fd62327cc2be83f76.tar.gz
mailman2-b89f016fd9e853ebd7d1f03fd62327cc2be83f76.tar.xz
mailman2-b89f016fd9e853ebd7d1f03fd62327cc2be83f76.zip
- bin/unshunt
- Queue/Runner.py - Queue/Switchboard.py Backported the gfiles backup changes from the trunk. The following comments are from the trunk checkin. Note that the test cases are not added. Added robustness to Switchboards and Runners so that if a runner crashes uncleanly (e.g. segfaults the Python interpreter), messages being processed will not be lost. The vulnerability, ideas, and patches are credited to Richard Barrett and Mark Sapiro. Their original work was modified by Barry for this commit and any bugs are his fault. The basic idea is that instead of unlinking a .pck file in dequeue(), the file is renamed to a .bak file. The Switchboard grows a finish() method which then unlinks the .bak file. That class's constructor also grows a 'restore' argument (defaulting to false), which when true moves all .bak files it finds in its hash space to .pck, thereby restoring a file lost while "in flight". This relies on the fact that even with multiple qrunners, exactly one process will be responsible for one hash space slice, so it's never possible (under normal operation) for a .bak file to be renamed to .pck by some other process. Test cases for both the new Switchboard behavior and the use of that by Runner subclasses has been added. There are two things to watch out for, either of which may require some additional changes. There is some small potential to duplicate messages in various queues, if say 'mailmanctl' were improperly started more than once by a site admin. This usually won't happen unless an admin is overly eager with the mailmanctl -s switch, so we can chalk this one up to operator error. I'm not sure what more we can do about that. There's also a possibility that if we're processing a message that continually causes the Python interpreter to crash, we could end up duplicating messages endlessly. This is especially troublesome for the Outgoing runner which could conceivably cause a mail flood. I consider this the more critical issue to defend against, probably by adding a numbering scheme to the .bak file names and refusing to restore a .bak file more than say 3 times without human intervention.
Diffstat (limited to 'messages/hu/UPGRADING.hu')
0 files changed, 0 insertions, 0 deletions