tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: ServerSocket not being closed properly.
Date Tue, 24 Apr 2001 16:50:18 GMT
On Tue, 24 Apr 2001, Brad Cox wrote:

> At 7:23 AM -0700 04/24/2001, wrote:
> >Anyway - a cleaner solution ( IMHO ) is to just set "stoped" and do a
> >bogus connection. That's what I did in 3.3 - and seems to work fine.
> That does sound better. I really hope this gets nailed ASAP. I 
> suspect the present configuration complexity, exacerbated by the lack 
> of configuration validation, could be fixed with a simple gui.

There are few ideas that can be used for configuration validation, and
the best ( IMHO ) is to run the sanity test after every change in the
config file. ( maybe watchdog too ).

In 3.3 we package all the tests as self-contained wars, and the admin has
a web-based runner - but it needs more polishing to make it really easy to

I don't think anything else will work - XML validation doesn't help too
much ( since tomcat is a collection of modules - and the user can add any
custom module, the problem is to validate that the configured collection
of modules works fine )

We could also do small smog-tests at startup ( few internal requests,
etc), but that's not too good ( affects tomcat on each startup, and it's
not complete anyway ).

Regarding the configuration complexity - the main problem is the fact that
in few cases the module order is important ( this is true for Apache 1.3
also, and Apache2.0 improves a bit with the new "position" parameter).

Tomcat 3.3 takes a similar aproach with Apache2.0, by letting the module 
register itself in the right position in each chain - the
current architecture should provide all the needed elements. The only
problem is that each module must be modified to take advantage of the new
API, and this takes time ( and it's not a top priority - fixing the
existing bugs and releasing a stable 3.3.0 is more important IMHO ). 

BTW, 3.3 also has a (reasonably) well defined "state", that should allow
restart, adding/removing of configs, etc. Since the connectors are pluged
in as regular modules, the architecture allow them to reconfigure the
server ( either by config re-generation as in the current code, or by 
automaticly sending the config via ajp14 as proposed ). Again - the
modules must take advantage of that, and it takes time and work.

Most of the effort has been put into the lower-level architecure and
modularity - and not in individual modules. The idea is that in time we
can rewrite individual modules ( for example the mapper is a big target
for optimizations, etc ), and improve various spots.

> This might go far towards turning around the bad press Tomcat has 
> been getting of late, but this problem is fatal to gui wrappers.

Well, the "bad press" is right in many aspects - we do need an
installer and better admin gui. At least on Linux the RPM install does a
lot of magic ( and can do even more, there are few ideas to improve it ), 
but a windows installer will do a lot. 

Fact is - we do improve - and that's what matters ( for me ). I don't
think anyone claims the first versions of apache were easy to install ( or
even the latest ).  


View raw message