tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <james.t...@eng.sun.com>
Subject Re: request for review: server/config discussion
Date Tue, 20 Jul 1999 20:26:30 GMT

i hope the "server/config" discussion/subProject can kickstart
without too much overhead from existing projects ... hence my
artificially constraining this to a "100% pure java server config
initiative." also, the tomcat implementation is so simple and
most likely provides a complete subset of features needed by
other servers (this is not to say it is feature complete) this
to is an attractive starting point in my book.

i do hope this "config service" can be used by more engines and
can even possible manage a wider set of configuration data ...
big picture and this will be stated in the "objectives" section.
down to earth a bit, we've got to starting picking the low
hanging fruit to kick this off. as i see it, these are:

	tomcat (small, 100% java server, xml config driven,
		and is actively tracking the servlet and jsp
		specifications)

	xml config format as a baseline today ... possibly
		openining this up to other formats as
		consensus feels appropriate

	multi-protocol friendly "configuration service" which
		will shield the consumers of configuration
		data (server with read access, tools with
		read/write access) from the data format (xml)
		and file i/o details

from the feedback that has been posted, i think the boundaries
of this discussion are well based and there are two to three
key subTopics of interest:

	xml format

	entitity roles (eg config service, server, etc)

	api (as i see it this will be a fallout of getting
		the afore mentioned roles on the table)

hope this helps,

- james

hope this helps,

- james

hope this helps,

- james

Ben Laurie wrote:
> 
> "Craig R. McClanahan" wrote:
> >
> > Ben Laurie wrote:
> >
> > > "Craig R. McClanahan" wrote:
> > > > My single biggest gripe about Apache (or Netscape Enterprise Server, and
I'm sure lots of others),
> > > > no matter now good it is at what it does, is the fact that you have to
restart the server for the
> > > > most trivial configuration file changes.  To me, that's not the way things
should work -- it should
> > > > be possible to make incremental changes to existing configurations, at
least to some level, without
> > > > global restart being required.  This doesn't seem to be a high priority
for most server
> > > > developers (and I'm talking to myself here as well -- Apache JServ 1.1-DEV
still requires restarts
> > > > on config changes), but it sure does matter in environments where a server
restart can be very
> > > > disruptive to lots of users.
> > >
> > > a) Apache supports "graceful" restarts for this reason.
> >
> > The Apache source code is pretty dense, but it looks like a graceful restart still
kills all the child
> > httpd processes and recreates them.  Among other things, that seems to mean all
the modules go through
> > their initialization lifecycle again.
> 
> Yes, but not if they are currently processing a request. This means it
> doesn't disrupt users.
> 
> > > b) Supporting incremental changes could get pretty complicated, because
> > > of cached derived information. I suppose simply blowing away all the
> > > caches is feasible, though.
> > >
> >
> > Speaking as an author of server-side stuff as well (Apache JServ 1.1-DEV) I am familiar
with the "pretty
> > complicated" parts of it.  Basically, you can no longer count on certain things
being static for the
> > life of your server, and this has lots of ramifications.  But exit/restart is still
the lazy way out of
> > dealing with the issue.
> 
> And is there something wrong with laziness? :-)
> 
> 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