On Tue, 2006-11-21 at 11:58 +0100, Rainer Jung wrote: > Henri Gomez schrieb: > > Why not just extends current jkstatus ? > > Mapping rules are kept process local. They are only shared, because the > first process generates them and afterwards all other processes inherit > them during fork. > > To make the rules manageable via jkstatus (everyone wants that, me too; > it's a much bigger task) we need to do two things: > > - use shared memory at least to exchange information about changes to > maping rules, so that the process that handles the jkstatus request is > able to distribute the changes. > > - also we need to think about virtual hosts: mapping rules are per > virtual host. At the moment, if you call jkstatus, you will only see the > rules defined for the virtual host, which you called with jkstatus. If > you want to have a central administration point, jkstatus must go > through all vhosts starting from the main server to produce the list, > and if you change something it might need to change it in a vhost that's > different from the vhost, the request runs in. > > This is no argument, that it is very hard to make these changes. It's > simply not in scope for the next release, which should get ready in very > few days, because we had a couple of nice bug fixes since 1.2.19.
May be that is time to make a new branch: 1.3 for example ;-) Cheers Jean-Frederic > > Regards, > > Rainer > > > > > 2006/11/21, Rainer Jung <[EMAIL PROTECTED]>: > >> 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] > >> > >> > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
