John, I also had this problem several months back. I turned on debug level tracing just to see what was happening.
Here is a snippit from the log.... notice that there is a 10-minute gap between each entry.... 770: 16/06/06 15:20:48 INFO James.Mailet: RemoteDelivery: Attempting delivery of Mail1150406666744-21082-to-mail.com to host mail-com.mr.outblaze.com. at 208.36.123.68 to [EMAIL PROTECTED] 834: 16/06/06 15:30:49 INFO James.Mailet: RemoteDelivery: Attempting delivery of Mail1150406666744-21082-to-mail.com to host mail-com.mr.outblaze.com. at 64.71.166.194 to [EMAIL PROTECTED] 877: 16/06/06 15:40:50 INFO James.Mailet: RemoteDelivery: Attempting delivery of Mail1150406666744-21082-to-mail.com to host mail-com.mr.outblaze.com. at 64.71.166.196 to [EMAIL PROTECTED] James will wait 10 minutes before timing out with a server. Then it goes to the next MX server for the domain and waits another 10 minutes... For a domain with a bunch of MX records defined, James could lock up an outbound thread for over an hour trying to send one stupid email out. I hadn't noticed until then that I was configured with the default thread count of 1... which meant James was waiting doing nothing for hours trying to send a few emails to this server and a couple of other servers that were down. Other outbounds were backing up in the queue while we sat around for 10 minutes per email per MX server waiting for outblaze.com to timeout. I bumped the thread count to 10 and things cleared out (eventually...). I think your thread count of 4 is still pretty low and risky. All it takes is several notes going to the same 'down' server to completely lock up the system waiting for timeouts (I personally think 10 minute timeouts are WAY too long... but that's a diff issue). Theoretically, the potential is there for all threads to lock up at one time no matter how many threads you have. But the more threads you have, the less likely they'll all end up locked out on one particular target server. There is a pretty lengthy thread on this topic around the 16-20 June '06 timeframe related to the problem I was encountering. Jerry -----Original Message----- From: John Rose [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 1:06 PM To: server-user@james.apache.org Subject: mail backed up in spool folder I'm a newbie regarding James 2.2. We are running an Apache Tomcat application that uses James 2.2 as it's email service. This is running on a Windows 2003 server. There are several thousand outgoing email backed up in the \james\apps\james\var\mail\spool folder and I can't seem to clear them. I have restarted the James service twice and the backed up email keeps growing. I've got 4 delivery threads configured. Please let me know if there is anything I can do to resolve this backlog. Also let me know if there is more information that I can provide to help assist in the matter. Thank you. John Rose Support FoundationIP Tel: +1 612-332-8800 X 1017 Fax: +1612-332-0080 [EMAIL PROTECTED] **************************************************************************** **** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee; access to this email by anyone else is unauthorized. If you are not the intended recipient: (1) you are kindly requested to return a copy of this message to the sender indicating that you have received it in error, and to destroy the received copy; and (2) any disclosure or distribution of this message, as well as any action taken or omitted to be taken in reliance on its content, is prohibited and may be unlawful. **************************************************************************** **** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
