Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Java Programming IT Technology

Quest For "Unbreakable Java" Unites ABAP & Java 198

Posted by Hemos from the its-a-festivus-miracle dept.
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."
This discussion has been archived. No new comments can be posted.

Quest For "Unbreakable Java" Unites ABAP & Java More

Quest For "Unbreakable Java" Unites ABAP & Java

Comments Filter:

  • Throw it in jail (Score:5, Interesting)

    by SIGALRM ( 784769 ) * on Monday January 03, 2005 @12:52PM (#11245387) Journal
    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 (Score:2, Interesting)

      by Anonymous Coward
      I agree that ABAP's dispatcher is an excellent model for per-process isolation.

      Hrmpf! ABAP and/or R/3 should better not be taken as a model for anything. Hell, even Visual Basic is the work of a genius compared to the convoluted mess that ABAP R/3 is. Dont expect anything to come out of this 'Unbreakable Java' in the next 10 years. A lot of people at SAP would like to get rid of ABAP and see Java as the way out, but it wont be done overnight. Sure they can do interfaces so that you can call Java from ABAP

  • The perfect solution... (Score:5, Funny)

    by CodeWanker ( 534624 ) on Monday January 03, 2005 @12:54PM (#11245408) Journal
    for making ANYTHING into "Never Goes Down" is a marriage. Dammit.

    • Re:The perfect solution... (Score:5, Funny)

      by grub ( 11606 ) <slashdot@grub.net> on Monday January 03, 2005 @01:00PM (#11245472) Homepage Journal

      Scientists have discovered a food that takes away a woman's sex drive. Wedding cake.
      • I'm getting married in a few months. I don't want all her sex drive to go away, just a little bit of it. There are days she just won't stop- 5x a night and work is such a drag the next day... repeat over the week and I'm pulling (no pun intended) 120hr work weeks.

        Are all women insatiable like this or did I just happen to hit the motherload?
        • Are all women insatiable like this or did I just happen to hit the motherload?

          Is she approaching 40?
          Did she attend a private church-funded school?
          Those are the best reasons I've been able to come up with to explain my situation.

          Knock her up. That put an end to it for me.. All they want to do for the first trimester is sleep.
        • Maybe you're just not satisfying her. Is she having an orgasm (or more)? If not, try reading The Clitoral Truth [sevenstories.com] 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 :(.
    • heheh, it seems wives are like gas stations, some are full service, some have partial service, and others make you self service.

  • ABAP? (Score:2, Redundant)

    by bogaboga ( 793279 )
    It seems I have been sleeping under some rock! For this is the first time I am hearing of ABAP.

    • Re:ABAP? (Score:3, Informative)

      by srinivas_rc ( 737431 )
      It is a programming language for changes in SAP ERP System.

      • Re:ABAP? (Score:5, Informative)

        by KenSeymour ( 81018 ) on Monday January 03, 2005 @01:07PM (#11245544)
        I have heard of it jokingly referred to as "German COBOL."

        If you enter the world of SAP, be prepared for a thousand acronyms.

        • first (Score:3, Insightful)

          by geekoid ( 135745 )
          that's bPfaTA

          How come when I talk to a company executive, they're implementing SAP.
          Nobody ever seem to have implemented it.
    • ABAP is an acronym for "Advanced Business Application Programming". Why they had to develop their own language is a mystery considering the number of available friendly-licensed languages out there.

      = 9J =

  • kekek, never say never, didn't Fable teach you anything

  • I think the first thing he should do is install Solaris 10 with DTrace [sun.com] 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 [mirrordot.com] 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 :).

  • Java in one process (Score:2, Interesting)

    by killmister ( 686470 )
    >>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.

    • Re:Java in one process (Score:2, Insightful)

      by Anonymous Coward
      > 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.

      That does not change the fact that those threads are handled by a virtual machine that provide no isolation between them.

      --
      Mickaël Rémond
      http://www.erlang-projects.org/ [erlang-projects.org]
  • 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.
  • Hrmm...sounds like a bad Slashdot poll option. ;-)

    R3

  • So basically... (Score:5, Interesting)

    by bill_mcgonigle ( 4333 ) * on Monday January 03, 2005 @01:03PM (#11245497) Homepage Journal
    • 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.

    • Re:So basically... (Score:5, Informative)

      by /ASCII ( 86998 ) on Monday January 03, 2005 @01:20PM (#11245677) Homepage
      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.

      • Re:So basically... (Score:2, Informative)

        by Anonymous Coward

        Have a backup computer which automatically picks up if the first one falls down.

        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 awar

  • 8 years of Java! (Score:4, Funny)

    by Octagon Most ( 522688 ) on Monday January 03, 2005 @01:07PM (#11245542)
    "eating, sleeping, and drinking Java" for 8 years

    I'm getting the shakes even thinking about that.

  • Analogies Gone Wild! (Score:3, Funny)

    by Momoru ( 837801 ) on Monday January 03, 2005 @01:12PM (#11245602) Homepage Journal
    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.
    • I have a suggestion for the next /code release: add a feature to the code that will scan the comments after they are submitted and searches for grammatical errors. When an error is found, the incorrect word would be then shown in red in brackets, and a correct word would be put outside of the brackets with a link to the dictionary.

      Basically embarrass the posters by highlighting their errors to everyone and at the same time draw their attention to the errors.

      I bet after implementing such a system this sit

  • Shared memory w/ processes is no better (Score:3, Insightful)

    by Anonymous Coward on Monday January 03, 2005 @01:22PM (#11245692)
    than shared memory with threads. Threads are basically just processes that share the same memory. And it's the shared part that makes resistance to errors or error recovery so problematic.

    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.

  • "Normally less than 10 percent of the users connected to a system are actively sending requests; the others are thinking about their next action or typing in some data at the front end (thinking users)."

    Thinking users?!?! I didn't know this article was supposed to be funny!

  • This has been the basis of Erlang for 18 years (Score:2, Interesting)

    by Anonymous Coward

    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 [www.sics.se]

    Fortunately, Erlang has been designed from the ground-up for robustness. All feature of Erla

  • Crash-only software (Score:5, Interesting)

    by Earlybird ( 56426 ) <slashdot @ p u r e f i c t ion.net> on Monday January 03, 2005 @01:46PM (#11245886) Homepage
    Ladies and germs, I give you crash-only software [stanford.edu].

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

        Not just that -- accept that crashing is a valid way of shutting down your program. In other words, be kill -9-safe. Also, include crash recovery in the first place; an orphaned pid file (hello, Jabberd [jabber.org]!) or an orphaned lock file (yo, Lucene [apache.org]!) should not prevent a program from starting up. It's incredible how prevalent these lit

        • We are in violent agreement. True, your program can be kill -9 safe but it does not mean that your program cannot simply exit() when some pre-defined condition arises. (A traditional exit() is also a good way to check for memory leaks with such programs purify and valgrind - but that's another matter). But these ideas are not revolutionary by any means. I thought everyone who writes fault-tolerant servers follows these practices.

  • Hmmm (Score:3, Funny)

    by knightrdr ( 685033 ) on Monday January 03, 2005 @01:47PM (#11245888) Homepage
    I thought my girlfriend was the only thing that didn't go down.
  • The developer seems to be creating isolation from other people by "eating, sleeping, and drinking Java". I hope there is showering in this regimen, and not involving Java.
  • The Java VM is already very secure from a code exploit standpoint. The machine model provides an unescapable environment which is equivalent to the hardware "user mode". It is straightforward to extend the API in pure Java to provide logically isolated "processes" and/or users, and many previous projects have done so, for example JDistro [freshmeat.net]. All in all, Java provides excellent protectation against attackers executing arbitrary code and buggy programs corrupting memory.

    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 know .net has AppDomains which are modeled after NT processes which you can run use to isolate code/tasks. Sharing of data between appdomains has to be done over shared memory,.net remoting or someother type of marshaling. You can also unload and load them at will. I think java has something similiar but not as powerful called protected domains.

  • Misssing the point (Score:3, Interesting)

    by iamacat ( 583406 ) on Monday January 03, 2005 @02:17PM (#11246161)
    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.

  • Nothing new here (Score:3, Interesting)

    by IHateSlashDot ( 823890 ) on Monday January 03, 2005 @02:21PM (#11246198)
    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).
  • Java, remember, was intended as a client-side concept. As a server-side concept, it provides a useable API to the application programmer, but from the OS side, it's a terrible idea.

    If you want reliability, what you need is a transaction processing system, where transaction programs are quickly started, do their job for one user, and exit. There have been high-performance systems for transaction processing for decades. That's how mainframes work. CICS, TIP, and of course Tandem worked that way. CGI pr

    • The basic idea is that the web server starts up some CGI program, lets it do all its initialization, and lets it run to the point that it is ready to accept data for a specific transaction. Then it makes a call to wait for transaction data. When a transaction comes in, the server forks off a new copy of the initialized transaction program. That copy deals with one user transaction, and then exits.

      Congratulations - you've just invented FastCGI [fastcgi.com]. At least, you would have done if you'd come along a decade or
      • FastCGI is neat, but a different approach. It's basically another level of client/server processing, in which the CGI programs are servers and the web server is the client. Because the CGI programs don't exit after each transaction, they can be corrupted. That's different than a transaction processor.
    • I don't think fork is what you want.

      My understanding is that there is a preset number of "processes" for CICS. I think we have 4. So for CGI, you would start up 4 processes, get them through initialization, then let them loop on data (incoming requests). If one crashes, restart it.

      To be efficient, all dynamic allocation of anything should be an exception, not SOP, including creating processes. That is why Unix appears slow for batch work; it lends itself to lots of dynamic allocation. Of course, most

  • Check out the Isolation JSR (Score:5, Interesting)

    by AdamInParadise ( 257888 ) on Monday January 03, 2005 @02:29PM (#11246296) Homepage
    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 [jcp.org]

    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.

  • Ever hear of Tandem (Score:2, Interesting)

    by Anonymous Coward
    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.

    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 proces
  • When a program "crashes", "freezes", "chokes", "barfs", becomes unresponsive to GUI/API/network input and likewise appears to remain in a "steady state", what is the program actually "doing" at that time? The CPU probably isn't actually halted; it's probably retrieving instructions and executing them, though not apparently. I always figured that the CPU was in some kind of A/B loop, like

    INSTRUCTION1: EXECUTE INSTRUCTION2
    INSTRUCTION2: EXECUTE INSTRUCTION1

    resulting from memory corruption inserting those bra

  • Before you put too much faith in "unbreakable" JVMs, you should read the comments about Sun's JVM source code on Slava Pestov's Weblog: "HotSpot source code is a bad joke" [jroller.com]. scary!

  • This is nothing more than a cleverly disguised pimping of SAP'S netweaver app server.

    First and foremost SAP I do not want to have to run your hacked up JVM. Is it a good idea, yea probably but implementing it is gonna be hard because of the closed nature of JVM.

    No sys admin and or programmer in his right mind wants to work with or support some third party JVM.

    All that being said what's up JBOSS developers? Is this a good idea? I most certainly trust your skill far and beyond anything these guys can produ
  • Yep, process separation, operating system does it for free, pretty much old news. The thing that bugs me about some Java developers is how they take those concepts like multithreading and separated execution and try to rebuild it painfully with a Java infrastructure, when the VM is probably not the best place to do this.

    For example, when the author talks about the ABAP's process model and how it should probably be rebuild with Java. The idea is basically: One process (or thread) per request, shared session

Slashdot Top Deals

8 Catfish = 1 Octo-puss

Close