Welcome!

Linux Authors: Liz McMillan, Frank Huerta, Elizabeth White, Pat Romanski, Sandi Mappic

Related Topics: Java, Linux

Java: Article

Unbreakable Java: A Java Server That Never Goes Down

Some developers may not believe that there is a fundamental problem with Java's robustness

Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture. Some may even remember the White Star Line promising that their ocean liner Titanic was unsinkable; an iceberg in the North Atlantic proved them wrong and demonstrated that there is no such thing as an unsinkable ship. Is it really possible to build a Java application server that never goes down?

It's All About Isolation
The key to understanding robust Java is isolation, isolation, and isolation. Robust applications, especially robust application servers, require a high level of isolation between users. It's not acceptable that an error occurring while processing one user's request may affect all users connected to the system. The complexity of software systems makes it impossible to develop software that is completely free of errors, so errors will always happen. Only isolation can provide real robustness by limiting the impact of errors.

The design of the Java Virtual Machine ignores the painful lessons operating system vendors have learned in the past 40 years. The concepts of processes, virtual memory management, and different protection modes for kernel and user code can be found in all modern operating systems. They focus on the question of isolation and therefore robustness: an application with errors cannot affect the other applications running in the system.

In contrast, Java follows the all-in-one-VM paradigm: everything is processed inside one virtual machine running in one operating system process. Inside the VM, parallelism is implemented using threads with no separation regarding memory or other resources. In this respect Java has not changed since its invention in the early nineties. The fact that Java was originally invented as a programming language for embedded devices may explain this approach.

There Is No Isolation in Java
Java does not have a problem with isolation; there is virtually no isolation at all. Java tries to avoid dangerous concepts like manual memory management (this is like taking some of the icebergs out of the ocean) and it can't be denied that it provides at least some isolation concepts, but a Java Virtual Machine is still easy to break. For example, class loaders make it possible to partition an application into parts that cannot see and access each other directly, which provides some isolation. Going back to our nautical example from the very beginning, this is exactly what was supposed to make the Titanic unsinkable: the ship consisted of separate compartments and water pouring into the ship was supposed to be stopped by the bulkheads separating the compartments - unfortunately the iceberg was too big and way too many compartments filled up with water. In terms less familiar to the sailor but more familiar to the developer: all the fancy isolation built with class loaders does not help if you have memory leaks, threads running amok, or even bugs in the VM.

SAP's Approach to Isolation
SAP's ABAP application server - the powerhouse underlying enterprise-scale R/3 business solutions - was based on the concept of process isolation from the very beginning. It consists of a dispatcher and a bunch of work processes handling the requests. The work processes are normal operating system (OS) processes and the OS provides a high level of isolation for free. The dispatcher guarantees that in one moment exactly one user request is processed by each work process. In case of a crash, only the user currently processed in the crashing process is affected. All other users continue their work and the operating system takes care of the resource cleanup.

To overstress the ocean liner example a little: the ship is not split up into compartments but every passenger gets its own ship (a separated process) with some guide (the dispatcher) taking care that all sail the same course and don't hit each other. Using this architecture, an iceberg (a severe error) may still hit one of the ships but it will affect only one passenger.

One passenger per ship sounds weird. Giving each passenger his or her own private dining room and engines seems to be a huge waste of resources. Two things can be done to handle the resource issue. First, it is possible to let the passengers share the ship with some others without meeting them at any time. Some invisible mechanism moves the sleeping passenger out of the ship, storing him or her somewhere outside and puts another active passenger into it, taking care that only one active passenger is in each ship at any moment. The second way to address the resource problem is to share as many resources as possible between the little ocean liners.

In the ABAP application server, the state of the user - often called user context - is not stored inside the process but in a shared memory area accessible to all work processes. This allows attaching the user context to a free work process when the next request arrives. Attaching user contexts is a very fast operation because no data is copied.

The ABAP virtual machine (yes, ABAP is executed on a virtual machine) was designed from the very beginning to store user contexts in shared memory. All infrastructure (the engines, the dining room) is written in C and able to deal with user contexts being moved between the work processes too.

User Isolation in Java
SAP's VM Container technology transfers the ABAP isolation concepts to the Java arena. The first step is to increase the number of virtual machines and therefore reduce the number of users handled by each VM. Having a hundred instead of a thousand users assigned to a VM makes a difference in case of a crash, but still affects too many users. Decreasing the number of affected users further without increasing the number of virtual machines requires some extra magic.

