Jean-frederic Clere schrieb: > On Tue, 2006-11-21 at 06:52 +0100, Mladen Turk wrote: >> Rainer Jung wrote: >>> 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. >> That's the entire point.
But this is not what a user expects from a change in a list. >> Once new entry is added it will be there for the server lifetime. >> Of course it can be disabled with minus prefix. >> >> If one adds the mount point and then deletes it, other child >> processes might not pick that up, but that's not how they >> suppose to work. "Deletion" *must* be done only by prefixing >> the mount points with minus. >> I'm not even sure why I allow to have the new mounts at >> the first place. OK, but you did. And my proposal comes in, because I want to fix this behaviour exactly becauswe of the case, are adding and deleting rules. >> >>> One could live with that (after we >>> improve the docs). >>> >> Sure. The entire idea of reloading a uriworkermap.properties >> was to temporary disable some pre-existing mount. I understand, but it can be used in a much more powerful way. It's an external file with an easy syntax, so external monitor and manage scripts can easily manipulate it's contents. >> >> Anything else should be handled via graceful restart. >> BTW, this was added only to help the IIS that doesn't have >> the graceful restart concept. Graceful restarts can produce hanging processes under heavy load. You'll notice slots in state "G" or "L" in the server-status. >> I don't like the idea of splitting the static and dynamic >> mount points. >> The proper way to go would be to add the second shared memory >> (database like) that would contain the mount points with >> options to manage that via jkstatus. Anything else IMHO is >> useless, because it can be done via simple restart, if one >> needs to add/remove the whole bunch of new mounts in frequent >> way. > > Yep. Static configuration is just a dynamic configuration that never > changes. The right way to go is to have the configuration in shared > memory the complex stuff is how to update it. > I am trying to get something similar to work on mod_proxy and I need an > external process to update the shared memory. That using shared memory to share the mapping rules and the changes is what I wrote too. And I will investigate this further. My suggestion is to make the current behaviour of uriworkermap.properties reloading easier to understand for the users. This is something I can easily do for the next release. Handling the rules via shared memory would definitely have to wait at least for one more release. > > Cheers > > Jean-Frederic > >> >> Regards, >> Mladen. >> Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
