Question

Frustratingly, HawtDispatch’s website describes it as “thread pooling and NIO event notification framework API.”

Let’s take the ‘thread pooling’ part first. Most of the Executors provided by Java are also basically thread pools. How is HawtDispatch different?

It is also apparently an “NIO event notification framework API.” I’m assuming it is a thin layer on top NIO which takes incoming data and passes to its notion of ‘thread pool,’ and passes it to a consumer when the thread pool scheduler finds the time. Correct? (Any improvement over NIO is welcomed). Has anyone done any performance analysis of netty vs HD?

Answer 1

HawtDispatch is designed to be a single system wide fixed size thread pool. It provides implements 2 flavors of Java Executors:

• Global Dispatch Queue: Submitted Runnable objects are executed concurrently (You get the same effect using a Executors.newFixedThreadPool(n) executor)
• Serial Dispatch Queue: Submitted Runnable objects are executed serially (You get the same effect using a Executors.newSingleThreadExecutor() executor)

Unlike the java executor model all global and serial dispatch queues share a single fixed size thread pool. You can use thousands of serial dispatch queues without increasing your thread count. Serial dispatch queues can be used like Erlang mailboxes to drive reactive actor style applications.

Since HawtDispatch is using a fixed size thread pool for processing all global and serial queue executions, all Runnable tasks it executes must be non-blocking. In a way this is similar to the NodeJS architecture except it using multiple threads instead of just one.

In comparison to Netty, HawtDispatch is not a framework for actually processing socket data. It does not provide a framework for how encode/decode, buffer and process the socket data. All it does is execute a user configured Runnable when data can be read or written on the non-blocking socket. It’s up to you application then to actually read/write the socket data.