Francesco Nigro
Francesco Nigro
https://issues.apache.org/jira/browse/ARTEMIS-3050
https://issues.apache.org/jira/browse/ARTEMIS-3163
That's a follow-up issue of https://github.com/open-telemetry/opentelemetry-java/issues/2968 Same purpose, but as mentioned on https://github.com/open-telemetry/opentelemetry-java/issues/2968#issuecomment-864370074 I see that the referenced commit is using a CLQ with a separate size tracker to overcome...
Motivation: `SimpleConnectionPool` is backed by a `CombinerExecutor` that can be caught in a tight (potentially endless) loop while consuming (and executing) actions, occupying its current running event loop for too...
I'm implementing support for https://github.com/netty/netty-incubator-transport-io_uring on Vert-x `Transport`, see https://github.com/franz1981/vert.x/tree/4.2.1_iouring for some initial experiment.
Fixes #4163
InboundBuffer's allocation create 16 pending entries by default while it could delay it when the initial size information is available. This change is going to lazy allocate it: it's less...
Allow users to define Netty event loop threads cores affinity. Given that Vert-x use long-living threads bound to specific selectors, being able to bind it to a specific core can...
This is using a separate size atomic counter. Potential improvements (need benchmarks to spot if makes sense to push this that far): - using separate queue add/remove counters using different...