tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Clarke" <tcla...@agency.com>
Subject Re: request for review: server/config discussion
Date Tue, 20 Jul 1999 21:18:03 GMT
You also might want to be able to commit a batch of changes at once.

I think if we:
    a) make it easy to do something equivilent to kill -HUP
    b) allow partitions to be refreshed independently

We would have something pretty useful.


Tom


Tom Clarke
Senior Software Engineer
AGENCY.COM
v 212.358.2798
----- Original Message -----
From: Ben Laurie <ben@algroup.co.uk>
To: <tomcat-dev@jakarta.apache.org>
Sent: Tuesday, July 20, 1999 5:12 PM
Subject: Re: request for review: server/config discussion


> James Todd wrote:
> >
> > "Carreira, Jason" wrote:
> > >
> > > If those values depend on values in the config construct, they should
> > > regsiter themselves as listeners to receive changes from the config
object.
> >
> > craig has expressed this request as well and i do like
> > the idea that "a config service listener" can choose to
> > act on config detail changes as deemed appropriate. as i
> > see it, there are two main features (and a couple of sub
> > features):
> >
> >         translate "persistified config data" to the relevant
> >         objects
> >
> >         provide a multi-protocol service to config data
> >         consumers (aka listeners) to:
> >
> >                 read config data (eg server)
> >
> >                 read/write config data (eg tools)
> >
> >                 notify (actively or passively) listner
> >                 that a config change has occurred since
> >                 the last request
> >
> > each of these do need to be stated a bit more explicitly
> > for review but i do believe there is a common goal taking
> > form here.
>
> Much as I like the idea of notifying config changes, I think it is
> likely to lead to trouble. Here's the problem in a nutshell: either you
> notify in detail what the changes are, in which case we are looking at
> horrendous complexity and likely lots of interesting failure modes, or
> you just say "it's changed" in which case you only need a single module
> that requires a restart (canonical example: Apache listeners - these
> cannot change without a restart) and every change gives you a restart
> anyway.
>
> I suppose its possible that there's some middle ground, but I'm afraid
> my imagination has failed me...
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
>      - Indira Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>


Mime
View raw message