Normally less than 10 percent of the users connected to a system are actively sending requests; the others are thinking about their next action or typing in some data at the front end (thinking users). Keeping the user state (user session in Java terms) in a memory area outside the virtual machine allows reestablishing the sessions of all thinking users in case of a crash. This reduces the number of affected users in our example to only 10 or one percent of the thousand users (see Figure 1).

The technology used to keep the sessions outside the virtual machine is called Shared Closures (see sidebar for details). The session state of a user is saved to shared memory after his or her request was processed. This guarantees that the shared memory contains a backup of the session state of at least all thinking users and that the data is accessible to all virtual machines. In case of a crash, another virtual machine can copy the user state from shared memory to its local memory and continue processing the user's requests without the user even noticing.

Memory Diet for the VM
The drawback of the described approach is that you have more virtual machines, each of them eating up some memory. This requires extra measures to keep the memory footprint of the VMs low; they must be put on a diet. This problem is addressed by Shared Classes.

The memory consumed by Java classes can become quite large in real-world applications. Shared Classes is a technology built into the Java Virtual Machine that shares the runtime representation of the classes, including the native code generated by the JIT compiler, across all virtual machines on one physical box. The classes exist only once in memory, reducing the overall memory consumption of the VMs.

In addition to the session backup explained earlier, Shared Closures can be utilized to reduce the memory footprint of a virtual machine. Configuration data and other application or server-wide information can be shared between VMs. Mapping the data from shared memory will provide access to it without consuming memory in each VM.

Don't Forget Supportability
Providing a high level of robustness through isolation is half the battle, but robustness without supportability is not sufficient. If something goes wrong in the application server, support personnel must be able to track down and resolve the problem easily.

The virtual machine used in the VM Container has been improved regarding supportability. One of the most interesting features is the ability to switch dynamically into debugging mode and vice versa. The switch can be initiated from the inside (using Java code) or from the outside (using administrative tools). Normally, Java application servers need dedicated debugging nodes because the Java virtual machine must be switched into debugging mode at start-up. Using the VM Container, debugging is possible at any time, even in productive systems. A sophisticated rights management restricts which parts of an application or server a developer can debug. This prevents misuse of debugging capabilities in production environments.

Besides debugging, the monitoring capabilities of the VM can be used to obtain granular statistics about the running server. The monitoring is built in a way that does not affect the performance of the running application until explicitly switched on.

Summary
The VM Container technology offers improved robustness through isolation. The isolation is provided by reducing the number of users handled in parallel in one virtual machine. Saving the user's session state in a shared memory area improves the failover characteristics of the application server. Advanced sharing technology helps to reduce the memory footprint of the virtual machines. Improved monitoring and debugging support makes it easy to detect and fix problems at runtime.

