On 29.09.2011 22:49, rapponcape wrote: >> Aha, the client is using HTTP 1.0 and not 1.1. This could be one reason >> for Tomcat closing the connection. See below. >> > > When I reconfigure and put Apache in front of Tomcat and use a jkmount with > AJP connector, response is normal and without error. Appears to only happen > when tomcat is standalone.
Could be the answer is small enough, that Apache can buffer it and send without chunked encoding. Don't know. >>> You see: no Content-Length header. I > > I do see Content-Length in the POST header You cut out the relevant part. I was talkingabout the Tomcat answer, you saw it in the client request. That's now the same ;) Rainer > On Thu, Sep 29, 2011 at 1:49 PM, Rainer Jung <rainer.j...@kippdata.de> wrote: >> 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
