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.

Re:Throw it in jail

[bloo9298]

I don't see why different security managers would be necessary. What's needed is to give different rights to each thread, and JAAS allows you to do that.

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.

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.

my thoughts on java

[sevinkey]

Got into Java because of applets... fun to make a website with a little custom control in it. And the language was a nice improvement over C++ since you don't have to manage your memory. There's a lot of stupidness in the language, but it wasn't too bad.

And development overall in a real-world environment wasn't bad at all. In face I've written in Windows and deployed on Linux for multiple projects now.

However, with Java client apps it's write-once, debug-everywhere, since every VM has its quirks you have to troubleshoot, and suddenly I have several versions of my software to troubleshoot (last time I did that was circa 99, so maybe it's better now)

My last java project was a system of servlets for Tomcat which were needed to be up 24/7. The thing works, but the memory leaks were terrible, even making sure I set everything to null after using it, it was a memory bleeding dog.

My current job uses primarily C# on Windows server, and I'm much more impressed with .Net than java, despite being biased against Microsoft for the most part. The language features are much more clean, like my favorite:
foreach (SomeObject i in SomeCollection)
but there's a ton of language features that I don't want to get into here.

It's the stability and deployment that really got me. I can just compile my code to a DLL (and a couple of stub .asmx files) and throw it up on a webserver in the /bin folder, and I can have me a webservice, or a simple way to access compiled code from a script.

I still have to reboot windows 2003, but that's just because I keep my patches up-to-date. If I neglect to patch a server, it would stay up longer than the Java boxes. And this stuff runs much faster... almost as fast a C. Sounds absolutely nuts, but it's true.

Nothing new here

[IHateSlashDot]

I read the article hoping that it would have some useful info in it but came away extremely disappointed. Wow! A process based dispatch model. How novel. You mean crashing a process doesn't bring down the whole application? Let me think. Oh yeah. I remember learning something about that in the 70s. Pretty new concept. Come on now. The whole basis for this model is flawed. It uses multiple processes and then slips in the fact that it uses shared memory to communicate between the processes. This makes the whole model practically useless in any real world scenario. I've built systems that handle many ten of millions of users. Production systems mind you (you know, people actually pay money to use them and rely on them. They are still running today happily processing hundreds of millions of requests per day. Those were all multithreaded servers and have an average downtime rate of just a handful of minutes per year. (By contract they are only allowed only an hour of downtime per year including upgrades). Writing robust servers just requires some basic skill, not a new paradigm (or in this case an archaic paradigm).

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.