Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <456232E2.8070708@kippdata.de>
Date: Mon, 20 Nov 2006 23:57:38 +0100
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: [Proposal] Change in behaviour of uriworkermap.properties
References: <45622A27.203@kippdata.de>
 <6291fc850611201435g13eed76k3377b3383268335f@mail.gmail.com>
In-Reply-To: <6291fc850611201435g13eed76k3377b3383268335f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Hi Henri,

Henri Gomez schrieb:
> JkMount shouldn't be affected by any automatic reloading to preserve
> compatibility.

They will not be affected, neither with the old, nor with the proposed
new implementation. That's why I would flag them as "static", versus
dynamic for the uriworkermap.properties mounts.

> The new mounts via uriworkermap.properties chould be considered
> transient, ie they could follow the file change but did the 60s isn't
> too long is some circumstance ?

We could make that configurable, but it will have the important
performance penalty (checking file timestamps more often). 60 seconds
was the interval I think since the implementation started.

> I think it will be better to make the Routing administration via some
> basic HTML pages where the admin click the 'action' button and know
> when the new rules are applied.

Yeah, that would also be very nice. But: mounts are handled per virtual
server, so if you wanted to change a mount for a special virtual server,
you would also need to call the admin webapp inside that virtual server.
Many deployments I know, place the admin webapp (=status worker) in a
special virtual host, only listening on an admin network. That one will
not see the mounts of the other virtual hosts. I'm thinking about how we
can improve the interoperability between the status worker, shared
memory and the mount maps, but that will be a more tricky change.

> 2006/11/20, Rainer Jung <rainer.jung@kippdata.de>:
>> Hello,
>>
>> I would like to change the detailed behaviour of uriworkermap.properties
>> (JkMountFile) in mod_jk in a non-compatible way. The reason is a problem
>> I found with the momentary implementation plus the impression, that the
>> actual behaviour in detail is a little strange.
>>
>> I'm interested in opinions about that.
>>
>> 1) Old situation
>>
>> Entries in uriworkermap.properties are read during startup. They are
>> added to mount defined by other means (JkMount and mount attribute in
>> worker.properties and JkWorkerProperty).
>>
>> When the file has been changed and some time went by (60 seconds after
>> reading it last) the next request will trigger a new read of the file.
>>
>> Now only entries, that did not exist before, are being added to the
>> internal mount list. To "remove" an entry from the internal list, one
>> needs to add a minus sign in front of an existing entry.
>>
>> 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. One could live with that (after we
>> improve the docs).
>>
>> 2) Problem
>>
>> During runtime this means, that the actual mount list consists of a
>> continuous overlay of multiple versions of uriworkermap.properties.
>> Unfortunately each web server process does this on it's own, it's not
>> shared data. Now if a process doesn't get any requests, it will not
>> detect a changed version of the file and may miss the reading=adding of
>> entries. Other processes might get requests and do the reloading. If the
>> files is being changed again and later on all of the processes get
>> requests, the internal mount list of the various processes will begin to
>> differ. As a result the correct forwarding of requests will depend on
>> the process that handles the request, which is out of control of the
>> user/admin etc.
>>
>> 3) Proposed new situation
>>
>> I would like to distinguish the mounts loaded from
>> uriworkermap.properties (=dynamic) internally from other mounts, like
>> JkMount, mount attribute in workers.properties and via JkWorkerProperty
>> (=static). If the uriworkermap.properties file changes, the process will
>> delete all dynamic mounts and completely reload them from the file.
>>
>> That way each process does have a consistent internal state, reflecting
>> the state of the config files, at least whenever the 60 seconds have
>> passed.
>>
>> It would be nice to use the shared memory segment as an intermediate to
>> handle the reloading. But as long as all actions in the processes are
>> only triggered by requests, in the old model this would only help, if we
>> also exchange the maps via the shared memory. This change would be much
>> more delicate. So I would prefer an easier change by simply marking the
>> map entries internally.
>>
>> The important thing is: afer the change the feature would behave
>> differently, but I must confess: every user I met first expected the
>> behaviour I suggest here. Everyone thought the old behaviour is exotic.
>>
>> Comments?
>>
>> 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