Jason,
Thanks for the feedback with regard to JVMs.
We agree with you -- given the state of the art in JVM
implementations, it seems premature to require multi-tenant
single JVM PaaS. As noted in the document, it was not our
intent to mandate this.
regards,
-Linda
On 6/2/2011 12:02 PM, Jason T. Greene wrote:
> On 6/2/11 12:47 PM, Antonio Goncalves wrote:
>
> -snip-
>
>> Correct me if I'm wrong, but latelly I've been earing a lot about
>> multi-tenant. It looks to me that the world is moving the other way now.
>> Application servers, databases... tend to be lighter and lighter in
>> terms of resources. So why bother having multi-tenancy ? Just
>> instanciate several servers or DBs and each instance only hosts one
>> application.
>
> This is essentially my thoughts on multi-tenant single JVM PAAS, but also for a number of other reasons:
>
> 1. Security - Without major changes to the SE JVMs, it will be nearly impossible to prevent one hostile app from having
> the ability to interfere with another. The JVM security manager isnt really a good fit for a multi-tenant environment,
> at a minimum it would be very difficult to manager. Also there is really no such thing as a heap safe guard, so it's
> possible that one tenant could somehow gain access to another's memory.
> 2. Robustness - One bad/broken jar can easily crash the entire server, since there is no limit to the amount of cpu and
> memory it can use.
> 3. Resource tracking fairness - With the state of the current SE JVMs, it's not really possible to bill usage fairly.
> You could track the number of requests, possible connection pool usage, and invocation counts, but these are not
> necessarily a fair representation of hardware resource cost.
> 4. Complexity - Trying to get all of the EE services to "partially" adress the above problems (the best we can hope for
> given the state of SE) will lead major changes to probably every EE API we have, and will likely make all of the
> implementations far more complex.
>
> All of these issues are pretty much solved by having multiple processes which can then take advantage of the underlying
> OS that has been solving these problems for decades. Having each of those processes be a JVM works great today, however,
> it does waste memory since there is no class/data sharing*,**.
>
> It's a shame that the work behind MVM didn't continue, had it been further along, it might have fit our needs.
>
> If the goal, however, is to make it easier to build SAAS applications that actually sounds achievable.
>
> [*] I realize openjdk has a class sharing feature but it is very limited (client only, inteded for bootclasspath only),
> and requires that you save memory dumps (so not practical).
>
> [**] Certain non-certified JVMs (Dalvik), and other research projects have implemented multi process class file sharing.
>