U-WROTE:
if (!errors.isEmpty()) {
getMailetContext().sendMail(mail.getSender(),
errors, mail.getMessage(),Mail.ERROR);
}
So in the event of an exception from the JDBC layer, we SHOULD be logging
the exception and posting the mail to the error processor, so you should
find the e-mails in your error repository. Of course, if the spooler is
also using JDBC, then we can't do that (but nor would we be able to receive
new e-mails), nor can we store it in the error repository if THAT store uses
JDBC.
I-WRITE:
hmmmm..... i would have thought that an error message of NO RECIPIENT (or
something like that)
would be sent to the sender... the idea is that i would not want to accept the
message if i cannot process it.
the way it seems is that James will accept everything and then process it
later - IF CONFIGURED PROPERLY\, otherwise the accepted mail is lost.
U-WROTE:
By the way, must you use MSSQL? I hear nothing (absolutely nothing) good
about the JDBC drivers for MSSQL. I can tell you that in my own testing
with MySQL, I have pumped millions of messages. My last stress test ran 40
hours and roughly 4 million messages. Success breeds trust.
I-WRITE:
um, well, no, not really. M$SQL is already on the box and used. unfortunately, i
have had the reverse experience with MySQL where it was(is) not stable at all
running in a WinTel environment... but that too can be INCORRECTLY CONFIGURED..
alan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