References

  • Tanenbaum, A. (2001). Modern Operating Systems (2nd Edition). Prentice Hall.
  • Byous, J. "Java Technology: the Early Years": http://java.sun.com/features/1998/05/birthday.html
  • SAP Web Application Server Components: http://help.sap.com
  • Kuck, N., et.al "SAP VM Container: Using Process Attachable Virtual Machines." Java Virtual Machine Research and Technology Symposium, San Francisco, August 2002.
  • J2ME CDC HotSpot Implementation Overview: http://java.sun.com/products/cdc-hi/overview.html

    SIDEBAR

    Why Is It Called VM Container?
    The technology behind the Always On Java initiative is called VM Container and the name suggests that there is something like a virtual machine and a container housing it. Right!

    The name is based on the fact that the ABAP application server already contains a lot of interesting and battle-tested services that can be reused to build a robust Java server. The components were reshaped and now provide the container that hosts the Java Virtual Machine. The VM was licensed by SAP and modified to seamlessly integrate into the container and to provide additional features like sharing technologies and enhanced supportability.

    SIDEBAR 2

    Shared Closures
    One of the key features of the VM Container technology is the Shared Closures API. It provides a semantic similar to serialization but with a new and very fast implementation. This technology enables middleware developers to share Java objects between virtual machines running on the same computer. For the application developer, high-level APIs based on Shared Closures are available, for example, providing caching or configuration management.

    The name Shared Closures already implies that not only single objects but the whole transitive closure of objects reachable from one root object is shared. This behavior is like Java serialization except the operations are faster and a special mode of operation, called mapping, is supported.

    A Shared Closure is created or updated by providing a reference to the root of an object tree to the API. The content of the tree is copied to the shared memory while the objects inside the virtual machine remain unchanged.

    An exiting Shared Closure can be used in two different ways:

    • Copy: The objects in the Shared Closure are copied to the heap of another VM. The objects become normal local objects and can be modified (see Figure 2).
    • Map: The objects in the Shared Closure are not copied but only mapped into the address space of the virtual machine (see Figure 3). This operation is very fast in comparison to copy, because no data is transferred. Especially no extra memory is consumed for the mapped objects. The objects mapped into the address space are read-only.
    An implicit versioning mechanism takes care of the fact that some VMs may have mapped a version of a Shared Closure when another VM wants to publish an update. All previously mapped closures remain unchanged, whereas new map requests provide the new version. A distributed garbage collector removes all old versions that are no longer used.

    Mapping objects from Shared Closures is the best mode of operation for caches and configuration data that rarely changes. Copying the data of a Shared Closure is used to implement session failover or messaging mechanisms.

    SIDEBAR 3

    A Peek into the Labs: Full User Isolation
    In the development labs at SAP, work is in progress on a solution that goes beyond the approach described in this article: it merges the Java and the ABAP world. Both virtual machines run together in one work process and full user isolation is provided for ABAP and Java programs: in one Java Virtual Machine, only one user request is processed at a time.

    A new paradigm was implemented called Process Attachable Virtual Machines. It decouples the VM from the process and makes it a lightweight memory image that can be moved between processes. Using VM templates, new virtual machines for the pool can be created with nearly no runtime effort. VM templates are available that contain a fully bootstrapped virtual machine, including the application server and the deployed applications. Using VM templates offers a way to create new virtual machines for the pool instantaneously.

    The number of work processes can be configured in a way that guarantees that the working set of all processes fits into the machine's main memory (although the memory is usually too small to hold all VMs at the same time). The number of virtual machines in the pool is normally higher, to take into account situations where a virtual machine does blocking I/O or other operations that don't use the CPU. In those cases, the VM is temporarily detached to free the process for new requests.

    The operating system schedules preemptively between the processes but the virtual machines are moved in and out of the processes on a semantic base (semantic scheduling). This dramatically reduces the problem of thrashing because the working set is only changed after a user request is finished. Controlling the semantic scheduling is easy because the VMs are not operating system processes but attached to processes and detached on demand.

    The session state of the users is kept in a special shared memory area accessed via the Shared Closures technology. The VM and the user session are separated after each request. Therefore the VMs can be used independently of the user sessions; there are no sessions sticky to a special VM except in the moment when a request is processed.

    SIDEBAR 4

    Virtual Machine
    The virtual machine used for the VM Container is based on a Sun CDC/Hotspot VM. It was originally designed for embedded devices, making it very lightweight and easy to port to new platforms. Having a VM with a low memory footprint is important because the isolation approach of the VM Container will increase the number of parallel running VMs. You may imagine the VM Container as a cluster of Palm Pilots if you like.

  • More Stories By Thomas Smits

    Thomas Smits has a degree in business administration and economics with a focus on business informationtechnology. His first contact with Java was 8 years ago. Since then, he's been eating, sleeping, and drinking Java. He did development projects for German Rail (Die Bahn), Brenntag, and other companies. Thomas authored a course on Java Web technology for Sun Microsystems and has done a lot of customer-specific training on Java. Since 2002 he is a development architect in the SAP NetWeaver team.

    Comments (18) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    news desk 10/31/05 08:23:49 AM EST

    Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture.

    SYS-CON Germany News Desk 10/30/05 05:12:47 PM EST

    Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture.

    SYS-CON Canada News Desk 10/30/05 02:48:26 PM EST

    Unbreakable Java: A Java Server That Never Goes Down. Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture.

    Eclipse News Desk 10/29/05 05:39:58 PM EDT

    Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture.

    JDJ News Desk 10/29/05 05:23:46 PM EDT

    Unbreakable Java: A Java Server That Never Goes Down. Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture.

    Alejandro Ramallo 01/16/05 03:11:27 PM EST

    Great article.But...much of what your are doing can be already be done using non-proprietary technologies. I am talking about JINI and in particular about the JavaSpaces Service. Dispatching a process per request has already been proven using these technologies. For example you can build a Virtual Compute Server that can handle all your requests in different VMs (several companies have implemented this, we are one of them). Plus you get the dynamism of the VCS (Grid Engine). Obviously JavaSpaces is the shared memory that enables this construct. I think the best approach to the future of Application Servers is in the nature of the Rio Project (http://rio.jini.org). I can imagine Sun implementing the future version of their App Server on top of Rio. Ahhh...Rio is OSS! and JINI is almost OSS!

    SIGALRM 01/04/05 04:18:07 PM EST

    ///Inside the VM, parallelism is implemented using threads with no separation regarding memory or other resources. In this respect Java has not changed since its invention in the early nineties///

    I agree that ABAP's dispatcher is an excellent model for per-process isolation. Going further in Java, I would suggest adding a portable root jail to the API. This could allow chroot to isolate and/or run the I/O of native subprocesses through a Java SecurityManager, using a user mode filesystem mechanism. In this way you could secure a Java language service... a handy way of adding a final wrapper to the security provided by the JVM.

    thasmudyan 01/04/05 02:02:14 PM EST

    The thing that bugs me about some Java developers is how they take those concepts like multithreading and separated execution and try to rebuild it painfully with a Java infrastructure, when the VM is probably not the best place to do this.

    For example, when the author talks about the ABAP's process model and how it should probably be rebuild with Java. The idea is basically: One process (or thread) per request, shared session data storage across requests - that sounds like the best place for a classic CGI environment to me. PHP would probably do a nice job, or Perl or anything.

    So if you want those features, why not build on top of Apache, maybe communicate with the client via XML webservices? CGI calls to script interpreters would pretty much provide anything you could possibly needed, while offering customizable degrees of separation *for free* right in the webserver. Why not? Why spend millions to build another bloated Java application server (that may or may not some day be able to support the same kind of featureset that webserver architectures already have)?

    codepunk 01/04/05 06:21:00 AM EST

    This is nothing more than a cleverly disguised pimping of SAP'S netweaver app server.

    First and foremost SAP I do not want to have to run your hacked up JVM. Is it a good idea, yea probably but implementing it is gonna be hard because of the closed nature of JVM.

    No sys admin and or programmer in his right mind wants to work with or support some third party JVM.

    All that being said what's up JBOSS developers? Is this a good idea? I most certainly trust your skill far and beyond anything these guys can produce.

    dotnetrocks 01/03/05 05:52:07 PM EST

    ///What's kind of funny is that the isolation so desired by the author is built in to .NET from the get go. They're called Application Domains, and they're used heavily in ASP.NET to isolate applications from one another, but have them remain inside a single OS process.///

    There's more to applications domans than just this.

    try .NET!! 01/03/05 04:49:30 PM EST

    What's kind of funny is that the isolation so desired by the author is built in to .NET from the get go. They're called Application Domains, and they're used heavily in ASP.NET to isolate applications from one another, but have them remain inside a single OS process.

    Mickaël Rémond 01/03/05 01:09:56 PM EST

    It was really fun reading this article as isolation as described in this article has been one of the founding principle of the Erlang VM. Erlang is a concurrency oriented langage created to support the development of robust scalable fault-tolerant applications.

    I strongly recommand reading Joe Armstrong thesis. This is very enligthning regarding this topic and this is real world feedback:

    http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

    Fortunately, Erlang has been designed from the ground-up for robustness. All feature of Erlang are designed to achieve the robustness goal (Concurrency model, functional programming, error handling, supervisor and worker mechanisms). This is precisely why it will be very difficul to achieve with Java, if even possible.
    I hope this helps,

    KenSeymour 01/03/05 11:55:44 AM EST

    I have heard ABAP jokingly referred to as "German COBOL."

    Hayo 01/03/05 09:24:02 AM EST

    The article may also be downloaded at the SAP Developer Network in a more readable version. (You might need to register a user for SDN!)

    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.doc...

    Mike 01/03/05 08:38:29 AM EST

    Great story

    dagfinn 01/01/05 05:17:49 PM EST

    This topic is also covered in some detail in my blog at SAP Developer network.
    https://weblogs.sdn.sap.com/pub/wlg/940

    Penguiin 12/31/04 09:14:48 AM EST

    "Unbreakable Java" is as reckless a claim as "Unbreakable Linux" - great article though, thanks.

    PV 12/30/04 12:54:07 PM EST

    Great article. This article brings to light the aspects of VM we rarely think of. I think a lot of the JVM shortcomings will be eliminated when java penetrates deeper into the Operating System to the point that JVM is an integral part of the OS.