tomcat-dev mailing list archives

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

Henri Gomez schrieb:
> JkMount shouldn't be affected by any automatic reloading to preserve
> compatibility.

They will not be affected, neither with the old, nor with the proposed
new implementation. That's why I would flag them as "static", versus
dynamic for the mounts.

> 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 ?

We could make that configurable, but it will have the important
performance penalty (checking file timestamps more often). 60 seconds
was the interval I think since the implementation started.

> 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.

Yeah, that would also be very nice. But: mounts are handled per virtual
server, so if you wanted to change a mount for a special virtual server,
you would also need to call the admin webapp inside that virtual server.
Many deployments I know, place the admin webapp (=status worker) in a
special virtual host, only listening on an admin network. That one will
not see the mounts of the other virtual hosts. I'm thinking about how we
can improve the interoperability between the status worker, shared
memory and the mount maps, but that will be a more tricky change.

> 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:

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

View raw message