>>>>> "BAW" == Barry A Warsaw <[EMAIL PROTECTED]> writes:
BAW> Think of shunt as a safety net. If Mailman has a bug that
BAW> causes an uncaught exception to occur while handling the
BAW> message, it gets shuffled off to shunt, so that once the bug
BAW> is fixed, you ought to be able to move the message back to
BAW> qfiles/in and have it delivered again.
BAW> I may do two additional things with shunt: first, I should
BAW> probably include a key in the metadata to indicate which
BAW> queue the shunted file came from, and second, I want to add a
BAW> bin/unshunt command which will re-queue shunted messages
BAW> safely and correctly.
This is now done.
BAW> As to your other problem, I'm going to have to think about
BAW> that. I agree that it's not good that if Mailman is shut
BAW> down that messages are delivered either twice or not at all.
BAW> A solution will likely require some disk i/o, but the
BAW> question is, how to do things robustly without hammering the
BAW> disk.
This should be solved too. First, Mailman already attempts to cleanly
shut down the qrunner loops on receipt of SIGHUP or SIGTERM. Second,
should an error occur, the message's metadata dictionary (i.e. its .db
file) will containe a list of as-yet-undelivered recipients. So upon
restart or unshunting, it should continue where it's left off. To
reduce the impact on the disk, it will only maintain undelivered
addresses per `chunk', which can be SMTP_MAX_RCPTS, or per-address if
VERPing. I think this is a fine tradeoff (some small number of folks
/might/ get duplicates, but no one should miss a message).
-Barry
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
