Quest For "Unbreakable Java" Unites ABAP & Java

jg21 writes "Writing an article about "A Java Server That Never Goes Down" is pure hubris, but a German developer who says he's been "eating, sleeping, and drinking Java" for 8 years doesn't seem to care and his article brings to light the aspects of VM we rarely think of as he introduces "user isolation" and tells about some interesting work SAP in Germany is doing in that area, merging the Java and the ABAP worlds."

Comments

Throw it in jail

[SIGALRM]

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.

The perfect solution...

[CodeWanker]

for making ANYTHING into "Never Goes Down" is a marriage. Dammit.

Re:The perfect solution...

[grub]

Scientists have discovered a food that takes away a woman's sex drive. Wedding cake.

So basically...

[bill_mcgonigle]

• run fewer users per VM
• run more VM's
• use "shared closures" (fast oo serialization) to get idle users out of the VM's and,
• use Apple's Shared Classes to reduce memory footprint (needs java 1.5)

This sound like it's at least as much about fast and effective recovery on crash as it is crash prevention. Which to a web user is the same thing.

All VM's have bugs so crash-proof is a tall order.

Re:So basically...

[/ASCII]

Yeah, what the author meant with crash proof is that when a crash happens, only the user whos request the application was processing gets an error, and because of the shared closures, the crash may not even be that bad for the one user.

This scenario breaks down when: there is a bug in the shared classes or the shared closures implementation, when there is a bug causing corrupt data to be written to the shared closuers, when one or more processes trigger a bug which cause them to hog a scarce system resource like memory or CPU time, when a OS bug or a hardware failiure is encountered, etc, etc, etc.

The ideas outlied are sound for an extremely high availability system, but they are not enough to make the clain unbreakable.

Some improvements to the outlined strategy: Use a validator to check that the information written to the shared closures is always correct. Mirror the shared closures to another computer. Have a backup computer which automatically picks up if the first one falls down.

Re:ABAP?

[KenSeymour]

I have heard of it jokingly referred to as "German COBOL."

If you enter the world of SAP, be prepared for a thousand acronyms.

Crash-only software

[Earlybird]

Ladies and germs, I give you crash-only software.

• Crash-only programs crash safely and recover quickly. There is only one way to stop such software -- by crashing it -- and only one way to bring it up -- by initiating recovery. Crash-only systems are built from crash-only components, and the use of transparent component-level retries hides intra-system component crashes from end users. In this paper we advocate a crash-only design for Internet systems, showing that it can lead to more reliable, predictable code and faster, more effective recovery. We present ideas on how to build such crash-only Internet services, taking successful techniques to their logical extreme.

Re:Step on those Beans!

[OwnedByTwoCats]

I have programmed professionally in at least 8 languages, including C, C++, perl, and PL-SQL, and have worked in several others in academic or limited settings.

I have been doing Java since 2000, coming from C++.

Java isn't bad. It is complete; it has a threading model with appropriate concurrency controls. It isn't that different from other imperitive object-oriented languages. It has automatic garbage collection. After startup, on our applications, the performance difference with C++ is negligible, and what we save with automatic GC is quite bankable.

My employer used two strengths of Java to justify the move from C++: platform independence, and garbage collection.

I don't know what jbich wants to see in a language.

Re:Java and memory leaks and slowness

[Decaff]

Sure, the java developers will make various excuses, but I loathe every Java app I have ever run.

Every one? I doubt that very much. If you have used commercial websites you are sure to have used a significant number of websites powered by Java application servers (check the number of .jsp extensions). You 'loathe' all those websites?

This is the norm, not the exception. It is not flamebait.

Generally, they are memory leaking pig apps.

Eclipse, Tomcat, JBoss, ant and all such widely used and successful applications are all memory leaking pigs? This would be surprise to the developers of these applications who have honed and tuned them over the years, and the thousands of contented users.

How about the thousands of Java games running on mobile devices in a few MB? Are they memory leaking pigs too?

Sure, there are memory leaking pig Java apps. There are memory leaking pig X apps where X is the language of your choice.

Check out the Isolation JSR

[AdamInParadise]

There is already a JSR for that would define a standard for Jail-like compartments in a single JVM process:
JSR 121: Application Isolation API Specification

Problem is, this JSR is going nowhere. There are some big corps onboard, but no one seem's interested in defining a common API. Sun's management is clearly not interested (more precisely, "Sun's managment has decided not to commit any resources to this project in the short term.") So there are lots of research papers, prototypes and Master's thesis, which are all very interesting, but no working implementation that everyone can use.

That's really sucks because with an implementation of this JSR, the JVM could get a lot more OS-like. Too bad.