An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.

[andrewbanchich]

Running on Windows 10, I am getting this backtrace. I'm using surf which uses isahc under the hood.

Is backpressure something isahc / surf should be handling, or should I be handling this in my own code?

  thread ' tokio-runtime-worker-50' panicked at ': called `Result::unwrap()` on an `Err` value: Io(Os { code: 10055, kind: Other, message: "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full." })backtrace::backtrace::trace_unsynchronized',
src\libcore\result.rs             at :C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.37\src\backtrace\mod.rs1165::665

   1: std::sys_common::backtrace::_print_fmt
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\sys_common\backtrace.rs:76
   2: std::sys_common::backtrace::_print::{{impl}}::fmt
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\sys_common\backtrace.rs:60
   3: core::fmt::write
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libcore\fmt\mod.rs:1030
   4: std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\io\mod.rs:1412
   5: std::sys_common::backtrace::_print
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\sys_common\backtrace.rs:64
   6: std::sys_common::backtrace::print
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\sys_common\backtrace.rs:49
   7: std::panicking::default_hook::{{closure}}
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:196
   8: std::panicking::default_hook
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:210
   9: std::panicking::rust_panic_with_hook
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:473
  10: std::panicking::continue_panic_fmt
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:380
  11: std::panicking::rust_begin_panic
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:307
  12: core::panicking::panic_fmt
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libcore\panicking.rs:85
  13: core::result::unwrap_failed
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libcore\result.rs:1165
  14: surf::http_client::isahc::IsahcClient::new
  15: surf::request::Request<surf::http_client::isahc::IsahcClient>::new
  16: surf::one_off::get
  17: my_program::consumer::process_task::{{closure}}::{{closure}}
  18: <tracing_futures::Instrumented<T> as core::future::future::Future>::poll
  19: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  20: std::panicking::try::do_call
  21: panic_unwind::__rust_maybe_catch_panic
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libpanic_unwind\lib.rs:80
  22: tokio_executor::threadpool::task::Task::run
  23: tokio_executor::threadpool::worker::Worker::run
  24: tokio_executor::threadpool::worker::Worker::run
  25: tracing_core::dispatcher::with_default
  26: std::thread::local::LocalKey<T>::with
  27: <crossbeam_channel::flavors::array::Channel<T> as core::ops::drop::Drop>::drop
  28: std::thread::local::LocalKey<T>::with

[sagebind]

I think Surf is calling unwrap in a manner that makes this difficult. Creating a new Isahc client is not a cheap operation, and could fail with the error you are seeing if creating one more socket can't be done.

If you are making more than just a few requests, I recommend creating a surf::Client once and re-using that, instead of using the freestanding functions, which create a new client for each request.

[andrewbanchich]

That works, thanks!