On 17.04.2009 01:30, Anthony J. Biacco wrote: >> On 16.04.2009 01:49, Anthony J. Biacco wrote: >>> worker.template.socket_timeout=10 >> I'm not very much in favor of the socket_timeout, but well, if you >> think >> you need it. Just for the sake of completeness, please check, whether >> having no socket_timeout changes anything about your problem. >> > > Confirmed same errors with socket_timeout commented out
Good to know. >> (*) We failed to read the Cpoong response. Note that we are still in >> the >> same second, so the wait time did not expire. We must have had some >> other failure. >> >> My expectation: Tomcat closed the connection due to connectionTimeout. >> mod_jk didn't check the connection_pool_timeout for this connection, >> because our pool is already small enough (13 conns). >> >> Try setting connection_pool_minsize to "0" and check, whether the >> observation goes away. Even with minsize "0", it can happen rarely, >> because Tomcat closes the connection at the moment the >> connectionTimeout >> is reached, whereas mod_jk needs to run the internal maintenance (once >> a >> minute) to check the idle connection timeouts. >> > > With connection_pool_minsize=0 I can confirm the different event from > mod_jk after the tomcat connectionTimeout. All of the log lines were debug then. So with normal log level setting info, you won't get any disturbing log output. >> *But*: I don't fully understand, why the problem goes away by > switching >> to a ping timeout of 25000 milliseconds. Maybe the 10 second >> socket_timeout hides the thing in this case [wild guess]. There is > also >> a relation between the ping_timeout and which connections do get >> checked >> during maintenance (the connection_ping_interval). So a longer >> ping_timeout reduces also the frequency of ping checks, so it should >> also reduce the frequency of the info messages. Not sure whether the >> combination of all results in not getting them any longer. >> > > If I increase the ping timeout to 20000 the maintaining worker process > still executes 2 minutes (almost to the second) after the tomcat request > finished. No error. The 3rd minute's process, same. It isn't until 4 > minutes after the tomcat request finished that I get the cpong error. > If I set connection_ping_interval to something like 10 (with a 10000 > ping_timeout), the cpong error shows up 1 minute after the tomcat > request finished instead of 2. OK, so that explains why the cping/cpong info log depends on the ping_timeout (via the relation to the inerval). >> Go with connection_pool_minsize=0 and ignore very occasional info > level >> messages. >> > > Will this affect my performance since it won't keep any connections in > the pool and have to recreate one on every request? No it won't. Connections will only be shut down, when they are idle for more than a minute (the pool timeout xou configured). So if your site is busy only very few of your connections (peak load connections) will be closed, all other connections will stay open and be reused. Testing with occasional clicks doesn't reveal that behaviour. If the site is not busy, then the connection creation overhead will be more frequent, but due to the small load on the system it will be no problem at all for your system resources, and the latency you add in a normal LAN will be in the single digit milliseconds range. > As long as the ping without pong isn't going to break anything (like you > said, it's info, not error (just sounds like a not-good thing)), i'm > fine with it. Right. >> You could have a look at "netstat -an | grep 8009" on the Apache > server >> (or whatever your AJP port is) and see, how the status of the >> connections changes, e.g. from ESTABLISHED to CLOSE_WAIT (remote side >> has closed the connection) and TIME_WAIT (local side has also closed >> the >> connection). > > After a tomcat request I have: > tcp 0 0 10.10.10.18:13597 10.10.10.16:8009 > ESTABLISHED > > After the tomcat connectiontimeout I have: > tcp 1 0 10.10.10.18:13597 10.10.10.16:8009 > CLOSE_WAIT Yes, so you can see Tomcat closed the connection, and mod_jk didn't yet do the same. > After the cpong error I have nothing/no connection With minsize > 0 we might not close the connection although the idle timeout has passed and the cping will detect the CLOSE_WAIT status and as a result mod_jk will close it to. With minsize==0 we will already close it because of idleness and there will be no need for the cping test, since the connection doesn't exist any more. > Because of the connectionTimeout in tomcat and the cpong failure, it > seems like I'm defeating the purpose of a connection pool anyway, no? > Since the tomcat socket close is minutes later causing the mod_jk socket > close. No, think about a busy situation. Then the most connections will not be idle for a long time, nd thus neither tomcat nor mod_jk will have a reason to close them. >> We saw that. Since Cping/Cpong worked, we do not even have an info >> message, only debug messages. >> >>> At this point tomcat manager status shows the socket in stage 'P' > and >>> keeped alive socket count is 0. >>> Above mod_jk log repeats every 2 minutes. Tomcat manager status >> doesn't >>> change. > > Is it me or is this a better situation to be in? > I'm not sure about the 'P' stage though, if it's suppose to be that way, > or if it should be back at 'R' at this point. Sorry, I'm to lazy (busy) at the moment to check, what exactly 'P' and 'R' for AJP connections in the Tomcat manager mean. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
