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
Now I just Buy Mine on the way to work. So far so good.
It seems I have been sleeping under some rock! For this is the first time I am hearing of ABAP.
kekek, never say never, didn't Fable teach you anything
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!
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
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.
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.
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.
Score: -1, Idiot Who Has Never Written A Line of Code in His Life Yet Wants To Sound Like a Hardened Programmer By Making Retarded Comments About Stuff He Clearly Knows Nothing About
What does he mean "Titanic"? Software is like a car, not a boat!
"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!
SIGFAULT
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/
My intention isn't to troll here, but...
.. enough of that...
Does anyone that knows more than just java as a programming language actually like it? I know a few lanauges, scripting and programming, and was introduced inevitably to java back in 2002 or so.
I hated it right from the get-go. The total operating system independence is the only thing that's cool about this language in my opinion.
The language itself is clunky and overly complicated, not to mention annoying, and the vm is a total resource hog. Everything is slow, and well
After reading this article, I think I actually loathe it now.
Now if you excuse me, I'm going to go clean out all the hate mail I'm getting from the "I've been eating, sleeping and happily married to java.. exuse me? C? C++? Perl? What the heck are those?" people...
---- How absolute the knave is! We must speak by the card, or equivocation will undo us. -Shakespeare
I thought my girlfriend was the only thing that didn't go down.
Originally, CGI application processes were invoked by the web server, passing the data request to the process as environment variables.
Then came Java, and every web app runs under the same VM...crashing the VM crashes all the web applications for all users.
The Java solution is preferrable over CGI because it is much faster to assign a job to a Java thread than to create a new native process each time a new request is made.
So why CGI did not choose to cache native processes? a native process could be blocked at some port, then the web server would wake the process up by sending the request to the process through an IPC mechanism. Therefore the cost of launching the request would be minimized, since the process would already be running. A shared memory queue would be the fastest communication mechanism, I think.
The job of the web server would then be to take each incoming request, parse the data, find out which is the process assigned to the request, then send the data to the process, initializing the process first if the process does not run.
The web process would wait on the queue for a specific amount of time; when that amount passed, the process would terminate itself.
By the way, ABAP is yet another programming language (coming in two flavors:plain and object oriented) designed specifically for tackling database problems. It seems that the problem of information management from conventional programming languages has not been tackled yet.
So, following this guy's reasoning, since all code has bugs, a bug might corrupt the shared memory, and therefore, you break all processes!
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.
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.
Classes aren't the only thing that use memory in Java. Your VMs probably have max heap size set to 512M-1G in the first place...this doesn't include the VM's footprint. Even with 4G of memory, you'll soon be in continuous swap mode if you have too many VMs.
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.
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?
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.
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
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 .jsp extensions).
The focus wasn't code running on someone else's system and you know that.
If the memory leaks on someone else's system, it isn't my problem, is it?
Sure, there are memory leaking pig Java apps. There are memory leaking pig X apps where X is the language of your choice.
Java apps, running under Linux or Windows, are far worse than the average for all other apps.
Admitting you have a problem is the first step to getting help.
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).
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 programs also work that way, but because UNIX/Linux is a lousy transaction processing system, they've fallen out of favor.
If you wanted a real transaction system for Linux, what you'd need is this:
-
Some way to make forkable transaction programs with small dynamic memory footprints and small startup costs.
That means a language implementation with shared code, small dynamic data, and short startup time.
Perl, Python, or Java would work with some modifications to the run time environment, but a hard-compiled language would be better.
-
Copy on write semantics for transaction programs.
-
Really fast fork. Not fork/exec, fork.
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.This gets around the big problem with CGI programs - the initialization cost dominates the transaction. CGI is a good idea from the reliability and security standpoint. If the startup overhead problem is fixed, it's a good solution for high volume applications. You don't want to be doing class loading or source compilation for every transaction. On the other hand, you don't want to share the run time environment between transactions.
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.
The only bigger assholes than the guy who responded to your original post were the guys who modded him up.
FTFA Some may even remember the White Star Line promising that their ocean liner Titanic was unsinkable; an iceberg in the North Atlantic proved them wrong and demonstrated that there is no such thing as an unsinkable ship.
Who 'remembers' that?
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
My employer used to run custom C++ applications for back-end web processing. Now we run Java/J2EE applications for back-end web processing.
Switching to Java had a negligable change in our hardware budget. "More money for servers" is a myth.
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
I never had the performance problems with any of my JAVA apps that I created or that I used (such as eclipse).
The performance problems referred by others may be related to the abilities of the JAVA programmer more than the JVM.
BTW, just so I can be like everybody in this thread. My brag text is that I've been programming for over 23 years and used ASM, C/C++, Forth, Fortran, PHP, Perl, Haskell, Prolog, Java, and some I rather forget.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
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.
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 bracketing instructions in the codepath. But I'd expect there to be more code intervening most of the time, which would more often generate other results. And at least occasionally for such degenerating garbage generation to corrupt the corrupt loop brackets, ending the loop. But those never happen. What is that crashed process actually doing while it's too busy to talk to me?
--
make install -not war
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.
"eating, sleeping, and drinking Java" for 8 years
I'd be concerned that more than his server would break...
The focus wasn't code running on someone else's system and you know that.
No. You said you 'loathed' all java apps you had used. You did not qualify this. There was no 'focus' on what you said - it was a clear statement.
If the memory leaks on someone else's system, it isn't my problem, is it?
Yes, because if memory *really* leaked on those systems, they would become unstable and unusable. Java is used widely in critical applications like banking, and ticketing systems. If these systems become unstable, it affects you!
Java apps, running under Linux or Windows, are far worse than the average for all other apps.
I assume you have some statistics to back this up?
The only bigger assholes than the guy who responded to your original post were the guys who modded him up.
If responding to vague generatisations with counter examples and facts counts me as an asshole, then I celebrate my assholeness!
so you hired a moron to debug a shitty application, so java sucks?
you can write crappy code in any language, it is up to the programmer not to write crappy code in the first place.
PHP is the solution of choice for relaying mysql errors to web users.
Unite .NET + JAVA or Visual Basic ?
.Net and Mono.
Already been done! There is J#, and Java support in
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. At least, you would have done if you'd come along a decade or so ago (its been around at least since 1996).
And yes, its available for use with C, Perl, Python and Java - oh, and Smalltalk, Lisp, Ruby, VMS, and others as well. You can even get supported plug-ins for the more common webservers.
Alright, so you specify a forced fork rather than an optional one. Still, that's a pretty trivial difference.
You're special forces then? That's great! I just love your olympics!
How about contributing something rather than just talking about how others can't do something? You imply you know more than the parent poster but did nothing but contribute a pre-teen style slam. Hmm. I wonder who has the higher IQ?
What's kind of funny is that the isolation so desired by the author is built in to .NET from the get go.
They're called Application Domains, and they're used heavily in ASP.NET to isolate applications from one another, but have them remain inside a single OS process.
Oh no, its worse than that. Not only does SAP/ABAP consist of a world of acronyms, but they are acronyms or abbreviations for German words, not english ones.
Consider this little tidbit - a SAP 3.1/H system with multiple installed modules can have as many as 10000 tables in the schema. The length limitation on a table name is 4 characters! So you get names like MARA, MSEG, VTTK, etc. etc. Field names are no better, transaction names are also only four characters (SM30, SM35, VT01, VT02). To boot, even the names of the modules are cryptic: for exaple, SD, PM, MM, and FI.
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.
If the memory leaks on someone else's system, it isn't my problem, is it?
Yes, because if memory *really* leaked on those systems, they would become unstable and unusable. Java is used widely in critical applications like banking, and ticketing systems. If these systems become unstable, it affects you!
Incorrect. Memory leaks in those systems are less of an issue because the processes are regularly restarted... Often to deal with memory leaks.
aren't most Java virtual machines written in c/c++?
... the concept isn't new, but interesting is combining the safety of user separation with the programming safety of Java.
... (yes you can prohibit that one, but there are more subtle ways of destruction).
And - if you build applications that can be customized and extended beyond any level (as SAP does) - you want at least that it will not crash and burn too often with too hefty impacts - even if you are not primary the guilty but some stupid consultant writing a messy customization.
Think of some schlehmil having a System.exit call in an EJB
Incorrect. Memory leaks in those systems are less of an issue because the processes are regularly restarted... Often to deal with memory leaks.
Not true. Java application servers can be very stable indeed. For example, the free Tomcat server can be run for a very long time without problems (memory issues arise if JSP pages are being constantly recompiled, but this is more likely in a development context, not a deployment).
Memory leaks (or rather, poor memory management) are common in badly written web applications, but very rare in the web/application servers themselves.
J2EE servers are used in situations that require very high availability, such as online transaction processing. Restarts are not acceptable in these situations.
ant is a really simple cmd-line process, I can't see how it leaking memory would be a big deal.
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.
[o]_O
There's been some discussion of approaches to concurrency recently on the Lambda the Ultimate blog. Erlang is mentioned as well as links to a bunch of other approaches.
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 problems are too complex for that and are best addresses with dynamic allocation, hence the popularity of C/C++, VB, and Java.
Joe Batt Solid Design
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.
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". scary!
cpeterso
Where's the -1, Inevitable modifier when you need it?
Dealing with lawyers would be a lot less tedious if they all looked like Casey Novak.
Like most Java-bashers, he uses proof by vigorous hand-waving...
= 9J =
.... she says she loses count after 5 ;-)
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.
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 produce.
Got Code?
I agree pretty much entirely with you. .exe but every one ive seen isnt free , if you know of any which are , preferably ones which are easy to use, please tell :) )
:D )
I was doing c++ programming as a hobby really for a year or two before i changed my university course to applied computing - which teaches java as part of the course.
To begin with i was -not- looking forward to it, having heard horror stories about java being slow, clunky and inelegant - indeed i tried a java app out to see what it was like and found it horribly sluggish. Everything about it just felt slow.
Im no java expert , and my coding skills in either c++ or java are far from adept but i like java more then i liked c++.
Sure - java has its problems and things about it i dont like, but then so does c++.
I for instance hate pointers with avengance in c++, like i hate not being able to compile to native code in java so people dont need to run a jvm to run my program
( yes i know about programs out there which turn java programs to
On the other hand there are things about java i really do like, such as arraylists which i adore \o/.
no language is perfect really. Its either very fast, efficient and a nightmare to code in and debug ( assembler, etc ) or easy to understand and code in but absolutely awful performance wise ( visual basic imo but im sure theres worse
Linux has always been monolithic; it has not migrated from a microkernel-based model.
Indeed.
Larry
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 data storage across requests - that sounds like the best place for a classic CGI environment to me. PHP would probably do a nice job, or Perl or anything.
So if you want those features, why not build on top of Apache, maybe communicate with the client via XML webservices? CGI calls to script interpreters would pretty much provide anything you could possibly needed, while offering customizable degrees of separation *for free* right in the webserver. Why not? Why spend millions to build another bloated Java application server (that may or may not some day be able to support the same kind of featureset that webserver architectures already have)?
Years ago I worked on a single board computer. This machine was for a space shuttle program for a major national laboratory. I determined rather quickly that I could have put a clock on the reset and start from the beginning of the assembly code everytime and the system would have worked fine. This wasn't a 'crash'. A crash in the Air Force meant that a plane physically crashed into something. Or a rocket crashed into the dessert. Crashing was unacceptable. So if the software didn't work we called it a 'hang'. As far as a bringing software to a halt with a crash, that is not a very logical thing to do. It shows an extreame lack of design skills. I just wouldn't do it like that. There are many reasons why you can't do things like this in a lot of different systems. For embedded systems you really need to have a logical shut down. I would guess that would be correct as well for a server. You might mean that an application would 'crash', but not the whole system. Would you suggest that a server crash to end a user session? What about all of the other users? In the theoretical world of fantasy software the idea of 'crash only' is a cute intellectual idea, but utterly not a good way to design any software. You should provide a way to break out of code. Remember software engineering is just one part of engineering. You might think that a software crash is a benign event, however when software runs hardware, systems, trains, buses, airplanes, sattelites, then a 'crash' is a very bad thing and people might die. Maybe you mean 'reset only'. If that is the case, then I could have done this in 1988. If the system 'hung' the watchdog timer would reset. In embedded systems a watchdog timer is a very common thing, and actually a requirement. But you probably should use the term 'reset only' and not 'crash-only'. Crash is a catastrophy. Reset is an expected event.
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'm a long time Windows programmer, and I know what the difference is between a process, thread, and fiber. Can you explain what a fork is and why exactly it is different from a thread? If a thread throws an exception or crashes in Windows, it is simply killed off without causing the application to crash. Basically a thread occupies the same memory space as the creating thread, and a process gets a whole new memory space. How does "fork" differ from that model?
LOAD "SIG",8,1
LOADING...
READY.
RUN
Wow, they've taken the 'insights' of Oracle Apps database design principles to another level! Bravo!
Java sucks, ABAP sucks worse. Let the idiots go play with their stupid languages.
That is all.
Forking duplicates the running process and continues executing from the next instruction. Returns the pid of the child to the "real" process, and 0 to the dup. You end up with two processes, each with its own (identical to the other) address space and data.
To the programmer, it appears that fork() makes a copy of all the memory, but internally, both processes have all their pages marked as copy-on-write. When one process tries to write to such a page, the CPU raises a page fault interrupt (This sounds scary, but it's not - it's also how demand loading of executables and virtual memory works). The kernel intercepts this, and makes a new copy of the page for that process to write on. The overhead is minimal - at fork() time, some tables are copied, and the first time you change something on a page, a pagefault occurs. The CPU was performing the writable check on every instruction anyway.
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 never had the performance problems with any of my JAVA apps that I created or that I used (such as eclipse).
It depends what you're doing. Need to start an application quickly? Tough -- each new version of Java (1.2, 1.3, 1.4, at least) adds gobs of new classes that are loaded on startup, whether you use them or not. From 1.2 to 1.4 (haven't played with 1.5 much), startup time has gotten steadily worse. For some types of programs, this is OK, but for things to put in front of people on the desktop, it's not.
Also, the way some (many?) JVMs make things faster is by using more memory. The more memory you give it, the faster it goes -- yeah, it's true in any language, but JVMs really suck it down. You can make a Java application run reasonably fast on a system with 128 MB of memory, but can you switch to your other applications quickly, or will they all be swapped to disk? Can you run 2 or 3 Java applications at once?
Interestingly, the example you give (eclipse) approaches the problem by ignoring all of Java's built-in GUI toolkits (AWT and Swing) and writes its own using the native interface. (And I haven't used it recently, but I will guess that it still starts up noticably slower than native applications.)
In other words: Yes, you can write reasonably fast applications in Java. All you have to do is ignore all the libraries that ship with it, and write your own in C instead.
Disclaimer: I've used Java since the 1.0 days, and I've written and delivered real programs (>50,000 lines) using it. If you try hard enough, you can make a program running inside a JVM go fast, but Java doesn't make this easy for you.
Quite frankly a network systems engineer should not have to troubleshoot applications. I would troubleshoot the programmers instead because it sounds like poor programming is the root of your problem.
Me? 8 years nonstop Java.
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.
Ah - thanks for the explanation. That's definitely not something easily reproducible on Windows.
LOAD "SIG",8,1
LOADING...
READY.
RUN
Some of us are still running cygwin on MS-Windows 95.
Using MS-Windows NT-specific code would leave us out in the cold.
Either that, or they'd have to maintain two versions, which I doubt they want to do.
In theory this is true in Unix as well, but if the thread crashed or got an exception it wasn't expecting how do you "know" that the memory space of the other threads aren't damaged. Also in theory even though you can allocate mutexes etc. in a way that they'll be released when this happens ... you weren't expecting it to happen and in theory theory and practice are the same.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
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.
I looked at the comment history of t_allardyce, and he is also a karma whore, doing short provocative comments to provoke many answers.
I read the arguments about Isolation - but sorry, isolation isn't enough.
To make things that never fail you need more than one computer!
The minimal configuration is TWO computers (sorry for shouting) and even that won't work if both computers fail.
This means you need to do distributed computing - whether you like it or not.
Stuff that never stops => more than one computer => distributed computing.
It also implies NO SHARED DATA STRUCTURES (imagine me hitting the keyboard here) - why? - think about it. Computer A has a pointer to a data structuire on computer B - computer B now crashes - ooops.
So how far have we come? - you need two or more computers, and no shared data structure (oh, and by the way, no sharing implies EVERYTHING MUST BE COPIED) - so you have to copy everything you need to do crash recovery to both machines involved.
This is very definately NOT how java was designed. Threads SHARE resources - so you have to use one style of programming when using two threads on the same machine but a completely different style of porgramming when using two threads on two different machines - some people might like this - I don't.
Oh and what more? - stable storage - what's that? Stable storage is storage which survives a crash! You need that as well.
I think (I'm not really sure) That there are actually 6 different things you need to do to make a fault tolerent system (see pages 27-28) of [1] - isolation in one of them.
If you want to make fault-tolerent system I'd suggest to read [1] (it's free) - then download [2] and off you go - it's easy.
Using [2] We have made some pretty reliable systems - as far as I know some of them have never stopped :-)
Cheers
/Joe
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.
Andrew Tanenbaum, is that you?
Look at Candea's papers (http://www.stanford.edu/~candea/papers.html)... he applied that stuff at least to a J2EE online auction app (on JBoss) and a real satellite ground station...
from the Cygwin developer:
That isn't really new. I'd like to point you to the example 6.1,
"Forking a Win32 Process" on p. 161ff of Gary Nebbett's excellent
book "Windows NT/2000 Native API Reference", published by MTP,
ISBN 1-57870-199-6, which also describes the problem with kernel32.dll
initialization of the child process.
Care to explain what are the problems with this approach? Clearly, something of a technical nature prevents them from using NtCreateProcess.