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.
for making ANYTHING into "Never Goes Down" is a marriage. Dammit.
"Wow. Now THAT'S a lot of angry Indians." - Lt. Col. George Armstrong Custer
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.
Looks like the JDJ link is already slow to respond, but there's a mirror here at MirrorDot for those who haven't already bookmarked the site from previous Slashdot comments. (No, I'm not at all affiliated with MirrorDot -- just sharing the love :).
>>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!
Isn't this what Oracle did with the Oracle virtual jvm that started in 8i? and that was a looooong time ago. Though having used SAP I can see why it would take them years to catch up with the rest of the world.
It is a programming language for changes in SAP ERP System.
I could change the world, but GOD won't give me the source code
R3
Stuff that matters: circuitbreakers, vacuum-cleaners coffee makers, calculators generators, matching salt+pepper shakers
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)
"eating, sleeping, and drinking Java" for 8 years
I'm getting the shakes even thinking about that.
I have heard of it jokingly referred to as "German COBOL."
If you enter the world of SAP, be prepared for a thousand acronyms.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
Ok the Ship analogy was good at first, but this is a little rediculous:
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.
If a process crashes then all memory that the process has access to is suspect. If that's all the jvm contexts then they're all suspect.
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/
I thought my girlfriend was the only thing that didn't go down.
Yay, I think you invented ISAPI.
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.
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.
Sure, the java developers will make various excuses, but I loathe every Java app I have ever run.
.jsp extensions). You 'loathe' all those websites?
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
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.
However, the standard Java VM does not provide any way for a supervisory process to limit two key resources: memory and CPU. The Thread.stop() call is useless against a malicious DOS attack via Threads with infinite loops since the attacker can simply provide a "finally" clause that perpetuates the loop. Thread.stop() is even deprecated in later version of Java. Furthermore, there is no way to limit the memory that malicious code can allocate via new (unless I missed something in recent versions). So crashing a JVM via malicious applets or servlets is trivial. This is acceptable for a web browser (just restart the JVM), but not so good for server side Java. Furthermore, infinite loops and data cancer (actual memory leaks where the memory is allocated but not referenced anywhere are impossible in pure Java) are common failure modes of honest but buggy software, so JVMs too often crash due to either CPU or memory starvation even when only trusted code is running.
The goal of the system described is to provide a way to limit CPU and Memory consumption by leveraging the process model provided by the OS. Furthermore, the hardware enforced user mode helps protect against JVM and JNI bugs that might otherwise break the Java machine model (and allow memory leaks/corruption or malicious native code execution). Having multiple layers of protection is always good.
I've been doing a lot of Java in the last few years, and I like it.
There are some warts. It uses a lot of memory, RMI should be transparent, the package setup is not very helpful, and iteration is still uglier than python, but in general most things are there for a reason, with an eye on large project development. This is where things make sense -- you can move, refactor, or whatever and once it compiles it probably runs.
Swing is a two-edged sword. It probably doesn't do exactly what you want out of the box, but you can beat it into working pretty closely to what you want.
And the cross-platform stuff really works.
It gets better if you heavily use the collection classes and the libraries.
-- ac at work
I used to code in C (7 years). I used to code in C++ (another 7 years).
I have used Perl and Python.
I prefer Java for the following reasons:
1) I like programming in an object oriented style.
2) C++ has lots of gotchas. My favorite is having to recompile client code for a class when the size of instances changes.
3) Java has a thriving job market. Smalltalk was to hard to get ahold of a widely used compiler (fork over a thousand dollars or more).
And then once you learned it, you had to move to the few towns in which there was a job.
4) You can write cross-platform code that uses serial ports, network sockets, GUI code, encryption and much more without doing #ifdef or automake or autoconf stuff.
You just write the code once, as they say.
5) I work on big programs that take a year to write. So the power of the language to help me organize things makes a big difference.
So Perl, in particular, is out!
C code gets hard (for me) to manage after about 15,000 lines.
I use an IDE written in Java all day and I do not think it is horribly slow. Emacs, of course, runs more quickly, but I have to remember a lot of strange key combinations to get anything done and it looks like crap.
I guess YMMV. Hate and loathe all you want. It leaves more work for me.
You are entitled to your opinion.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
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
Actually, it is really a fairly nice language to work with. Not perfect, but very tightly integrated into the workflow. If a user can do something in the system, a good bapper can re-create it with ABAP for other users. Fairly nice for business stuff.
;)
Like Cobol. Or AppleScript
-WS
An operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.
Maybe you're just not satisfying her. Is she having an orgasm (or more)? If not, try reading The Clitoral Truth with her - it describes and explains the complex anatomy/physiology of all the female genital stimulation receptors, and how to "work the API" ;). If she is having orgasms, but remains unsatisfied, she probably needs more than sex to be satisfied sexually - like maybe some wedding cake :). Though for women they need a full course meal, including a divorce settlement :(.
--
make install -not war
that's bPfaTA
How come when I talk to a company executive, they're implementing SAP.
Nobody ever seem to have implemented it.
The Kruger Dunning explains most post on
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.
If the memory leaks on someone else's system, it isn't my problem, is it?
There are very few types of memory leaks in Java, and they are very well understood and isolated. Compare that with C++ which has a greater propensity to leak memory than even c (since many c programmers use the stack instead of dynamic allocation wherever possible).
In Java, if you have a memory leak, you'll learn about it very quickly, and the memory error/stack-trace/profileability can usually quickly point you in the right direction (fixed-sized class memory, v.s. user-cached-and-not-released objects). In C++, for a sufficiently large app, good luck closing up the sieve.
Your pain of java means you are most likely familiar with AWT or Swing, which, depending on your VM, can be slow or a memory hog. Moreoever, many Java applications are not tuned to use a realisitic memory size, so there is a slow ramp-up period of excessive garbage collection until a desireable configuration is acquired by the VM. In production environments, this sort of tuning is done prior to roll-out.
The key difference is that DOS / Windows and even Mac applications are not generally designed for multi-month up-time. So the main difference between Java and non-Java-like applications is not readily apparent to the casual user.
I do agree, however, that for sufficiently small application life-cycles (such as the UNIX program "ls"), java is innappropriate. But this, again, falls into the category of applications not meant to be run for multiple months.
-Michael
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 blame Windows.
fork(2) is way better than threads in any application where the forked part doesn't need much communication with the parent. Because when a forked process crashes, there's no way for it to harm the parent. Even if you do need communication, fork mixed with pipes, sockets, signals, or shared memory can be great - a little more programming effort than threads, but you can have better-defined interfaces, you limit the damage a single failure can cause, and you often needn't worry as much about synchronization. Copy-on-write, implicit in fork, is also very useful - I just had to make a threaded program, and I basically had to implement copy-all-the-time (or I could have, at the cost of speed, implemented copy-on-write). If I could have just forked, I could have had processor-supported copy-on-write, which would have been faster, simpler, and smaller.
But alas, for whatever reason, Windows has no fork. (Let me qualify that - Microsoft SFU has it by somehow going outside the Win32 subsystem (has Microsoft released this API? If not, why not?), and Cygwin somehow fakes it in an inefficient way.) It's a really bad situation - all reasonable definitions of "cross-platform" include Windows, and thus exclude fork(2), so we're all stuck with the fragile solution of using threads and rolling our own copy-on-write.
Underneath the Win32 API is the NT Native API. NtCreateProcess can be called with the SectionHandle parameter set to NULL which produces a new process with the same address space as the ParentProcess handle, mapped copy-on-write just like fork. CreateProcess from win32 calls this function to create a new process but does not expose all of the functionaility.
SFU and the POSIX subsystem have to use NtCreateProcess too, but take advantage of SectionHandle=NULL.
Cygwin uses copy-on-create to simulate copy-on-write by copying the entire address space to the child. This is slow and wastes memory. The cygwin mailing lists have had endless arguments on why they don't take advantage of NtCreateProcess. Here's a small thread.
Also, there is the problem that Win32 does a lot more than just call NtCreateProcess: the native function creates a new process but nothing else. It allocates no memory, creates no threads, and loads no libraries. When you call CreateProcess from Win32, it does all that for you. Since Cygwin implements Posix (and related) over Win32, not Posix over NT (as opposed to SFU which is over NT), they feel compelled to use only Win32 functions.
It would be nice to have a cygwin fork that creates its own subsystem, an open-source SFU, that would take advantage of this kind of thing.
Depending on fork to provide stability is a workaround for the real problem: the app crashing.
Besides, if your data areas are well defined, you can put them in shared memory sections and have the children map that copy-on-write at the same addresses.
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.
Ummmm, no. Cygwin could detect the type of Windows running at startup and then execute different code based on the platform. Cygwin could load the NtCreateProcess function dynamically when NT is detected and use the old style copy everything method for 9x. One code base, and one binary that behaves differently based on the platform.
See LoadLibrary, GetProcAddress, , GetVersionEx and VER_PLATFORM_WIN32_NT.