Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of henri.gomez@gmail.com designates
 64.233.166.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=YwzcKCts8x+Rt9CFV7WMzxWMA9JBWgmE7kARfXodKDXbi8yxMMaso/XtbidoO4YS1SNJYIOShRWxf+tJ/6I5T7TLTnNgiZ0PPvi2UUd4bzpETG0f8FcNsnAMNGfY5+3IbT43IsVbZEH5Xa3wbqXS24SxvQtYdUS0q/HBbqiBZkk=
Message-ID: <6291fc850604062020o192cb37ex16e9572a11b774a1@mail.gmail.com>
Date: Fri, 7 Apr 2006 05:20:59 +0200
From: "Henri Gomez" <henri.gomez@gmail.com>
To: "Tomcat Developers List" <dev@tomcat.apache.org>
Subject: Re: Challenges for Java hosting
In-Reply-To: <443521E7.5010609@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <443521E7.5010609@apache.org>

2006/4/6, Remy Maucherat <remm@apache.org>:
> Hi,
>
> This thread started (for whatever reason) on the private list as part of
> an unrelated discussion. The point is to see what could be improved to
> make Tomcat more suitable for shared hosting, which is a very nice goal,
> but unfortunately with very serious issues.
>
> I don't see many improvements possibilities, as I consider the following
> solutions and problems (where each user would at least need its own vhost=
):

I see vhost as a client virtual server, where the 'client' is not a
real / human end user but someone who ask you to host its applications
with one or many webapps in it.

> - Every virtual host gets its own appBase folder. Having its own folder
> for JARs just won't work (or it means you were able to use the "shared"
> folder successfully, which I doubt).

What do you mean ? Did we have actually such own folder of vhosts jars
with its own classloader ?  If not could it be done easily ?

Actually a client application get its classes from :

- jars in common [lib, endorsed, i18n] and webapps lib directory

- classes from common [ classes ] and webapps classes directory.

Could we have instead a by vhost supplemental directory to get its own jar =
?

example :

vhosta will grab in jars in /home/vhostsa/lib and common [lib,
endorsed, i18n] and webapps lib directory

vhostb will grab in jars in /home/vhostsb/lib and common [lib,
endorsed, i18n] and webapps lib directory.

In such case did the classloader for vhosta should be different from
the one for vhostb.


>If you use the
> TOMCAT_HOME/TOMCAT_BASE stuff, each user can get its own "shared" folder.

> - There are still tons of JVMs to manage and monitor, which may be a
> problem.

Why did there should be tons of JVM ? Couldn't we use a single JVM for
each vhosts ? As many I prefer give more power and resource to a
single JVM that spread thread and memory to many JVM where some could
be at some time very less used than others.

> - If the connector should be shared, with the servlet containers running
> in separate processes, I don't see how to cross the process barrier
> except by going back to square one (httpd in front, with AJP and many
> JVMs/Tomcats, each with its own vhost).

That's the current situation now, one Apache 2.x with multiples
virtuals servers, each virtual server with its own JK/AJP worker to
reach a specific Tomcat.

> Some general problems for production are:

> - No self tuning of the JVM.

Of course but it's not better to have may JVM present in system with
memory and thread/system resources use when for exemple users are only
using one of the multiples JVM.

Imagine for example users for differents country, said asia, europe and USA=
.

You setup one JVM / Application for ASIA users, one for Europeans
users and the third for US users.

During the day, you'll see activity on Asian JVM, then European JVM
and then on US JVM, but even when only one is really used, the 2
others are still in machine and consume memory and resources. Sad,
this power could be better used for the really active JVM.

> - No actual isolation, throttling capabilities, etc, provided by the JVM.

JVM or OS ?

> - Impossibility to control memory leaks (impossible to force discarding
> classloaders and all associated class defs and instances, for example).

What do you means ?

> - Hard to do thread management (by that I mean, monitor and recover for
> threads stuck in loops or deadlocked).

Well it's also hard today with a 'dedicated' JVM, the only solution
may be to restart the JVM ...

> Any ideas ?

Well if it could be done, I'm sure you're probably the best to imagine
such solution.


> I suppose native code could be used to improve the situation in some
> areas (although I don't know how to do it ;) ).

Native code ? Do you imagine some sort of sub-JVM launching ?

> R=E9my
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org