[okeuday]

You can try to have fault-tolerance in the JVM, but not real-time fault-tolerance, and there is a difference. The goal is to have decent performance while being fault-tolerant. The JVM garbage collection prevents real-time fault-tolerance when using an Actor model within the JVM.

[RyanZAG]

Can you explain this concept in a bit more detail? There is nothing I can find to back this up anywhere, and the idea seems very strange to me as I've never heard of it before. A quick Google search on the topic seems to show a number of papers detailing real time fault tolerance on Java.[1]

At any rate, as far as I can tell CloudI is mainly intended for network and web systems, which are not going to be real time when running on Linux/Windows in any event. (network buffers, etc)

[1]

http://dl.acm.org/citation.cfm?id=1404893

https://weblogs.java.net/blog/editor/archive/2013/03/18/jona...

http://books.google.co.za/books?id=BroUpHAZThwC&pg=PA470&lpg...

[okeuday]

CloudI and Erlang underneath are focused on soft real-time. For hard real-time (embedded) you need tighter integration with hardware. While it is true that people attempt to pursue (soft) real-time fault-tolerance on the JVM, the point in the CloudI article is that the pursuit does not achieve fault-tolerance which can be considered real-time, simply due to the JVM garbage collection which must interrupt real-time processing of an Actor model. This problem isn't often discussed, but is a simple way of showing the problems with fault-tolerance on the JVM. Without the JVM supporting fault-tolerance, the effort to have decent (real-time) fault-tolerance would be similar to creating a new VM. Since creating a VM is difficult to do properly, and testing is required after its completion, it makes much more sense to use the Erlang VM since it has native real-time fault-tolerance that is already used in commercial products.