Thanks for your reply.  Followup....

>
> 7.0.6 was not ment for production use. Start with the latest 7.0 release.
>

Will attempt to test with latest stable 7.0.21

>
> 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.

>> You see: no Content-Length header. I

I do see Content-Length in the POST header


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.
>
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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

Reply via email to