JVM restarts/availability JSRs

I made a comment in my JVM restart post about some JSRs that address server restarts. Here are the JSRs and how I see them solving some of the problems.

121: Application Isolation API

This JSR addresses the need to have mini-JVMs inside a single JVM that are completely isolated from each other. They can be stopped, started, restarted, etc without impacting anything else running inside the overall JVM. This reduces the ramp up time considerably and is similar to how some VMs manage processes rather than managing entire VMs. This one actually completed last year. I’m very interested to see if it gets rolled into things because it could be extremely powerful.

277 and 294: Java Module APIs

This is similar to OSGi support that was approved in JSR 291, however it makes modifications to the JVM, which aren’t really addressed in 291 (from what I know, which is minimal). This JSR allows more freedom to control class-loading and management of classes within boxed contexts. It probably does not address threading issues related to mis-behaving classes inside a context, but together with JSR 121, this would be a excellent solution. Let’s hope Sun has the vision to see this as well.

284: Management APIs

This one comes from the folks at Google and addresses utilization and management of processing within a JVM. It specifically addresses the need to terminate mis-behaving processes within the JVM.

291: OSGi

This one seemed like it was marshaled through the JCP just to battle 277 and 294. I think OSGi is great, but it doesn’t address many of the JVM level problems in very large, high availability applications. It really only addresses services and how they are separate but accessible. I’d much rather see 277 and 294 fully realize what the JVM should have in terms of modularization and separation of executing. If we could see truly separate execution spaces within a JVM that strongly define their public and private interfaces, we could gain a lot of stability without requiring what I believe to be dangerous restarts.

3 thoughts on “JVM restarts/availability JSRs”

  1. Great post Brian and I will read more into these. Sounds interesting and hopefully its not all to good to be true.

    Like

    Reply

  2. JSR 291 wasn’t marshaled through to battle 277 and 294. It came before 294 (hence the number) and indeed, was an extension of one of the earlier ones (232). So both 277 and 294 were created *after* OSGi was already around. 291 just formalised version 4.1 of the spec under a JSR.

    Also, OSGi doesn’t just address services. It addresses modules, security and lifecycle, all on top of the existing class loader architecture/structure. Services are part of that process, but it’s a superset of the functionality of 277 and 294 as well as other parts.

    As for the distributed applications or mini apps; there’s nothing to stop that happening in an OSGi platform, but that’s not what it sets out to achieve. In addition, there’s no reason that the services need to be local to one VM as distributed frameworks like R-OSGi and Newton and Infiniflow show.

    In terms of restarts, OSGi provides exactly the same mechanism as Tomcat does for webapps; you can stop, restart, install and uninstall on the fly. The fact that you’re always in one VM means that there are some situations (e.g. badly behaved native code) that can take the process down as well as memory management; but that’s a deployment choice that you’ve got. There’s no reason that that can’t exist using the same framework as you do for modules.

    Like

    Reply

  3. Alex,

    Thanks for the comments. I think it seemed like the OSGi JSRs have been approved rather quickly. As for the competing with the other JSRs, it does indeed do that specifically because much of the community believes OSGi superior. I don’t get into that debate.

    Furthermore, 277 and 294 were formalized declarations of Sun’s intent to solve the problems. Gilad and others will probably tell you they came up with the ideas years if not a decade ago. I still feel as though this particular JSR was specifically put through and rather quickly at that because Sun was looking to formalize some of the more academic discussion it had been having into JSRs. Whether or not that is accurate is left to the historians. Just seemed that way.

    As for OSGI, I understand the nature of OSGi and how it solves the modules, lifecycle and dependencies as well as distribution. My point was that there is more to making large distributed applications than those concerns. You have availability, provisioning and other concerns as well. OSGi can’t solve these problems until the JVM does because it isn’t necessarily allowed to modify the JVM semantics or the runtime. The different with the Sun JSRs like 277 and 294 is that they more than likely will modify the JVM because Sun is driving them. Therefore, they have the potential to create a truly modular system, which undoubtedly OSGi will take advantage of.

    Like

    Reply

Leave a comment