tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: UserConfig: alternative implementation
Date Wed, 04 Nov 2009 18:46:07 GMT
On Wed, Nov 4, 2009 at 6:47 AM, Mikhail Kryshen <> wrote:

> On Tue, 3 Nov 2009 16:34:57 -0800
> Costin Manolache <> wrote:
> > Curious: how does it scale for large number of users, in particular if
> you
> > have NFS homes ?
> I use it at a university server with 780 user accounts with home
> directories mounted via NFS from distinct file server, user database is
> LDAP. Reading the remote user database and checking all home directories
> for webapps takes about 100 ms of real time.
I was asking about tomcat startup time - loading all the 780 contexts,
versus a normal
startup with 2-3 contexts. BTW - it would be nice to include this kind of
info in the docs.

> Performance for the large number of deployed webapps would likely be the
> same as with the original tomcat UserConfig or Host having all the apps
> in a single appbase.
> It would be interesting to change this to not init the contexts when
> tomcat
> > starts - just register a handler that would start the context on first
> > request.
> > Or as a Valve that looks for ~foo and then lookups and start the context
> for
> > that user on demand.
> Most contexts will probably start soon anyway since every user would want
> to check his/her webapp after it is installed. Then to make this approach
> useful some checking for long-ununsed contexts would be required or
> periodic tomcat restarts to clean-up. Anyway it would be interesting
> thing to implement.

780 users each accessing his app every time tomcat starts ? I doubt it.
You're right, stopping long-unused contexts would be another nice thing.

> > IMHO this could be a nice feature - but it's a perfect example of thing
> that
> > shouldn't be bundled in tomcat, but
> > available as a separate download. And if it used a scheme like /user/foo
> -
> > it may even be possible to implement it as a app+standard filter, with
> just
> > one 'internal API' call to load the context.
> For me it's not a problem to support this as a separate package, but
> tomcat already have such a thing bundled which is not currently very
> useful.

Well, since we'll have a major release - it is possible to move what used to
be bundled ( and not
currently very useful or used by lots of people ) to separate packages that
can be
better supported.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message