On 2012-10-05 at 15:17 -0400, Phil Pennock wrote:
> If your volumes are such that you _need_ multiple mails in one
> connection for the majority of mails, then things are more complicated.
Matthew Newton's answer is good and handles most cases; there's a corner
case of a message deferred before the pause is put in place (temporary
glitch on remote server) which should be fairly rare; if that happens, a
mail can still trickle out to the older server. A minute of delay to
let the volume of the rest of the mail take the message down the old
connection, before the old mailbox is frozen/exported/whatever, should
deal with that scenario.
If the old server _dies_ for a period of time, you can do something like
nuke the wait-<old-server-transport> DB to force re-routing, right at
the time you bring the server back up.
For this, you might want to have two identical transports, with
different names, used for the old and the new routers, so that you can
independently nuke them. That might be overkill.
-Phil
