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