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

Reply via email to