tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: possibility of runtime replication of jkstatus / mod_jk
Date Wed, 02 Sep 2009 18:27:46 GMT
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 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).



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message