On 22.05.2009 23:09, Lawrence Lamprecht wrote: > Rainer, > > Thanks for great advice, unfortunately I am not a programmer and have some > issues when I try to compile the updated mod_jk. > > What I have tried is to compile mod_jk under Centos. > > Below are my proceedures. > My config. > > [r...@localhost native]# head -n1 /etc/issue > CentOS release 5.2 (Final) > > [r...@localhost native]# httpd -v > Server version: Apache/2.2.3 > Server built: Nov 12 2008 10:41:27 > > I started as instructed with > ./buildconf.sh
Don't do buildconf.sh. It is only needed if you checkout mod_jk directly from the source code repository. It will create the configure script, which is already contained in the official source code distributions. It might not produce any problem, but you need more tools installed to be able to run buildconf.sh, than only for the real build. > ./configure --with-apxs=/usr/sbin/apxs > Make > > As far as I can see there were no error, I then copied the mod_jk.so to the > apache modukes dir. > > The concern that I have was the location of the new file. > /usr/src/tomcat-connectors-1.2.28-src/native/apache-2.0 > > My apache install is /etc/httpd/ > > The version of apache I am running is 2.2.3 and the one that was installed > for is 2.0? No, odules for 2.0 and 2.2 will both be build inside the apache-2.0 directory. It should have been named 2.x some time in the past. This simply comes from the fact, that the module for 2.0 and for 2.2 can be build form exactly the same source. Below that apache-2.0 there should be a .libs directory, that contains the new mod_jk.so file. You then need to find out where your Apache installation keeps its modules. Either look for the LoadModule lines in the config, or you could try /usr/sbin/apxs -q libexecdir Caution: on some linux systems there's an apxs and an apxs2. The first is to compile things for Apache 1.3 and the second for 2.x. > Other than that I am completely lost. > > Thanks again for your help and advice. HTH Rainer > Read our blog: Intelligent Supply Management - Your advantage > > -----Original Message----- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Friday, May 22, 2009 3:10 PM > To: Tomcat Users List > Subject: Re: mod_jk status code and loadbalancer monitoring > > 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
