-
Couldn't load subscription status.
- Fork 586
Add Netty-based frame handler #1663
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Better performance? |
Early tests with a simplistic workload showed a 10% increase in throughput but increased latency (compared to blocking IO). With a limited rate 10 K msg / s, the latency is comparable to the blocking IO. The goal is to make Netty the default (and maybe only) IO layer. This way we could get rid of a significant amount of code (our NIO layer) and benefit from Netty flexibility (NIO by default, but also native IO options). |
This commit adds a Netty-based frame handler. All network IO are based on Netty when this frame handler is in use. The client library can benefit of all the flexibility and advantages of Netty: simple API, pluggable IO layer (Java NIO by default, or e.g. native Epoll on Linux). The Netty frame handler deprecates the internal one using Java NIO. The blocking IO frame handler is still the default one in 5.x. The Netty frame handler should be the only one in 6.x. Fixes #1664
6caf2a8 to
74f538d
Compare
This commit adds support for the Netty-based frame handler that was added in RabbitMQ AMQP 091 Java client 5.27.0. New options: * --netty: to activate Netty with the defaults * --netty-threads: to set the number of threads used in the event loop * --netty-epoll: to use the native epoll support (Linux x86-64) * --netty-kqueue: to use the native kqueue support (macOS aarch64) This change also deprecates the options related to Java NIO. References rabbitmq/rabbitmq-java-client#1663 Fixes #856
Part of the back-pressure mechanism. References #1663
Having a method like useNetty() is not necessary as netty() activates Netty as well. Moreover useNetty() does not allow to set the EventLoopGroup, which is essential to configure when using Netty. References #1663 (cherry picked from commit aed8d84) Conflicts: src/main/java/com/rabbitmq/client/ConnectionFactory.java
Having a method like useNetty() is not necessary as netty() activates Netty as well. Moreover useNetty() does not allow to set the EventLoopGroup, which is essential to configure when using Netty. References #1663
Fix back-pressure in Netty frame handler References #1663
For Netty. Make sure that connection shutdown sequence is not executed in the IO event loop if recovery follows. Recovery kicks in the shutdown sequence, so we could end up with a deadlock if the new connection is allocated to the same event loop. References #1663
No need to try to connect if the event loop group was shut down. This also triggers an infinite cycle of connection recovery in the following case: connection disconnected, recovery starts, event loop group closed, new connection attempt, Netty channel created and becomes inactive immediately, recovery restarts, etc. References #1663
No need to try to connect if the event loop group was shut down. This also triggers an infinite cycle of connection recovery in the following case: connection disconnected, recovery starts, event loop group closed, new connection attempt, Netty channel created and becomes inactive immediately, recovery restarts, etc. To avoid the recovery loop, stop recovery when the exception (IllegalStateException) is thrown. References #1663
For Netty. Make sure that connection shutdown sequence is not executed in the IO event loop if recovery follows. Recovery kicks in the shutdown sequence, so we could end up with a deadlock if the new connection is allocated to the same event loop. References #1663 (cherry picked from commit cef9a48) Conflicts: src/main/java/com/rabbitmq/client/impl/Environment.java src/test/java/com/rabbitmq/client/test/TestUtils.java src/test/resources/logback-test.xml
No need to try to connect if the event loop group was shut down. This also triggers an infinite cycle of connection recovery in the following case: connection disconnected, recovery starts, event loop group closed, new connection attempt, Netty channel created and becomes inactive immediately, recovery restarts, etc. To avoid the recovery loop, stop recovery when the exception (IllegalStateException) is thrown. References #1663 (cherry picked from commit 5da2fc3)
No description provided.