tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Challenges for Java hosting
Date Sun, 09 Apr 2006 19:57:54 GMT
--- "Preston L. Bannister" <preston@bannister.us>
wrote:

> Again, the main question is which target you are
> trying to hit.
> 
> Are you aiming at Java web hosting where a hosting
> service would offer Java
> to *all* their customers?
> 
> Are you aiming at Java web hosting for any (or
> nearly any) existing Java web
> application?
> 
> In the first case you are aiming at the niche where
> PHP has found great
> success.  On a purely theoretical level, PHP as a
> solution should not
> exist.  On a practical level, there are all sorts of
> reasons why (at
> present) Java is a PITA for web hosting services,
> and PHP is easy to
> accomodate.  In this problem domain the vast
> majority of sites are very low
> usage.
> 
> In the second case you are aiming at a much smaller
> niche.  Playing games to
> keep a pool of JVMs with per-user-application
> in-memory state makes sense.
> This is almost certainly going to translate to
> greater trouble and
> complexity for the hosting service.  More trouble
> means a higher priced
> service offered less often.
> 
> If your aim to make Java ubiquitous (which I believe
> possible) then you want
> to target the first case.
> 
> For low-traffic websites the probability of a GC
> during the process of a
> single request is low.  Also - though I can't say
> I've looked at the latest
> GC implementations in detail, the trend (starting
> with generational GC) in
> algorithms was to not move long-lived stuff around. 
> Taken together, it is
> reasonable to assume that GC is not going to have
> much (or any) impact.
> 
> This is aiming at the niche where PHP is popular - a
> rather large niche.
> 
> What you are looking for is the simplest thing that
> can possibly work.  You
> don't need JVM enhancements.  You don't need to add
> complexity in terms of
> managing pools (always fun).  You don't need to
> worry about leaky
> abstractions.  Odds are you end up with something
> simple and dead reliable
> for a hosting service to deploy.

A hosting service I use has a good scheme with using
multiple workers.  Each Tomcat is it's own instance,
and points to the domain folder where we have the
common files and places for
classes...shared...common....the config files.  They
then have rules we have to follow as far as
developing, or they'll let you know you need to change
something....same would happen for PHP...some page
using all the processor.  But, other than that, we
have our own directory, our own process for the JVM,
and we have ssh shell access to the things we need,
but overall nothing that could not be handled through
a web interface.  It works out really well, and we
have several domains we support on it.  Doesn't seem
any more difficult than anything I've done with PHP
other than the classes and folder and things and every
now and then restarting the TC instance.

Wade

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


Mime
View raw message