Hi Lawrence, I will answer in a slightly different order below.
On 22.05.2009 13:58, Lawrence Lamprecht wrote: > I found a really old entry from way back in 2005. Reading through a > trail of messages under the heading "Adding working dynamically with mod_jk > status" > > What I would very much appreciate is two things. I would like to know > where I can get some clear documents on the status codes for mod_jk. > The status codes appear in the mod_jk.log file in the following format. > > [Wed May 20 06:27:47 2009] [21343:33088] [debug] jk_handler::mod_jk.c > (1969): Service finished with status=200 for worker=loadbalancer1 > > I have also seen other entries for status=302 etc. > > I would like to understand what these status code mean or represent. > > The second thing that I would like to see is, do you have any > information on monitoring the workers in the mod_jk config. I know > about the jkstatus function, but that is not very dynamic. It only > really reports errors if the wroker is called. > > I had an issue where I took down on of the two workers in the > loadbalancer config, I saw the error that the first worker was no > longer available, but as soon as the second worker took over the work, > then the error was cleared and nothing more was reported. > > I have had an idea, but seeing as I am not a programmer, I have no > idea how to achieve this, but I hope that someone else has also had > the same bright spark. > > I was hoping that there was some application that did something > similar to what webalizer does with the access.log file for the apache > web server that could analyze the mod_jk.log file and dynamically > report the status of the workers as things happen. Something like a dashboard > to show what state the workers are in at any given time. When the log file > is rolling in debug mode, there is very much information that could be > used to report back on the worker status. > > I hope that someone might have some good ideas. > > Somehting that I have also thought about is possibly upgrading the mod_jk > version that I am running at the mo. > I have the following setup. > > Server version: Apache/2.0.52 > Server built: Jun 29 2007 05:08:11 > JK Version: 1.2.15 > > I get really confused with the different versions and compatibility, so could > I keep the current Apache version and only upgrade mod_jk, > Where would I find instauction on how to go about doing this. > > Thanks in advnce > Lawrence Lamprecht The status worker was added to mod_jk around the time of your version 1.2.15. It improved *a lot* since then. Actually during the last releases it was the focus of most of the development. So do yourself a favour and update mod_jk. Recent is 1.2.28. Compatibility: mod_jk works for Apache httpd 1.3, 2.0 and 2.2. You need to either compile it against your web server (preferred way) or fetch a binary for your httpd version somewhere, e.g. in our download area. You cannot use a mod_jk for 2.2 to run in 2.0 or vice versa, but the minor digits behind usually do not matter. Compiling is easy (depending a bit on your OS), so you best go that way. We deprecated some configuration attributes long ago, so after updateing have a look at the mod_jk log during startup, if it contains info about not supported or deprecated attributes. The docs contain info about how to replace those. There are only few such attributes. We didn't deprecate anything during the last 10 releases, but chances are, that you should change a few configuration attributes you used with 1.2.15. There is one caveat: JkMount not isn't inherited from the global server to any virtual host or between virtual hosts. If you have virtual hosts, put your JkMount into those or use JkMountCopy. See docs. Now about status codes: The code in the log line you cited is the HTTP status code we return to the client. Those are defined by the HTTP rfc, so 200="OK", 302 is a redirect, 500 is an internal server error etc. In most cases those are simply the ones we get from Tomcat, only if mod_jk detects an error itself it might generate an own status code like 500, 502, 503. Note that the log line is of debug level, so you are not expected to look at those during normal production. JkLogLevel info is enough for production. Any error will be logged at log level error, as long as no message of level error shows up, everything is fine. The info level messages are there to give additional info in case an error level message shows up. Dynamics of status worker: It is as dynamic as it can be. mod_jk doesn't do any probing. If there is an error with a worker we will only detect when there is a request for the worker. In that case, the status worker will immediately reflect the new status. In the latest two versions we started to implement a so-called watchdog thread, that does some very basic probing, namely a cping/cpong connection check for the pooled connections. The watchdog thread might get more powerful in the future. Concerning your observation with taking down one worker in a load balancer: Have a look at version 1.2.28. It should report the worker you took down as either ERR (if you didn't swicth activation to stopped in the status worker) the whole time it's down, or as STP in case you let the load balancer know, that the worker should not be used any longer (activation flag). For a dashboard it should be enough to poll the status worker like once a minute and present the results. The status worker allows varous response formats, which are easir to parse than HTML. See the status worker documntaiton page. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
