JkMount shouldn't be affected by any automatic reloading to preserve compatibility.
The new mounts via uriworkermap.properties 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 <[EMAIL PROTECTED]>:
Hello, I would like to change the detailed behaviour of uriworkermap.properties (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 uriworkermap.properties are read during startup. They are added to mount defined by other means (JkMount and mount attribute in worker.properties 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 uriworkermap.properties, 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 uriworkermap.properties. 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 uriworkermap.properties (=dynamic) internally from other mounts, like JkMount, mount attribute in workers.properties and via JkWorkerProperty (=static). If the uriworkermap.properties 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
