On 19.08.2009 15:12, Markus Pohle wrote: > > > Hi list members, > I am Markus Pohle, new subscriber to this list and long time user of > apache tomcat and tomcat connector (with apache httpd). > > I do have a question according to mod_jk and jkstatus for which I did > not find any answer or solution, neither on internet/google nor the > mailing list and I hope, someone of you can help me. > > Here is the scenario: > > - two physical frontend servers, each with one apache httpd webserver > with mod_jk > - two physical middle tier servers, each with two apache tomcat servers > - the two frontend servers use linux-ha and heartbeat for failover > - mod_jk on the frontend servers are used to connect thru ajp13 to the > tomcat servers and do simple loadbalancing and failover (for the tomcats) > > - the both frontend servers with apache httpd have same mod_jk > configuration (of course!) > > now it comes... > > during uptime changes are made to the mod_jk configuration thru the > jkstatus pages, like disabling or stopping one tomcat node. if that > happens, the actual jkstatus configuration does not match the static > mod_jk-conf-file configuration any more. if the first frontend server > (or the apache httpd server on it) crashes, linux-ha and heartbeat do a > takeover to the second frontend server and start apache httpd on the > server. during apache httpd startup it loads its mod_jk configuration, > but that one differs from the actual jkstatus configuration on the > crashed first frontend server! > > My problem is, that I do not know how to replicate the actual jkstatus > config from the first frontend server to the second one so that i case > of takeover the modified configuration from with jkstatus is being kept. > > Does anybody ever had the same problem? Is there a solution? Any help > would be realy appreciated!
I don't have a nice answer, but I would - use a script for the common tasks, like changing the activation state - use administrative discipline for the unspecific rest of changes jkstatus uses only GET requests, and the URLs are easy to compose. So you can have a script using e.g. curl as an http commandline client and looping over the nodes of your farm to apply chnges for all nodes. The script can be run on any node, that has web access to jkstatus of all Apaches. curl also knows how to do basic auth. I plan to add saving of config changes, but this will not obviously solve the replication problem. The saved changes will be most likely in the form of a change protocol which gets replayed (added to the workers.properties) during startup. So in a distributed situation you would still need to apply the changes to all nodes. Farm management is currently not close (in time). Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
