Bringing Erlang's Fault-Tolerance to Polyglot Development | Hacker News Reader

Bringing Erlang's Fault-Tolerance to Polyglot Development

toptal.com

19 pointsbbeneschott9 comments

  Basically, building real-time fault-tolerance support on top
  of the JVM is by definition impossible, because the JVM
  itself is not fault-tolerant.

This isn't strictly correct. The article talks about the big difference between the JVM and Erlang being a shared heap vs multiple heaps, but really, it just comes down to coding. There is nothing stopping you from using message passing and immutability in the JVM, and many libraries (eg Scala Actors) do exactly this.

So it's definitely not impossible to build fault tolerance on the JVM.

Also the diagram showing Erlang acting on any number of CPUs while Java is somehow limited to 2 CPUs is simply a marketing lie and is very unnecessary. The JVM can scale happily to any number of CPUs, as it piggy backs off native OS threads, which in linux/windows both scale to any number of CPUs.

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.

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...

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.

Simple question: how could I migrate away from this platform if at one point or another I would get unsatisfied with either the platform or would need this on my own servers? Is there an open-source platform technology? Is this also available as a plain ol' software-as-a-product that I could use on my servers?

CloudI is under an open source software license, the BSD license, which is the most permissive of the open source licenses. So you can use CloudI in any product you want, using it how you want, on whatever servers you choose. The license just protects the CloudI source code developers from liability.

cool. you should write somewhere visible that the underlying technology is os bsd, it's a strong point for someone choosing to use it or not!

This seems like a really interesting approach. I've often wondered what it would be like to live in a world where almost everything could be wrapped in a transaction, and it seems like Cloudl sort of goes in this direction.

In CloudI, each service request is a transaction to be processed (with a UUID that is unique for all service requests among the connected CloudI nodes). Filesystem storage of transactions isn't a goal here, since transactions are expected to die when errors occur within services (http://en.wikipedia.org/wiki/Transaction_processing_system). Instead, database usage through CloudI services (or within a CloudI service) provides persistent storage.

Reply on news.ycombinator.com