tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Gomez" <>
Subject Re: [Proposal] Change in behaviour of
Date Mon, 20 Nov 2006 22:35:04 GMT
JkMount shouldn't be affected by any automatic reloading to preserve

The new mounts via chould be considered
transient, ie they could follow the file change but did the 60s isn't
too long is some circumstance ?

I think it will be better to make the Routing administration via some
basic HTML pages where the admin click the 'action' button and know
when the new rules are applied.

2006/11/20, Rainer Jung <>:
> Hello,
> 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.
> Comments?
> Rainer
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message