Java RTS and Nasdaq

Did you see the Rich Green’s keynote address at JavaOne? If not, watch the webcast replay here.

There was an interesting (albeit quick) segment on real-time Java; specifically regarding Sun’s Java Real-Time System (Java RTS). Anna Ewing, the CIO at Nasdaq, spoke about Nasdaq’s key trading system, and how it’s implemented in Java. They handle hundreds of thousands of transactions per second during peak load, and they do it with Java. That alone is cool.

However, do you understand why Java RTS is important to Nasdaq? Before you answer, let’s brush up on what, exactly, real-time is. A real-time system is one that is subject to an operational deadline. For example, the time from when a real-world event occurs, to the moment the system completes its processing of that event must occur within a strict deadline. Such a system demands predictable overall system behavior, with bounded latencies.

Often, real-time is confused with “real fast,” but that’s not accurate. A web server is required to send back HTTP responses as quickly as possible, but that doesn’t make it real-time. Conversely, financial settlements (the transfer of money from one bank to another) for foreign exchange trades are required to occur within two days of a trade, or they become invalid and stiff penalties apply. That two-day deadline is a hard real-time requirement, but it doesn’t demand a “fast” response. Nasdaq most certainly has tighter deadlines than two-days. In fact, Anna alluded to a sub-millisecond deadline requirement in her talk at JavaOne.

That requirement applies to each task, not the average response time of that task. For instance, if a system has a real-time requirement to process a request within 1 millisecond, and the average response time for 10,000 requests is 600 microseconds, it might appear that the system has met its real-time constraints. However, that may not be the case. This measurement, unfortunately, is for throughput, which is also confused as real-time.

Even if the large majority of responses over time are delivered by their deadline, the existence of even a few responses that occur outside that deadline represent what is known as “outliers.” Since the number of, and the degree of, these outliers is unknown and therefore unpredictable, this high-throughput system is not a real-time system. Real-time means you must complete a task before a deadline, all the time, or the result is an error.

Now you understand the differences between high-performance systems (really only a relative term), high-throughput systems, and real-time systems. It should also now be clear why Nasdaq requires Java RTS. Having high-throughput with standard Java today is good, but because throughput is a measure of average response time, it means that some customers get their orders fulfilled outside of the agreed deadline. This could cost the customer (and Nasdaq) money, as the markets continue to move during that delay. Java RTS assures customers like Nasdaq that their Java code will perform its tasks within a predictable amount of time, all the time.

For Java RTS to do this, it requires a different form of garbage collection, as GC in standard Java can occur at any time and interrupt your code from executing. This can cause you to miss a deadline. The real-time garbage collector (RTGC) that comes with Java RTS solves this problem.

And if the RTGC, with its minimized, bounded, latencies still fall outside of your tight deadlines, Java RTS (which adheres to the Real-Time for Java Specification) provides a means to work outside of the heap and without the need for GC at all.

This is an exciting achievement for Java (and Greg Bollella, Sun's Distiguished Engineer behind its success) as it opens the door for it to be used in applications it couldn’t be used before, such as critical flight control systems, manufacturing systems, military applications, embedded systems, and so on.

For more in-depth information on the internal real-time scheduling within Java RTS, read this DDJ article by Dr. Greg Bollella.

Posted by Eric Bruno at 05:32 PM  Permalink