tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Tomcat 6 plans (JSP 2.1)
Date Thu, 22 Dec 2005 17:50:33 GMT
On 12/22/05, Henri Gomez <> wrote:
> 2005/12/22, Remy Maucherat <>:
> > Henri Gomez wrote:
> > > Well a Tomcat will a small memory footprint is also very interesting for me
> >
> > How is Tomcat memory usage large ? Personally, I would think it's
> > extremely reasonable given the feature set, at least when using APR. It
> > would seem the base Java runtime would completely offset any gain there.
> Well memory is not the only point, faster start and less class to be
> loaded is also very important for me. In my company we're still using
> Tomcat 3.3.2 on our production servers (iSeries) since they are quite
> fast to start and that's very important when you have at the same time
> not less than 20 or 25 instances of Tomcat starting in its own JVM
> (one tomcat for a customer since the applications hosted have
> differents life cycle and constraint).

I didn't do any real benchmark, but the single-jar 5.5 should be as
fast on startup as 3.3.

Less class loaded - and less classes/features you need to worry when
setting up and maintainig is what I meant by footprint - Jetty is
around 0.5M I think.

The fact that we have features for everyone is nice - but a developer
doesn't need clustering
or APR, and a production server doesn't need the old connector, the
simple realm or the even the jasper compiler. It's more about beeing
simpler for everyone - by providing the functionality they use.

And no - it doesn't require any major refactoring - just small tweakings.

I understand this doesn't help for JBoss - but tomcat != jboss.

As for JMX - I think we do have a lot of things exposed, and adding
more is quite easy. I think part of the problem is that we may have
too much :-), and most generic JMX tools are not that good when you
have too much data to browse. IMO organizaing a bit the information
and maybe providing simpler interfaces would help.

Having a minimal set of features in the base package doesn't mean you
can't have a lot of features, and it doesn't mean it's much harder to
add features. In a production environment it's the same - either you
remove all the components you don't need or don't understand ( and
might break something ), or just add the components that you need.

Think about Firefox versus Mozilla. We are in exactly the same
situation, just on server side :-)

It's funny that JBoss does have most of this capability already - so I
understand Remy not wanting to reinvent the wheel :-), but I don't
think he can deny that this is a good thing to have.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message