tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach ...@objektpark.de>
Subject Re: Challenges for Java hosting
Date Fri, 07 Apr 2006 12:00:39 GMT
Hey Henri,

no problem. I have talk with Thorsten Kamann the other author and
we are happy to contribute the code. Then we can translate the  
complete docs
and finish the tomcat 5.5 integration.

Regards
Peter & Thorsten



Am 07.04.2006 um 13:16 schrieb Henri Gomez:

> 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
>
>


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


Mime
View raw message