tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <>
Subject Re: request for review: server/config discussion
Date Wed, 21 Jul 1999 04:12:05 GMT

very well put. let me add another *real* one that bit us

	block/monitor requests originating from a common
	ip address as it could be an overly aggressive
	search engine which will 1) ignore a robots.txt
	file plea to "leave me alone", 2) can't handle
	url's with embedded session id's so it spins on
	a top level page asking for page-after-page-after-
	page at a rate of 3 a second and 3) thrashes your
	database "new session log" (data like userAgent)
	and when your db goes belly up your most likely

we had a "hand configurable" environment which did not require
server reStart to manage thresholds for this sort of "service of
denial" attack. i'm sure there are plenty more examples as to
why this would be a good thing.

to finish the above real life scenario a bit more, turns out
the rabid search engine was unleashed by another entity working
within the same company ... but it could've just as easily
been a competitor trying to bring the site down.

- james

Troy Poppe wrote:
> On Tue, Jul 20, 1999 at 11:29:08PM -0400, Tom Clarke wrote:
> > Seriously though, from a user/sysadmin perspective, does it actually buy you
> > anything - having multiple configurations I mean?
> >
> > I can't think of an application that gives you this much flexibility in
> > configuration. Doesn't mean it's not valuable, but what are the scenarios it
> > gives me benefit as a user/sysadmin? (and doesn't just make it more
> > confusing and complicated)
> Oh, I could give you MANY reasons why this would be nice from a designers
> standing.  Lets see.  This is going to get off topic fast, but what the
> hell.
> I have several webservers that I want to act different based upon
> event X happening elsewhere in my enterprise.
>         - Case 1:
>                 Database server fails, and the webserver needs to reconfigure
>                 the servlet environment
>         - Case 2:
>                 My webserver is an embedded device, perhaps attached to some
>                 external device, which is one of dozens of such units.  Event
>                 X occurs, and the configuation file is altered in an appropriate
>                 manner.  This should then notify my webservers, and they should
>                 update configuration, and change behavior.
>         - Case 3:
>                 I have several frontend webservers that I want to bring to
>                 some state S (up, return temp error condition, down) simultanteously.
>         - Case 4:
>                 I have several frontend webservers that I want to add information
>                 about a new service to.
> <reality>
>         There's probably a better solution to these problems.  However, and I don't
> mean to over-glorify anything, if we don't think up new ideas for how to better aspects
> of a product, we can't really be developers, we're more maintainers.
> </reality>
> - Troy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message