-
Notifications
You must be signed in to change notification settings - Fork 342
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
TcpListener::incoming fails to receive new connections #888
Comments
I believe that this affects Tide as well, as we tried Tide a couple of days ago and it worked well, but no one in our team (Mac & Linux) can make it work today. It keeps frozen on accepting the connection:
|
Same for me. Reverting from async-std 1.6.4 to 1.6.3 fixed it |
Taking a look at this impl, it seems like it's calling async-std/src/net/tcp/listener.rs Lines 188 to 198 in e812663
In fact, async-io has had a commit with the message Unregister wakers if readable() or writable() is canceled since the latest release, so it sounds likely to me. |
@Darksonn can you file an issue on Though we can probably duplicate the |
Sure! Done in smol-rs/async-io#30. |
|
Prevent users from using v1.6.4 which faces issues receiving incoming TCP connections. See async-rs/async-std#888 for details.
* *: Bump async-std to v1.6.5 Prevent users from using v1.6.4 which faces issues receiving incoming TCP connections. See async-rs/async-std#888 for details. * client/network/src/gossip: Use channel instead of condvar `async_std::sync::Condvar::wait_timeout` uses `gloo_timers::callback::Timeout` when compiled for `wasm32-unknown-unknown`. This timeout implementation does not fulfill the requirement of being `Send`. Instead of using a `Condvar` use a `futures::channel::mpsc` to signal progress from the `QueuedSender` to the background `Future`. * client/network/Cargo.toml: Remove async-std unstable feature * client/network/src/gossip: Forward all queued messages * client/network/gossip: Have QueuedSender methods take &mut self * client/network/gossip: Move queue_size_limit into QueuedSender The `queue_size_limit` field is only accessed by `QueuedSender`, thus there is no need to share it between the background future and the `QueuedSender`. * client/network/gossip: Rename background task to future To be a bit picky the background task is not a task in the sense of an asynchonous task, but rather a background future in the sense of `futures::future::Future`.
* *: Bump async-std to v1.6.5 Prevent users from using v1.6.4 which faces issues receiving incoming TCP connections. See async-rs/async-std#888 for details. * client/network/src/gossip: Use channel instead of condvar `async_std::sync::Condvar::wait_timeout` uses `gloo_timers::callback::Timeout` when compiled for `wasm32-unknown-unknown`. This timeout implementation does not fulfill the requirement of being `Send`. Instead of using a `Condvar` use a `futures::channel::mpsc` to signal progress from the `QueuedSender` to the background `Future`. * client/network/Cargo.toml: Remove async-std unstable feature * client/network/src/gossip: Forward all queued messages * client/network/gossip: Have QueuedSender methods take &mut self * client/network/gossip: Move queue_size_limit into QueuedSender The `queue_size_limit` field is only accessed by `QueuedSender`, thus there is no need to share it between the background future and the `QueuedSender`. * client/network/gossip: Rename background task to future To be a bit picky the background task is not a task in the sense of an asynchonous task, but rather a background future in the sense of `futures::future::Future`.
* Fixes logging of target names with dashes (#7281) * Fixes logging of target names with dashes There was a bug in tracing-core which resulted in not supporting dashes in target names. This was fixed upstream. Besides that a test was added to ensure that we don't break this again. * Extend test * client: fix log filters (#7241) * client: fix multiple logger filters * client: add test for log filters setup * Fix logging from inside the WASM runtime (#7355) * Fix logging from inside the WASM runtime When using `RuntimeLogger` to log something from the runtime, we didn't set any logging level. So, we actually did not log anything from the runtime as logging is disabled by default. This pr fixes that by setting the logging level to `TRACE`. It also adds a test to ensure this does not break again ;) * Update frame/support/src/debug.rs * Print an error if an unregistered notifications protocol is used (#7457) * Print an error if an nregistered notifications protocol is used * Print an error if an nregistered notifications protocol is used * Update client/network/src/service.rs Co-authored-by: Bastian Köcher <[email protected]> * Fix wrong outgoing calculation in election (#7384) * Fix wrong outgoing calculation in election * Add test. * Lil bit better naming. * grandpa: fix tests * *: Bump async-std to v1.6.5 (#7306) * *: Bump async-std to v1.6.5 Prevent users from using v1.6.4 which faces issues receiving incoming TCP connections. See async-rs/async-std#888 for details. * client/network/src/gossip: Use channel instead of condvar `async_std::sync::Condvar::wait_timeout` uses `gloo_timers::callback::Timeout` when compiled for `wasm32-unknown-unknown`. This timeout implementation does not fulfill the requirement of being `Send`. Instead of using a `Condvar` use a `futures::channel::mpsc` to signal progress from the `QueuedSender` to the background `Future`. * client/network/Cargo.toml: Remove async-std unstable feature * client/network/src/gossip: Forward all queued messages * client/network/gossip: Have QueuedSender methods take &mut self * client/network/gossip: Move queue_size_limit into QueuedSender The `queue_size_limit` field is only accessed by `QueuedSender`, thus there is no need to share it between the background future and the `QueuedSender`. * client/network/gossip: Rename background task to future To be a bit picky the background task is not a task in the sense of an asynchonous task, but rather a background future in the sense of `futures::future::Future`. * client/network: Remove option to disable yamux flow control (#7358) With the `OnRead` flow control option yamux "send[s] window updates only when data is read on the receiving end" and not as soon as "a Stream's receive window drops to 0". Yamux flow control has proven itself. This commit removes the feature flag. Yamux flow control is now always enabled. * Make `queryStorage` and `storagePairs` unsafe RPC functions (#7342) The RPC calls can be rather expensive and can easily bring a RPC node in some problems ;) * consensus: prioritize finality work over block import in queue (#7307) * consensus: prioritize finality work over block import in queue * consensus: add test for import queue task priority * sync: only restart peers not doing finality related requests (#7322) * sync: only restart peers not doing finality related requests * sync: add test for sync restart * sync: add better docs to restart method * Undo phragmen merge * grandpa: fix early enactment of forced changes (#7321) * grandpa: fix early enactment of forced authority set changes * grandpa: add test for early enactment of forced changes * grandpa: fix typo in log message * grandpa: only allow one pending forced change per fork * grandpa: fix tests Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: André Silva <[email protected]> Co-authored-by: Pierre Krieger <[email protected]> Co-authored-by: Kian Paimani <[email protected]> Co-authored-by: André Silva <[email protected]> Co-authored-by: Max Inden <[email protected]>
Based on this question, it appears that there is some issue with the
incoming
stream onTcpListener
.This example does not print anything when new connections are made to that
TcpListener
, e.g. withnc 127.0.0.1 4444
. My guess is that it is somehow failing to send notifications to the waker.It works when fine rewritten to use
accept
in a loop.The text was updated successfully, but these errors were encountered: