--- "Preston L. Bannister" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
