On 29.09.2011 18:28, rapponcape wrote: > Tomcat version 7.0.6 listening on local machine 10.3.4.7 and accepting > incoming POST connections from 4 remote machines, 10.12.5.10[2-5]. > Configured in standalone mode, using HTTP connector.
7.0.6 was not ment for production use. Start with the latest 7.0 release. > Remote machines are sending constant stream of POST messages...~100 kbit/sec. > > All POST traffic is accepted and acknowledged, but, RESET packets > cause remotes machines to re-establish new connections, causing errors > on sender's side and slowing down rate of transfer. > > Traffic headers show local machine is sending "Connection: close" on > post acknowledgement messages. Despite fact that remote machines' > POST messages contain "Connection: Keep-Alive" header. > > ====================== > post traffic header ... > ====================== > > POST /myapp HTTP/1.0 Aha, the client is using HTTP 1.0 and not 1.1. This could be one reason for Tomcat closing the connection. See below. > HOST: 10.3.4.7:8080 > Connection: Keep-Alive > Authorization: Basic Y2VybmVyOnlpbiZ5YW5n > Content-type: multipart/form-data; boundary=----------1803119234 > Content-Length: 59970 > > ------------1803119234 > Content-Disposition: form-data; name="xml" > <?xml version="1.0" encoding="ISO- > --------------------------------------------------------------------------------------------------------------------------------------- > > ====================== > response header ... > ====================== > > ------------1803119234-- > > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > Date: Fri, 23 Sep 2011 18:27:25 GMT > Connection: close You see: no Content-Length header. It's likely dynamic content, so it is streamed, the length of the content is not known in advance. This means Tomcat has either to use chunked encoding, which needs a HTTP/1.1 client, or it must simply close the connection at the end of the transfer, which it does. > ====================== > >> # netstat -anp | grep 8080 > > tcp 0 0 :::8081 :::* > LISTEN 23107/java > tcp 0 0 ::ffff:10.3.4.7:8080 ::ffff:10.12.5.103:39809 > FIN_WAIT2 - > tcp 0 0 ::ffff:10.3.4.7:8080 ::ffff:10.12.5.104:33033 > FIN_WAIT2 - > tcp 0 0 ::ffff:10.3.4.7:8080 ::ffff:10.12.5.102:57077 > FIN_WAIT2 - > tcp 0 0 ::ffff:10.3.4.7:8080 ::ffff:10.12.5.105:39624 > FIN_WAIT2 - > > I've tried various connector configurations and protocols; HTTP, NIO, > connectionTimeout, etc. > > Here's what my connector config looks like currently: > > <Connector port=8080 protocol="org.apache.coyote.http11.Http11Protocol" > connectionTimeout="30000" > connectionLinger="100" > keepAliveTimeout="3000" > maxKeepAliveRequests="2000" > disableUploadTimeout="true" > maxThreads="500" > minSpareThreads="150" > maxSpareThreads="300" > acceptCount="200" > socket.soKeepAlive="yes" > enableLookups="false" /> > > =========================================== > > Why fin_wait2 state? I would expect to see ESTABLISHED connections > and and Keep-Alive in response header. > > Why are RESET packets being sent back to remote machines? Because Tomcat said "Connection: close", which means the client is not allowed to reuse the connection and Tomcat closes its side. Likely the client is nevertheless trying to reuse the connection, which will be answered by RST by the OS. Since your client doesn't send the FIN package, the state is FIN_WAIT2. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
