tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-frederic Clere <jfcl...@gmail.com>
Subject Re: [Proposal] Change in behaviour of uriworkermap.properties
Date Tue, 21 Nov 2006 11:44:39 GMT
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 <rainer.jung@kippdata.de>:
> >> 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: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message