tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject [Proposal] Change in behaviour of
Date Mon, 20 Nov 2006 22:20:23 GMT

I would like to change the detailed behaviour of
(JkMountFile) in mod_jk in a non-compatible way. The reason is a problem
I found with the momentary implementation plus the impression, that the
actual behaviour in detail is a little strange.

I'm interested in opinions about that.

1) Old situation

Entries in are read during startup. They are
added to mount defined by other means (JkMount and mount attribute in and JkWorkerProperty).

When the file has been changed and some time went by (60 seconds after
reading it last) the next request will trigger a new read of the file.

Now only entries, that did not exist before, are being added to the
internal mount list. To "remove" an entry from the internal list, one
needs to add a minus sign in front of an existing entry.

E.g. if one empties the, reloading it does not
change the internal mount list. Temporarily adding and later removing an
entry will not remove the entry. One could live with that (after we
improve the docs).

2) Problem

During runtime this means, that the actual mount list consists of a
continuous overlay of multiple versions of
Unfortunately each web server process does this on it's own, it's not
shared data. Now if a process doesn't get any requests, it will not
detect a changed version of the file and may miss the reading=adding of
entries. Other processes might get requests and do the reloading. If the
files is being changed again and later on all of the processes get
requests, the internal mount list of the various processes will begin to
differ. As a result the correct forwarding of requests will depend on
the process that handles the request, which is out of control of the
user/admin etc.

3) Proposed new situation

I would like to distinguish the mounts loaded from (=dynamic) internally from other mounts, like
JkMount, mount attribute in and via JkWorkerProperty
(=static). If the file changes, the process will
delete all dynamic mounts and completely reload them from the file.

That way each process does have a consistent internal state, reflecting
the state of the config files, at least whenever the 60 seconds have passed.

It would be nice to use the shared memory segment as an intermediate to
handle the reloading. But as long as all actions in the processes are
only triggered by requests, in the old model this would only help, if we
also exchange the maps via the shared memory. This change would be much
more delicate. So I would prefer an easier change by simply marking the
map entries internally.

The important thing is: afer the change the feature would behave
differently, but I must confess: every user I met first expected the
behaviour I suggest here. Everyone thought the old behaviour is exotic.



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

View raw message