[Mailman-Developers] big list

[Barry A. Warsaw]

>>>>> "BAW" == Barry A Warsaw <barry@zope.com> 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