Executor Threads

[Ori S]

Hi again,

I'm working on a REST backend and need to inquire whether it's possible to use RestExpress's/Netty's executor threads for my own use?

Background: The server sometimes serves requests fast while the main work in done on a thread.

My question is whether I can use one of the executor threads in order to carry out these tasks, or I have to create my own executor threads and use those?

Thanks.

/OS

[Todd Fredrich]

Hello again! Thanks for your question.

If you haven't seen it already, there is a diagram of how RestExpress uses the Netty I/O & executor thread pool and a little article about it here: https://github.com/RestExpress/RestExpress/wiki/Thread-Pool-and-I-O-Flow

As far as using the executor pool to perform tasks, if configured, RestExpress (Netty actually) will put the controller method execution on an executor and distribute multiple requests across the pool so there's nothing more to do.

However, if you're in need of additional threads to perform many things within a single request, then you'll need to spin up and manage your own executor pool. But, as you well know, that can be challenging.

I hope this helps,

--Todd

[Ori S]

Yeah, I actually saw that diagram and read the whole explanation. And that's why I opted to asking eventually.

Based on my research, there isn't a public (even a protected) method to dispatch work to the executor thread pool. Of course, as you suggested, spinning one is my last resort (which I already took) but I was wondering if there's a good reason why this couldn't be possibly incorporated into RestExpress? Either as part of the existing pool or as an auxiliary caching/recycling thread pool which is started on first use.

Just my 2 cents. I'd be interested to hear your thoughts about it.

/OS

[Todd Fredrich]

Thanks for the reply, Ori.

Basically, there are two reasons why RestExpress doesn't support that feature:

1) Netty is actually managing the executor pool and I don't want to mess with it and accidentally get something wrong.

2) Multi-threaded code is hard and, therefore, easy to get wrong. My general rule for myself in application code is, "If you're writing multi-threaded code, it's wrong." So I don't do it--I rely on a framework to do it for me.

I don't know what you're trying to accomplish, but it sounds like you may be well served to either use Java8 async features such as Futures or maybe use a domain-based messaging pattern (Erik Evans talks about the concept of Domain Eventing in his Domain Driven Design book). For this kind of thing when I don't want to spin up a whole messaging infrastructure, like JMS, I use my Domain-Eventing library: https://github.com/tfredrich/Domain-Eventing (or something like it).  This library manages another executor thread pool for the message handlers so I don't have to do it in my application code--it's been well peer reviewed and if it's broken I only have to fix it in one place.

The above-mentioned library either uses a local queue to message within a single JVM or can use Akka to message across multiple VMs. It also supports Hazelcast to message across VMs.