In five years all application servers will be realtime capable...
At the JavaONE 2007 the availibility of the Java RTS 2.0 specification was announced. Real Time Software is often used for embedded devices and robotics.
The predictability and hard timinig constraints are required otherwise the hardware could be damaged.
Real time constraints could be also interesting for general business applications... Reviewing the functional specifications of my recent projects (e.g. use cases), I found statements like: "the use case XYZ has to complete in 1 second" which is a (soft) kind of real time constraint. A real time application server would simplify the load tests and make the behavior of the software under load more predictable. Of course there is one drawback: the predictability is not free and costs about 10-30% of the throughput - but this should'n be a huge problem. On the other hand with a real time server the hardware could be better utilized.
An RTS application will become in the near future especially interesting for multi-project servers. The real time throughput-penalty of 10-30% can be compensated with faster hardware or bigger cluster. The "normal" application servers do not run on the 80%-utilitzation, so it shouldn't be a problem to convert them to an RTS-system - at least from the throughput perspective. So the resources of an applicationserver could be shared in a fair fashion between independent applications and the behavior under stress would be easier to predict...
I don't see RTS for servers. When a server is under load, and requests are queued, there can be no guarantee that the queue time + process time will complete within x period of time. RTS is, of course, useful for medical devices or military drones, where the effects of a 1 second delay due, say to garbage collection, can be catastrophic.
Posted by Shane Isbell on June 02, 2007 at 09:40 AM CEST #
Shane,
and RTS server will also have queues - but they will be priority driven. I see benefits in "soft" real time area, so I'm not interested in microseconds, but in milliseconds/seconds. A garbage collector of an RT application server wouldn't stop the world...
I still see some essential benefits having the predictability on a multi project application server.
thank you for your comment!
adam
Posted by Adam Bien on June 03, 2007 at 11:49 AM CEST #
With RTS you have much better control of the GC.
If you can guarantee that the CPU load of your app is less than 100% BEFORE the allocated memory is full (its not the Heap) then (in theory) you will never get stop the world GCs (also known as full GCs).
Without Java RTS you can't even prevent full GCs if you have only 10% CPU load! So given that a full GC on a > 1GB Heap takes several seconds you could probably increase responsibility of your server using RTS.
The other interesting part is that you can mix real time Threads on non Heap memory with plain old Threads (let call them POTs in about 5 years ;) ). I dont know if it is already possible but RT Threads should be able to run even while a full GC is running because they are not sharing memory...
so many cool news from j1 and no time to try them all out :(
regards,
michael
Posted by Michael Bien on June 03, 2007 at 11:37 PM CEST #