bill parducci wrote:
not to be pessimistic (i can't help myself :o), but the other problem i think you are going to run into is multiple [James] MXs servicing a single site. unless they all share a common database the 'state' information may not be available upon receipt of a bounce.Yes, I think it's a well-established practice to use a common database as a store in a distributed system.
the problem with a common database is that it introduces a single point of failure and that is what multi-MX installations are often trying to avoid. 'failover' is an option, but that is an even more difficult nut to crack.Low end databases often lead to a single point of failure. Enterprise grade databases do not have single points of failure, which is why people who such infrastruture requirements pay such big bucks.
the other option that i can think of is distributed state management (local DBs, remote synchronization): very cool but it has a whole set of problems unto itself.Bounces don't need to be processed in real-time... we can't control how long it takes the remote server to handle the response, so if a resource is temporarily unavailable, the message sits in a spool unprocessed.
--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
