tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Gomez" <henri.go...@gmail.com>
Subject Re: Challenges for Java hosting
Date Fri, 07 Apr 2006 11:16:13 GMT
Very interesting stuff

My german is too bad but from what I could see it seems a good candidate.

Could this works be ported back into ASF Tomcat 5.5.x ? Or better
included in ASF Tomcat ?

>2006/4/7, Peter Rossbach <pr@objektpark.de>:
> Hey,
>
> Java/JSP and Tomcat for german hoster is a very bad story.  For two
> year we
> start a tomcat 5.0 based spezial tomcat distibution for hosting. The
> Centaurus Platform
> has show that effectiv hosting is possible. Problem is to find hoster
> that use that package.
> Look at http://centaurus.sourceforge.net/ and see that we have create
> a very cool tomcat bundle.
>
> Centaurus features:
>
> Used a patched tomcat 5.0.27
> full graphical and console installer package for LINUX/Windows
>         You can have multiple installation profiles
> Very nice html admin/manager console for one instance
> Loading new Security Policy on demand without downtime
>         every webapp can register there own policy part (admin can control
> this integration with rules)
> Integrate new host from templates without downtime
> Native Iintegration at os services with Java Service Wrapper
> Plugin concept for people to extends tomcat core functionality
> use of Mx4J Http adaptor with authorisation for remote control.
>
> At cvs head exist a not final tomcat 5.5 version.
>
> Regards
> Peter
> - Documentation only exist in german language.
>
>
>
> Am 06.04.2006 um 23:48 schrieb Leon Rosenberg:
>
> > On 4/6/06, Preston L. Bannister <preston@bannister.us> wrote:
> >> Define "lightweight". :)
> >
> > only the basics you need for a webapp. no admin/manager, no
> > clustering, no gadgets.
> > To explain it:
> > Besides large portals with own server farms and millions of hits, I
> > often have small customers which get a dynamical website with some cms
> > etc. The problem I had and still have, is that typical hosting
> > providers (at least in germany) don't offer any support for java
> > webapps, best you can get is support for jsps only which sucks. This
> > is ugly, since the customer pays money for the webapp and asks me
> > afterwards, why should he rent a complete server to host it. Therefore
> > I started to rent servers myself, and re-rent it to the customer. The
> > customer gets the complete package, mail, backup, ftp/ssh access and
> > the webapp. To ensure this, each server has an apache running with two
> > jsp container instances on it, one for production, one for testing
> > versions. The customer pays less than he would pay for "professional"
> > hosting, and I can refinance the server with 3-4 customers. However,
> > having all test-webapps in one server, and needing to restart it from
> > time to time isn't really cool. I'd prefer to give each customer two
> > instances, which consumes low resources, maybe even multiple tomcat
> > instances in one jvm (is that possible?), and keep them independent
> > from each other. Therefore lightweight. And therefore pre-configured
> > :-)
> >
> > regards
> > Leon
> >
> >>
> >> If we are talking about a small number of users, with high average
> >> utilization, this might be a good solution.  In fact this is
> >> similar in
> >> resource usage to the virtual hosting (i.e. Xen) solutions.
> >>
> >> For more typical usage, the number of users is large, and the average
> >> utilization is low.  In this case one (very rarely used) JVM per
> >> user is
> >> somewhat expensive.
> >>
> >> Note you could reduce the expense with the same approach of using
> >> a fork()
> >> of a single image, expecting copy-on-write to radically reduce the
> >> real
> >> memory use (virtual memory use would be larger).
> >>
> >> Depends on what target you are trying to hit.  The hosting world
> >> (by numbers
> >> of users) is dominated by very low usage sites.  Is this a goal for
> >> Java/Tomcat hosting?  If you can beat PHP in CGI mode *both* in
> >> performance
> >> and in resource usage, then you have a pretty compelling
> >> solution.  If you
> >> are fatter or slower - this is going to disinterest a lot of hosting
> >> providers.
> >>
> >> Note that this notion is pretty much a non-starter if Linux does
> >> not do
> >> copy-on-write with fork().  This was a big deal back in the late
> >> 1980's (big
> >> Lisp apps forking "vi").  Don't know if this made it's way into
> >> Linux.  I'm
> >> pretty sure copy-on-write in fork() was in SunOS, but I don't know
> >> about
> >> Solaris.
> >>
> >>
> >> On 4/6/06, Leon Rosenberg <rosenberg.leon@googlemail.com> wrote:
> >>>
> >>> isn't it easier to give each user a pre-configured lightweight
> >>> but own
> >>> tomcat?
> >>>
> >>> leon
> >>>
> >>> On 4/6/06, Preston L. Bannister <preston@bannister.us> wrote:
> >>>> Well, that is one definition of "real applications".   There are
> >>>> other
> >>>> definitions.  :)
> >>>>
> >>>>
> >>>> On 4/6/06, Tino Schwarze <tino.schwarze@tisc.de> wrote:
> >>>>>
> >>>>> On Thu, Apr 06, 2006 at 09:15:17AM -0700, Preston L. Bannister
> >>>>> wrote:
> >>>>>
> >>>>>> You have to consider how (or if) to allow for long-running
> >>> background
> >>>>>> threads.  Successive requests for the same user will not use
> >>>>>> the JVM
> >>>>>> (whether this counts as an advantage or disadvantage is
> >>> debatable).  The
> >>>>> JVM
> >>>>>> isn't going to be optimizing code.
> >>>>>
> >>>>> The point of using an application server (instead of e.g. PHP)
> >>>>> is that
> >>>>> it maintains state on the server. You lose this by using fork
> >>>>> (). So
> >>> it's
> >>>>> not going to work at all for real applications since your
> >>>>> application
> >>>>> "returns" to it's previous state after every request.
> >>>>>
> >>>>> Bye, Tino.
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> ---
> >>>>> 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
> >>>
> >>>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
>
>

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


Mime
View raw message