Quasar is distributed on top of our own IMDG called Galaxy. Our goal is not to give you scalability, but to give you scalability while keeping familiar and simple programming models. There is absolutely no reason not to use Netty with Quasar. In fact, we're doing exactly that in an internal project.

I've setup 1m connections to a Netty service we host a couple years back, its kinda a fun exercise. I would avoid something like hazelcast if want to do something that palatalized. We used terracotta and the entire concept of a shared memory in a distributed system becomes a major headache.

Can you give some insights on why to avoid Hazelcast or friends for distributed system?

I can give my sample usages. I mainly used it for organizing the cluster automatically, like managing membership, server joining or leaving, maintaining the master server address list. With a distributed hash scheme like Soda, any member server can accept work from any client. Scaling out is very simple, just boot up a machine from an image. It would use Hazelcast to join the cluster and become available.

I also used it for distributing jobs, nice to able to say - queue these jobs and the distributed workers pick them up automatically.

I avoid using it for shared memory stuff, using it like Memcached. That's what Memcached, Redis, and friends are for.

Yes but you're dealing with callbacks then. In the context of the SP, Netty is an example of what they wanted to escape from.