Hmm, I'll try the Google route. I'll also may may have to try a packet
trace on both the cllent and server just to see if I can figure out what is
happening. (Most likely not related... but I also found that active FTP
won't work with the DSL modem/router, but does work with cable. So there
are definite differences)
But strictly from a JAMES point of view, I know I get a Connection Reset
exception in the log, yet the message is still sent. On the client
(Thunderbird), It says "contacting host..." then it changes to "Delivering
message...". But then it hangs for about a minute, and then finally times
out and says it can't talk to smtp server (I know that's not correct... but
Tbird obviously didn't get the final ack it was expecting). The JAMES
exception occurs apparently as a result of TBird finally timing out and
aborting. But the end result is that TBird (also tried on on Outlook...
same results) thinks the message was NOT sent, but JAMES did deiliver it.
Then the client retries (that's where the multiple sends occur).
So it appears that the message is received by the smtp server and forwarded
to the spooler before the socket connection is wrapped up since the
connection reset exception gets logged each time. Here is a representative
log:
03/08/07 10:59:51 DEBUG smtpserver: Sent: 220 mail.jwmhosting.com SMTP
Server (JAMES SMTP Server 2.3.0) ready Fri, 3 Aug 2007 10:59:51 -0500 (CDT)
03/08/07 10:59:51 DEBUG smtpserver: Calling start()
03/08/07 10:59:51 DEBUG smtpserver: Watchdog default Worker #12 has time to
sleep 359953
03/08/07 10:59:52 ERROR smtpserver: Socket to
adsl-87-102-37-171.karoo.KCOM.COM (87.102.37.171) closed remotely.
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at
org.apache.james.util.CRLFTerminatedReader.read(CRLFTerminatedReader.java:151)
at
org.apache.james.util.CRLFTerminatedReader.readLine(CRLFTerminatedReader.java:111)
at
org.apache.james.smtpserver.SMTPHandler.readCommandLine(SMTPHandler.java:749)
at
org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:370)
at
org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run(ServerConnection.java:422)
at
org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55)
at
org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116)
I'm a software architect and have debug skills. I'm not implying that there
is any problem at all with JAMES. I'm just trying to figure out what could
be happening on the wire that would cause this exception to occur.
In the SMTP protocol, is it possible that the final ACK back to the client
could be getting lost, and Tbird is timing out and closing the connection?
Would that cause this exception?
Thanks.
From: Stefano Bagnara <[EMAIL PROTECTED]>
Reply-To: "James Users List" <[email protected]>
To: James Users List <[email protected]>
Subject: Re: Tuning JAMES & MySQL
Date: Fri, 03 Aug 2007 19:06:23 +0200
randy roy ha scritto:
> Stephan,
>
> Thanks for the info. I was able to get rid of the connection pool
> problem. But there was a situation that made me get into this to begin
> with that unfortunately is still there after all the performance tuning
> stuff.
>
> I changed my provider from cable to DSL, and I'm getting failures on
> send. In the SMTP log I get SocketException: Connection Reset messages.
>
> This is intermittent. Sometimes it sends fine. But then it will get on
> a kick and fail for an hour or so, then start working again.
Sorry, no advice here. TCP/IP should works the same and should be
transport agnostic.
There should be no way to see difference between a cable and a DSL from
the TCP/IP protocols.
Maybe your new provider runs packet inspection hardware (this is a
privacy violation and a known source of all kinds of problems, IMO).
Maybe you should run some google search using your new provider name and
problems: you should find someone complaining for this even if they are
not using JAMES Server.
> The worst part about it is that even though a failure is returned, the
> email actually does get sent. So the email client continues to try to
> send it resulting in a bunch of copies sent.
SMTP protocol guarantee delivery of at least one copy of each sent
message. Sending multiple time the same mail is a known corner case
problem of SMTP protocol and while it can be minimized it cannot be
avoided at all.
In your case I guess there are bad network problems.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Tease your brain--play Clink! Win cool prizes!
http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
