Slashdot Mirror
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."
Sigs cause cancer.
I think the first thing he should do is install Solaris 10 with DTrace and debug with a passion. DTrace will reveal all those nasty problem areas making it easier to fix.
>>In contrast, Java follows the all-in-one-VM >>paradigm: everything is processed inside one virtual machine running in one operating system process. Well, recently Sun VM and Linux kernel developers have done a lot to improve threading support in kernel and the combination of SUN VM 1.4.1 and kernel 2.6 scales very good.
MySQL Error 1040: Can't return sig, Too many connections!
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
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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:
armstrong_thesis.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,
--
Mickaël Rémond
http://www.erlang-projects.org/
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.
.Net than java, despite being biased against Microsoft for the most part. The language features are much more clean, like my favorite:
.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.
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
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
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.
My experience has nothing to do with user isolation. I as a network/systems engineer have spent more time troubleshooting JVM than any other part of the ecommerce eco-systems I support.
Java has the following problems:
1. no one person really knows all of the Internals. I have seen the crap feedback from both the Tomcat mailing lists as well as commercial support for JRun. We paid $2500 a day for a JRUN expert who was a dork. I found out more piling through truss/strace results then they found.
2. Garbage collection: WTF? Can no one get this right? I love watching java buckle becuase of crap you have to go to to 'tune' it.
3. Load testing NEVER reflects how your app will perform in the wild. I have been on at least twenty commerical load tests with the major vendors. Every time we end up with yet more obscure issues that show their teeth.
Remember, the more complex your environment, the less likely you'll be able to support it. If the Java people were smart, they would build a better instrumented virtual environment. Don't get me wrong. There are good profiling tools.
Java is just anything but stable or predictable.
Current JavaVM implementations are all designed to run as one or multiple user processes on top of the OS. Not surprisingly, such implementations don't duplicate abstractions already provided by underlying platform - like virtual memory or persistent filesystem permissions.
However, if a VM was running directly on top of the kernel, it could implement these features more efficiently than what must be done for native code and would need little hardware support from the CPU. For example, kernel and user code can pass objects to each other without making a copy or any security concerns.
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).
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.
Nobox: Only simple products.
There used to be a company called Tandem (bought out by Compaq, then HP) that produced a computer system with no single point of failure.
/. land using Tandem's?
You could write programs in a language called TAL (Transaction Application Language) which provided the ability to checkpoint. Doing this, your program could initialte a primary and backup process. The backup process would run on a different CPU. By checkpointing, the application could keep the primary and backup process in sync. If, for some reason, the primary process were to fail, then the backup would take over.
Tandem's were heavly used in the financial industry. Unfortunatly, Compaq (and HP) seemed to down-play (or didn't understand) the true potential for these systems.
These computers a still being used, but are so under-sold for the potential they have.
Anyone out there in
Use the same code for the start-up sequence of your program as you do for crash recovery - treat them the same. Fewer lines of code leads to less chance of an error. That's all.
It is ironic that Apache 2.x is going to a multi-threaded model from the safer fork-based model. Isolation and 30 years of OS research be damned.
It is ironic that Linux is going to the monolithic kernel model from the safer microkernel-based model. Modularity and 30 years of OS research be damned.
Just because people have found that a hammer is the most generalized tool does not make the world full of nails.
- I don't need to go outside, my CRT tan'll do me just fine.
ant is a really simple cmd-line process, I can't see how it leaking memory would be a big deal.
It's certainly not simple! It is used for large-scale production builds and scripting. It's also used as a plug-in, often for repeated and automated tasks within other programs, where leaks would definitely show. (Actually, there have been *past* memory leaks in Ant, which caused problems in these situations).
However, if you sincerely think that Eclipse doesn't leak memory like a sieve, then I claim that you don't do your day-to-day in it.
I don't (I use NetBeans), but I know many who do, and without problems. Eclipse is a very, very widely used product. It's not used just for Java, but also for C++ and other languages. It is also the foundation for many custom applications, and is used for long periods. Eclipse is a well-respected and very well debugged application.
When there have been reports of memory leaks in Eclipse, these have been due to faulty plug-ins.
It is fair to say that Eclipse has a high start-up memory requirement, but I see no evidence or reports that it has any significant memory leaks.
I fully agree that forking is a workaround, and it's better not to have the app crash, but better still is both forking and having the app not crash. It's like having computers in a LAN secure from each other - yes, the firewall should work, but it's better not to depend on that.