Francesco Nigro

Yep, probably what I really wanted is to save these threads to be created as a whole and let the completions be handled directly on the event loop threads (or...

> Adding the option to e.g use a connection-wide pool of a given fixed size (and where the user is aware that blocking the callbacks in any significant way will...

@gemmellr I've pushed a change that allow using a single connection executor to handle all the sessions completions, although the processing algorithm has been changed to prevent starvation of completion...

@gemmellr I'm going to send a separate commit that handle this same issue in a different way, similar to what https://github.com/apache/qpid-jms/pull/45 has done ie completions are handled by a shared...

> I do specifically want to avoid a default case where users need to end up tweaking thread counts because an entirely legitimate blocking workload is drowning out other stuff...

> Ok. It seemed like you wanted to make it the default. I didn't said it clearly on the PR, but I don't want to break existing users code :)...

Yep, but if people decide to use 100 connections, why they should have 100 separate completion thread pools? I was thinking about a proper shared approach really that span across...

I've sent a change that it's introducing `HolderSuppliers` (bad name, so happy to receive feedbacks/suggestions) and `SharedDisposable` as a util that could be used on https://github.com/apache/qpid-jms/pull/45 to handle shared disposable/pre-configured...

I see that a version that just handle one completion task at time to guarantee FJ to handle fairness of completions isn't working that bad, really, but I need to...

@gemmellr @tabish121 I'm not very proud to have exposed directly the ByteBuf streams, but I have tried to use the right type on the facade and it makes the code...