tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: [Proposal] Change in behaviour of uriworkermap.properties
Date Tue, 21 Nov 2006 10:40:26 GMT
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


Mime
View raw message