tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Gomez" <henri.go...@gmail.com>
Subject Re: [Proposal] Change in behaviour of uriworkermap.properties
Date Tue, 21 Nov 2006 10:44:04 GMT
Why not just extends current jkstatus ?

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


Mime
View raw message