Rainer, On Tuesday 07 September 2010 11:09:46 you wrote: > > [Tue Sep 07 10:20:20.617 2010] [18806:46962404156768] [debug] > > find_match::jk_uri_worker_map.c (850): Attempting to map context URI > > '/*=lb-jboss51-integration' source 'JkMount' > > [Tue Sep 07 10:20:20.617 2010] [18806:46962404156768] [debug] > > find_match::jk_uri_worker_map.c (863): Found a wildchar match > > '/*=lb-jboss51-integration' > > [Tue Sep 07 10:20:20.617 2010] [18806:46962404156768] [debug] > > jk_handler::mod_jk.c (2462): Into handler jakarta-servlet > > worker=lb-jboss51-integration r->proxyreq=0 > > [Tue Sep 07 10:20:20.617 2010] [18806:46962404156768] [debug] > > wc_get_worker_for_name::jk_worker.c (116): found a worker > > lb-jboss51-integration > > [Tue Sep 07 10:20:20.618 2010] [18806:46962404156768] [debug] > > jk_shutdown_socket::jk_connect.c (722): About to shutdown socket 154 > > [Tue Sep 07 10:20:22.619 2010] [18806:46962404156768] [debug] > > jk_shutdown_socket::jk_connect.c (813): Shutdown socket 154 and read 0 > > lingering bytes in 2 sec. > > Hmmm, that's strange. Why is there a connection close between > wc_get_worker_for_name() and wc_maintain()? The first call doing > something with the connections would be wc_maintain(). And if it decides > to close sockets, it would log addiional statements. Nevertheless we can > see, that closing the socket really took 2 seconds (which is in fact a > builtin mod_jk timeout).
That's interesting, because I thought this bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=48169 Was addressed in 1.2.30 and this discusses a 2 second problem. > Are we sure, that those log lines are correct? This was generated by > mod_jk 1.2.30 without any code changes, right? I compiled it fresh from source without any change: [Tue Sep 07 10:07:56.683 2010] [17424:46962404156768] [info] init_jk::mod_jk.c (3189): mod_jk/1.2.30 initialized > Log level trace would show us more precisely, how we came to close the > socket, but it blows up log volume a lot. I'm using trace and greping for whatever you need to see. if you want to see more debug, tell me what keyword to grep (ideally, so I don't catch the hundreds of other lines of debug being generated by other worker threads). > > To confirm the settings: > > > > worker.basic.connection_pool_timeout=90 > > You don't usually want to set a pool_size. "1" would be appropriate when > using the prefork Apache MPM, but in that case mod_jk automatically sets > it to "1". I can remove it if you want - I only set it to 1 to ensure it was set (yes, I am using prefork). > > > worker.basic.connection_pool_size=1 > > worker.basic.socket_keepalive=1 > > I don't like "socket_timeout" ... Why? > > worker.basic.socket_timeout=90 > > but I would like socket_connect_timeout. I can change it. > The next two are possibly a bit short, because if the backend e.g. does > a Java Garbage Collection which miht take longer than 1 second, tose > timeouts will fire and take the node out of load balancing. > > > worker.basic.connect_timeout=1000 > > worker.basic.prepost_timeout=1000 > > You might want to add max_reply_timeouts, otherwise one single reply > timeout can take a node out of load balancing. > > > worker.basic.reply_timeout=90000 > > # Stop recoery attempts when JBoss instances do not respond. > > worker.basic.retries=1 > > worker.basic.recovery_options=27 > Don't want sticky sessions? Nope. The app clusters. Although it's set for other workers. John --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
