Switch to NIO[2] #11
Comments
michaelklishin
changed the title
michaelklishin
changed the title
|
did we get this feature in? |
|
@arunvisw we close issues that are fixed or no longer relevant for other reasons. This one is not closed ;) |
|
Would really appreciate if you can suggest some work arounds |
|
The original thread mentions a workaround. |
|
I were any progress on solving blocks by timeout? |
|
@Hronom I don't understand what "blocks by timeout" means but there is no way to avoid |
|
So switching to NIO helps to solve situation when |
|
@Hronom please get familiar with the original mailing list report. This has no relation to internal flow control (or generally speaking, flow control period). While flow control may make this more visible, it can be reproduced without flow control. |
|
We believe the original issue is addressed in #191 but we'll keep this issue open because switching to NIO is still something we are interested in. |
The current limit may be arbitrary right now (depends on the hardware and the scenario). Write as much as possible in the ByteBuffer before clearing it. Fixes #11
Limit also written frames to the (snapshot) size when iteration starts (instead of unqueuing during writing). Fixes #11
Use NIO by default (except in SSLTests). Fixes #11
And set number of NIO threads a parameter. Fixes #11
Allows to properly handle the first send header request. Fixes #11
Using ByteBuffer-based streams, to avoid duplicating the frame parsing/write logic. Fixes #11
Clean some unused code, handle connection and TLS handshake failure, add configuration hook for SocketChannel, create 'use*' methods to activate NIO or blocking IO. Fixes #11
This test was initially created to reproduce a transient error during the TLS handshake. It looks like this issue was related to Erlang, introduced in 19.x and fixed in 19.1.1 (http://erlang.org/download/OTP-19.1.1.README). Fixes #11
The ExecutorService wasn't closed properly in the base test class, there were thus many threads in park state when running the test suite. This could lead to resource exhaustion, especially on MacOS. Fixes #11
On MacOS, SocketChannel.read() can return EOF when the SocketChannel is closed. On Linux, it would throw an exception. This could lead to spinning threads on MacOS, because the NIO loop was never closed. Fixes #11
The default is to use blocking IO. Fixes #11
And change EOF message, to make it clearer. Fixes #11
Reported and discussed in some depth on rabbitmq-discuss.
Internal bug tracker:
#23327.The only solution is switching to NIO. NIO would yield little improvement for the client the way it works today but worth moving to for this issue.
The text was updated successfully, but these errors were encountered: