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 10:28:04 GMT
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.
> 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.
> 
> > 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.
> 
> 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.
> 
> 
> 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.

Cheers

Jean-Frederic

> 
> 
> Regards,
> Mladen.
> 
> ---------------------------------------------------------------------
> 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