> I know mod_jk will complain if it can't > make a connection or if there is a timeout... I suspect mod_proxy_http > will do the same.
They both are supposed to log 502, while Tomcat will raise a "connection reset by peer" when answering to an already closed connection. Timeouts for both are buggy until, if I remember well, Apache 2.2.17 (see : http://www.spinics.net/lists/apache-users/msg93765.html ), behaving with a timeout 4 times too short. I suppose this was hard-coded for test reasons, and just forgotten. They never replied on this anyway, and please check if you're not running this old bugged Apache. As said by Chris, your server seems quiet, and this means the problem might be out there. Uploading files ? Please check if there is any virus scanner software on the server, this might be an explanation. Have a look on the server if you can find the temporary file which is being uploaded, and what is its size (more than 100 megs ??) When the problem happens again, don't forget to do a 'netstat -an'. There, it will be important to check if there is any SYN_SENT connections, showing a network problem. Another thing more difficult if the problem is related to DNS solving which could be stalled for any reason. You can try some nslookup commands when the problem happens and compare with normal nslookup (what DNS server answered ?) ; you also can install a BIND on your server and make it log everything, this would give you logs for after crash analysis. Or let run a 'tcpdump port 53' and save its capture for later analysis. regards A.T. 2015-10-21 20:58 GMT+02:00 Christopher Schultz <ch...@christopherschultz.net >: > Jamie, > > On 10/21/15 2:37 PM, Jamie Jackson wrote: > > On Wed, Oct 21, 2015 at 1:03 PM, Christopher Schultz wrote: > > > >> Jamie, > >> > >> > >> > >> Your mostly-default <Connector> will default to a maximum of 200 > >> incoming connections with 200 threads to handle them. You are only using > >> 12, so something else must be going on. You have no obvious limits on > >> httpd, so you are probably using the default there as well > >> (coincidentally, also in the 200-connection range). > >> > >> That's a high connection timeout: 93 seconds (why 93?). Note that the > >> connectionTimeout sets the amount of time Tomcat will wait for a client > >> to send the request line (the "GET /foo HTTP/1.1"), not the amount of > >> time the request is allowed to run -- like for an upload, etc. I usually > >> lower this setting from the default of 60 seconds to more like 5 or 10 > >> seconds. Clients shouldn't be waiting a long time between making a > >> connection and sending a request. > >> > >> This timeout also applies to subsequent requests on a keep-alive > >> connection. So if the browser opens a connection and sends 1, 2, 3 > >> requests, Tomcat will hold that thread+connection open for 93 seconds > >> after the last request (assuming the client doesn't terminate the > >> connection, which it might NOT) before allowing other clients to be > >> serviced by that thread. This is a BIO-Connector-only behavior. The > >> NIO/NIO2 and APR connectors don't hold-up the request thread waiting for > >> a follow-up keep-alive request from a client. > >> > > > > Thanks for the info. It seems as if connectionTimeout is almost > universally > > misunderstood to mean something like "request timeout," (which is why it > > had been high--to accommodate things like long responses and file > uploads). > > It seems possible that we could be using up too many threads for too long > > because of the effect of this long timeout on keep-alives. > > While that's true, you should something like 185 threads "in reserve" > and so the server shouldn't grind to a halt and not let anyone else in. > If there are other components in the mix, those could prevent more > connections (e.g. load-balancer, QOS component, etc.) or even if you are > trying to connect from a single web browser with a 4-connection limit, > you'll obviously only be able to upload 4 files at a time. > > But you didn't say anything about that kind of thing, so I assume it's > not the issue. > > > The only time I can think of that a client would be taking any kind of > time > > between connection and sending the request URI line is if someone is > > manually interacting (say, via telnet). I'm going to follow your lead and > > reduce this. > > I wouldn't reduce it past the default of 60 seconds (60000ms) unless you > are observing client-starvation. > > > I doubt that this is the *sole* culprit, but it *is* something for me to > > tweak. > > I would read the whole HTTP-Connector configuration reference -- > especially the "timeout" related items -- and make sure you understand > them all before setting any of them. The defaults are reasonable, but > every environment has its own special set of requirements. > > I don't think the timeouts are the issue. What else can you tell us > about the behavior of the server when it "crashes"? I don't think you > have really described the actual problem, yet. > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
