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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > >>> > >>> isn't it easier to give each user a pre-configured lightweight > >>> but own > >>> tomcat? > >>> > >>> leon > >>> > >>> On 4/6/06, Preston L. Bannister <[EMAIL PROTECTED]> wrote: > >>>> Well, that is one definition of "real applications". There are > >>>> other > >>>> definitions. :) > >>>> > >>>> > >>>> On 4/6/06, Tino Schwarze <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > >>>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> -------------------------------------------------------------------- > >>> - > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
