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!
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.
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 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.