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."
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 :).
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
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
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.
Try out fish, the friendly interactive shell.
process P1 - starts user session S1, create session in memory, write session to closure S1C1 and append CRC.
At the next point in handling S1 the original process doesn't matter, any process can grab S1C1 and validate the CRC. Any process working on the session data only works on a copy, a change will create S1C2, S1C1 will remain until S1C2 is final and no process is using it any more.
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.
If its a hardware failure and you can start from the beginning maybe. But thats a lot harder to do than you make is sound given that realtime systems often cant miss a heartbeat and must keep on processing. I have spent much of my professional life writing code to do just that, and without having facilities built into the OS you have to write a lot of application level code to make it happen. Each application needs to be aware of all replicas, and in order for any replicas to take over they need to have the same "state".
The real problem is that the "state" made the first copy fail, so how does the copy keep from failing given the same conditions? If the logic is buggy then they will all do exactly the same thing given the same inputs. Migrating the process to another machine is a whole can of worms in and of itself.
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.
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
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.