Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <49DC6437.8020103@ice-sa.com>
Date: Wed, 08 Apr 2009 10:45:43 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: aw@ice-sa.com
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: apache/tomcat communication issues (502 response)
References: <a8bb65fb0904072323u50095eaaq96c35313019ec878@mail.gmail.com>
In-Reply-To: <a8bb65fb0904072323u50095eaaq96c35313019ec878@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

feedly team wrote:
[...]
> using netstat, i see a moderate number (~80) of tomcat's sockets in
> the CLOSE_WAIT state, not sure if this is relevant.
> 
Approximately, because I am not sure I have this really understood yet : 
a TCP CLOSE_WAIT state happens when the writing side of a TCP connection 
has finished writing and (nicely) closes its side of the socket to 
indicate the fact, but the reading side of the connection does not read 
what is left in the buffers, so there is still some data unread in the 
pipeline, and the reading side never closes the socket.
And now I'm stuck in my explanation, because I am not sure which side is 
seeing the CLOSE_WAIT... ;-)
But anyway, it indicates a problem somewhere in one of the two 
applications, my guess being the reading one.
It should do more reads to exhaust the remaining data, get an 
end-of-stream, then close its side of the connection, but it never does.
There is apparently no timeout for that, so the OS can never get rid of 
that socket, which probably leaves a bunch of things hanging around and 
consuming resources that they shouldn't.
On one of our systems, I have occasionally seen this issue grow until 
the point where the system seemed unable to accept new connections.
Now whether that has any bearing on your particular issue, I don't know. 
  But it sure indicates a logical problem somewhere.

There is quite a bit on the subject on Google, of unequal quality.
If someone knows a more rigorous explanation, please go ahead.

I will still add a purely sibjective and personal note : from personal 
experience, this phenomenon seems to happens more frequently whith Java 
applications than with others, so I would guess that there might be 
something in the Java handling of sockets that makes it a bit harder to 
write correct socket-handling code.
A Java expert may want to comment on that too.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org