Bill, Serge, >> Yes, I think it's a well-established practice to use a common database >> as a store in a distributed system.
>provided that the database can handle the volume. since mail is well >suited to load balancing across many, simple systems it is easy to >envision an implementation whereby you do not have the horsepower in a >db to keep up with the mail volume; a common problem making DBs the >achilles heel of most high throughput systems. Just to clarify the situation: our setup is very simple. James just forwards mail to our corporate mail-infrastructure, something that we can assume is always available. The bounces that we process are not 'immediate' in the sense that any bounce we receive is always from another MTA than our James server. Our custom mailets parse the mailId that is present in both the From: and Reply-To: fields to update the status of a mail in our backend database. Performance is not an issue, given the current hardware setup and traffic volumes. Maintaining state is handled by the database that keeps track of the mail status. -- Jeroen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
