Slashdot Mirror

How is this different from Akka?

I know somebody that tried this. At around 5000 threads he got no real progress whatsoever anymore.That was a while back, but at that time Java was already a few years old.

The thread limitation comes from the operating system, not from the Java virtual machine. Modern operating systems are not designed to handle a huge amount of parallel threads. The handling of the threads and the synchronization between the threads usually eats up most of the system's resources.

The Java VM indeed has some shortcomings regarding mutli processing: when using multiple cores on the same socket, the Java VM sometimes accesses the same cache lines from all cores. This leads to strange patterns with cache invalidation and slows down all the affected cores. Currently there is no way to mitigate this using Java APIs or VM parameters. But this is a very special problem. When this is indeed the bottleneck, the underlying application is very likely already very well optimized and running quite fast.

If you want to process a huge amount of data, currently the best approach is to run exactly as much threads as you have processor cores. Then you feed each thread with working tasks, using non blocking data structures. For the communication, the threads should use non-blocking IO. Java is prepared extremely well for this scenario, perhaps even better than node.js. Examples are Vert.x and Akka. In some older benchmarks, Vert.x had no problem to serve over 300'000 parallel requests per second on a six core machine.

Edited on on 18:05 Wednesday 17 September 2014: fixed some typos.

I don't know why people keep submitting this garbage from Espresso Logic, who is just taking advantage of the fact the the term "reactive" has been overloaded to mean different things to exploit the hype surrounding the Reactive Manifesto and related technologies (e.g., Akka, Rx, Node.js, etc.) to push their own, completely unrelated product, which is based on the more traditional (i.e., the one you find in Wikipedia) definition of "Reactive Programming".

"Reactive programming", as defined by the Reactive Manifesto (which is what all the hype is about), is about designing applications that operate in an entirely asynchronous and non-blocking manner, so as to maximize CPU utilization and fully exploit parallelism, and ensure that the system is always responsive to new events (user input, incoming data streams, errors, changes in load, etc.) rather than having resources tied up waiting for external processes (e.g., blocking on I/O). It has nothing to do with "reactive databases".

LinkedIn uses it for their mobile backend.
But I more than suspect that the mobile backend is just a simple frontend to the real backend. And that is written mainly in Scala.

As far as I know the closest thing to node.js in Scala would be something like Finagle, which they use at twitter:
http://twitter.github.io/scala_school/

For my current hobby project the backend is written in Scala, Akka and Play! - though I am considering replacing Play with Spray, since all the backed does is serving JSON from REST services.

http://akka.io/
http://spray.io/

I haven't played much with concurrency and multi-threading in Java, but I think Java Futures (sounds like an investment vehicle, but I think it's the feature you want) fit the bill: http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Future.html

In terms of other convenient methods for doing lots of concurrent work, there's the Akka project under the Apache 2 license: http://akka.io/ It is supposed to be a pretty decent implementation of the Actor concurrency model for Java and Scala ( https://en.wikipedia.org/wiki/Actor_model )

The Scala community has tried to move the problem into a more practical realm by adding things like parallel collections, DSL's to abstract out the problem for specific applications and the Akka Project for simpler concurrency.

Most of the parallel programming discussion I've seen is very complicated and not likely to appeal to those who have to do practical day-to-day business projects. By pushing the abstractions up a level, I think the Scala folks have made parallel programming more accessible for the average developer.

Ref: Parallel Collections video.