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: local policy)
Mime-Version: 1.0 (Apple Message framework v746.3)
In-Reply-To: <327858f40604061448n7bfd5f54o4abaddec6b31795b@mail.gmail.com>
References: <443521E7.5010609@apache.org>
 <7e91ba7e0604060915w24400d6dv4194cc92f4980b02@mail.gmail.com>
 <20060406171524.GD22221@easy.in-chemnitz.de>
 <7e91ba7e0604061020w5e1e274fu80b27f3f06b3fe83@mail.gmail.com>
 <327858f40604061140h3eed3acbn12431a413e0a8530@mail.gmail.com>
 <7e91ba7e0604061220s59d13187x3a051ddf202b443d@mail.gmail.com>
 <327858f40604061448n7bfd5f54o4abaddec6b31795b@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6DCD94FF-F149-442A-99ED-A3C191428187@objektpark.de>
Content-Transfer-Encoding: 7bit
From: Peter Rossbach <pr@objektpark.de>
Subject: Re: Challenges for Java hosting
Date: Fri, 7 Apr 2006 08:03:21 +0200
To: "Tomcat Developers List" <dev@tomcat.apache.org>

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