Ok, so I get that doing any long/blocking operation from Netty IO thread is a bad idea because it will block Netty's event dispatching from happening.
However I was thinking if doing so is actually a good idea to implement a sort of backpressure mechanism.
Let me explain.
Imagine you're building a client application that uses Netty to connect to a lot of servers of some sort, say http servers, but it doesn't matter. You're querying a lot of servers and you process the responses and maybe even have to do some other network call to pass the result. Imagine that the speed at which you're getting data from all those http servers is much greater then the speed at which you can process them.
Now, in that scenario you could, following the recommendation of not blocking Netty's threads, factor out those time consuming operations and run them on a separate threadpool and that's great, but that threadpool will be hot as the responses are piling up from Netty's IO threads. Soon you'll see OOM if your Executor has an unbounded queue for the tasks.
So then if you actually perform all those costly operations on the IO threads then it could serve as a backpressure mechanism. You will only let Netty go as fast as you're processing rate is..... [EDIT] Alternatively, you could use a blocking queue in your ExecutorService which will have the same effect -> it will block the calling thread when the queue is full [/EDIT]
Does it make sense to do it that way? If not, what would be the recommended way of solving the slow consumer problem in such scenario?