BEA has announced the availability of WebLogic Real Time Core Edition 1.1, which claims a maximum latency of 30 ms on its benchmark application. This consists of a JRockit 5.0 R26 with "deterministic garbage collection," JRockit Runtime Analyzer (which helps determine an application's latency characteristics), and WebLogic Basic Edition, a subset of the full WebLogic application server. The 30 millisecond claim doesn't apply to some J2EE mechanisms, because some of those mechanisms trade latency for scalability (for example, asynchronous JMS can introduce latency outside of the control of a given server, and database performance also factors in.) That said, BEA representatives stated that some very large deployments of WLRT are in use in unnamed financial environments, where latency is a very costly problem.

Taken from JRockit documentation:

For this reason, BEA JRockit 5.0 R26 introduces "deterministic" garbage collection, a dynamic garbage collection priority that makes the following guarantees about transaction latency: * On weekly basis the total pause time caused by garbage collection will not exceed 30ms during any sliding window of 50ms 99% of the time. * Total pause time caused by garbage collection will not exceed 100ms during any sliding window of 130ms.

I'm not a big expert in real time, but it sounds to me that this just won't cut it for some real time apps...

Hi,

I'm not a big expert in real time, but it sounds to me that this just won't cut it for some real time apps...

WebLogic Real Time (WLRT) Core Edition 1.1 is intended for soft real-time. Hard real-time demands sacrifices to the performance and the programing model that did not meet the target use-cases. Alex Alves BEA Systems

Taken from JRockit documentation:

For this reason, BEA JRockit 5.0 R26 introduces "deterministic" garbage collection, a dynamic garbage collection priority that makes the following guarantees about transaction latency: * On weekly basis the total pause time caused by garbage collection will not exceed 30ms during any sliding window of 50ms 99% of the time. * Total pause time caused by garbage collection will not exceed 100ms during any sliding window of 130ms.

I'm not a big expert in real time, but it sounds to me that this just won't cut it for some real time apps...

The 30 millisecond claim doesn't apply to some J2EE mechanisms, because some of those mechanisms trade latency for scalability (for example, asynchronous JMS can introduce latency outside of the control of a given server, and database performance also factors in.)

In other words, the real time JVM doesn't speed up things outside of the JVM like (for example) MQSeries or Oracle. All it does is to guarantee that your code has a really really really high chance of actually running within any given time window higher than 30ms, as opposed to the guarantee from the Sun VM (a.k.a. "none"!) that allows the garbage collector to stop your code for indeterminate (and seemingly interminable) periods of time.

That said, BEA representatives stated that some very large deployments of WLRT are in use in unnamed financial environments, where latency is a very costly problem.

Yes, it is definitely being deployed, and we've run into it in a number of big banks here in the states and in Europe. jRockit has some great technology, and kudos to BEA for some very fine work. There are still some a few rough edges in the JVM; from the tests that we have done, it is not yet as stable as the Sun JVM. However, I haven't had a chance to review the latest and greatest, so I hope to eat my words. Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java

+1

In other words, the real time JVM doesn't speed up things outside of the JVM like (for example) MQSeries or Oracle.

All it does is to guarantee that your code has a really really really high chance of actually running within any given time window higher than 30ms, as opposed to the guarantee from the Sun VM (a.k.a. "none"!) that allows the garbage collector to stop your code for indeterminate (and seemingly interminable) periods of time.

Now, you can eliminate the need to have latency backend issues with the use of an appropriate cache or IMDB. In the world of near-real-time there is a lot of application for BEA Real Time. Although they continually site "financial" as the big consumer I am curious as to why telco is not? If I have an IMS/SIP enabled network I can deploy some killer applications using this platform. Real-time rating, applications exposed over the network: real-time sports services, gambling (odds) and even integrated financial systems (tickers and other fun and exciting stuff).

Yes, it is definitely being deployed, and we've run into it in a number of big banks here in the states and in Europe.

Blah. Banks are boring. ;)

jRockit has some great technology, and kudos to BEA for some very fine work. There are still some a few rough edges in the JVM; from the tests that we have done, it is not yet as stable as the Sun JVM.

Agreed. But, when you are moving from the AIX JVM it is a world of difference! It still puzzles me as a customer as to why BEA would provide a JVM that gives me the power to run more applications on my existing license base? Well, judging from the posters here it would be because BEA is evil and their sales team is really a rabid pack of pit bulls that spit bees from their mouths. Cheers, Greg

Here's an article on WebLogic Real Time published on Dev2Dev: An Introduction to WebLogic Real Time Jon -- Dev2Dev

See http://java.sun.com/javase/technologies/realtime.jsp and http://research.sun.com/projects/mackinac/ Though I don't think their app server isn't supported on it ( at least, not yet, see http://www.eweek.com/article2/0,1895,1963869,00.asp).

Sun's real-time requires re-writes. In a nutshell, it isn't "Java" as we know it. (I am not saying it is any worse or any better as a solution, but it is different.) BEA's jRockit JVM is just a bog standard JVM that runs bog standard Java, but it can do so with real-time characteristics. Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java