This content has been marked as final. Show 2 replies
We ported the GlassFish Application Server to the Java RTS product implementation of the RTSJ in 5 hours including a new feature to open a real-time http connection.
First, not all of every ported application needs real-time support thus 95% or more just runs as is (since RTSJ is fully, completely, Java). Like in the GlassFish example we changed no code and it ran fine on the real-time JVM. Then we replicated the thread pool creation code and changed it to use instances of javax.realtime.RealtimeThread.
Converting large applications to completely RTSJ can be very simple, just a syntax change from java.lang.Thread to javax.realtime.RealtimeThread is all that is needed to get a lot of the features of the RTSJ. E.g., in Java RTSJ 2.0 (now in beta) instances of RealtimeThread can execute with a maximum of ONLY 200 microseconds of pause times from the real-time GC.
Using ScopedMemory and NoHeapRealtimeThreads is only necessary for those bits of logic wich require maximum latencies in the few tens of microseconds (such as low level command loops for high speed physical devices).
wondering if you've come across any examples
whereby JEE applications have been migrated to a
realtime vm ? Curious as to effort involved in
moving medium sized applictions (100ks lines of
code) over - primary motivations are the gc pauses.
Does this fundamentally require an app server
targeted for a realtime vm ?