public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
* [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections
@ 2020-11-03 12:26 Dietmar Maurer
  2020-11-03 12:51 ` Dominik Csapak
  2020-11-03 13:05 ` Wolfgang Bumiller
  0 siblings, 2 replies; 8+ messages in thread
From: Dietmar Maurer @ 2020-11-03 12:26 UTC (permalink / raw)
  To: pve-devel

---

 based, on Domink's patch, but with the following changes:

 - factor out code into separate function accept_connections()
 - no select with shutdown future (no needed)
 - remove sender2.send_timeout() - not sure why this was there?
 - restict number of spawned tasks

 Seems to work, but I get many handshake errors when connetion
 with the GUI:

 > https handshake failed - the handshake failed: unexpected EOF

 This is because of pve status ping (Thomas will fix that in pve)

 But I am not sure why I get the following?
 
 > https handshakeX failed - the handshake failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:../ssl/record/rec_layer_s3.c:1544:SSL alert number 46


 src/bin/proxmox-backup-proxy.rs | 81 ++++++++++++++++++++++++++-------
 1 file changed, 64 insertions(+), 17 deletions(-)

diff --git a/src/bin/proxmox-backup-proxy.rs b/src/bin/proxmox-backup-proxy.rs
index 78ea4d53..1f0c16b4 100644
--- a/src/bin/proxmox-backup-proxy.rs
+++ b/src/bin/proxmox-backup-proxy.rs
@@ -1,4 +1,4 @@
-use std::sync::{Arc};
+use std::sync::{Arc, atomic::{AtomicUsize, Ordering}};
 use std::path::{Path, PathBuf};
 use std::os::unix::io::AsRawFd;
 
@@ -116,25 +116,12 @@ async fn run() -> Result<(), Error> {
     let server = daemon::create_daemon(
         ([0,0,0,0,0,0,0,0], 8007).into(),
         |listener, ready| {
-            let connections = proxmox_backup::tools::async_io::StaticIncoming::from(listener)
-                .map_err(Error::from)
-                .try_filter_map(move |(sock, _addr)| {
-                    let acceptor = Arc::clone(&acceptor);
-                    async move {
-                        sock.set_nodelay(true).unwrap();
-
-                        let _ = set_tcp_keepalive(sock.as_raw_fd(), PROXMOX_BACKUP_TCP_KEEPALIVE_TIME);
 
-                        Ok(tokio_openssl::accept(&acceptor, sock)
-                            .await
-                            .ok() // handshake errors aren't be fatal, so return None to filter
-                        )
-                    }
-                });
-            let connections = proxmox_backup::tools::async_io::HyperAccept(connections);
+            let connections = accept_connections(listener, acceptor);
+            let connections = hyper::server::accept::from_stream(connections);
 
             Ok(ready
-                .and_then(|_| hyper::Server::builder(connections)
+               .and_then(|_| hyper::Server::builder(connections)
                     .serve(rest_server)
                     .with_graceful_shutdown(server::shutdown_future())
                     .map_err(Error::from)
@@ -170,6 +157,66 @@ async fn run() -> Result<(), Error> {
     Ok(())
 }
 
+fn accept_connections(
+    mut listener: tokio::net::TcpListener,
+    acceptor: Arc<openssl::ssl::SslAcceptor>,
+) -> tokio::sync::mpsc::Receiver<Result<tokio_openssl::SslStream<tokio::net::TcpStream>, Error>> {
+
+    let (sender, receiver) = tokio::sync::mpsc::channel(100);
+
+    let accept_counter = Arc::new(AtomicUsize::new(0));
+
+    const MAX_PENDING_ACCEPTS: usize = 100;
+
+    tokio::spawn(async move {
+        loop {
+            match listener.accept().await {
+                Err(err) => {
+                    eprintln!("error accepting tcp connection: {}", err);
+                }
+                Ok((sock, _addr)) =>  {
+                    sock.set_nodelay(true).unwrap();
+                    let _ = set_tcp_keepalive(sock.as_raw_fd(), PROXMOX_BACKUP_TCP_KEEPALIVE_TIME);
+                    let acceptor = Arc::clone(&acceptor);
+                    let mut sender = sender.clone();
+
+                    if accept_counter.load(Ordering::SeqCst) > MAX_PENDING_ACCEPTS {
+                        eprintln!("connection rejected - to many open connections");
+                        continue;
+                    }
+                    accept_counter.fetch_add(1, Ordering::SeqCst);
+
+                    let accept_counter = accept_counter.clone();
+                    tokio::spawn(async move {
+                        let accept_future = tokio::time::timeout(
+                            Duration::new(10, 0), tokio_openssl::accept(&acceptor, sock));
+
+                        let result = accept_future.await;
+
+                        match result {
+                            Ok(Ok(connection)) => {
+                                if let Err(_) = sender.send(Ok(connection)).await {
+                                    eprintln!("detect closed connection channel");
+                                }
+                            }
+                            Ok(Err(err)) => {
+                                eprintln!("https handshakeX failed - {}", err);
+                            }
+                            Err(_) => {
+                                eprintln!("https handshake timeout");
+                            }
+                        }
+
+                        accept_counter.fetch_sub(1, Ordering::SeqCst);
+                    });
+                }
+            }
+        }
+    });
+
+    receiver
+}
+
 fn start_stat_generator() {
     let abort_future = server::shutdown_future();
     let future = Box::pin(run_stat_generator());
-- 
2.20.1




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections
  2020-11-03 12:26 [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections Dietmar Maurer
@ 2020-11-03 12:51 ` Dominik Csapak
  2020-11-03 13:05 ` Wolfgang Bumiller
  1 sibling, 0 replies; 8+ messages in thread
From: Dominik Csapak @ 2020-11-03 12:51 UTC (permalink / raw)
  To: pve-devel

looks better than mine :)

comment inline

On 11/3/20 1:26 PM, Dietmar Maurer wrote:
> ---
> 
>   based, on Domink's patch, but with the following changes:
> 
>   - factor out code into separate function accept_connections()
>   - no select with shutdown future (no needed)
>   - remove sender2.send_timeout() - not sure why this was there?
>   - restict number of spawned tasks
> 
>   Seems to work, but I get many handshake errors when connetion
>   with the GUI:
> 
>   > https handshake failed - the handshake failed: unexpected EOF
> 
>   This is because of pve status ping (Thomas will fix that in pve)
> 
>   But I am not sure why I get the following?
>   
>   > https handshakeX failed - the handshake failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:../ssl/record/rec_layer_s3.c:1544:SSL alert number 46

i got that too, my guess was that the browser tries with client 
certificates?

> 
> 
>   src/bin/proxmox-backup-proxy.rs | 81 ++++++++++++++++++++++++++-------
>   1 file changed, 64 insertions(+), 17 deletions(-)
> 
> diff --git a/src/bin/proxmox-backup-proxy.rs b/src/bin/proxmox-backup-proxy.rs
> index 78ea4d53..1f0c16b4 100644
> --- a/src/bin/proxmox-backup-proxy.rs
> +++ b/src/bin/proxmox-backup-proxy.rs
> @@ -1,4 +1,4 @@
> -use std::sync::{Arc};
> +use std::sync::{Arc, atomic::{AtomicUsize, Ordering}};
>   use std::path::{Path, PathBuf};
>   use std::os::unix::io::AsRawFd;
>   
> @@ -116,25 +116,12 @@ async fn run() -> Result<(), Error> {
>       let server = daemon::create_daemon(
>           ([0,0,0,0,0,0,0,0], 8007).into(),
>           |listener, ready| {
> -            let connections = proxmox_backup::tools::async_io::StaticIncoming::from(listener)
> -                .map_err(Error::from)
> -                .try_filter_map(move |(sock, _addr)| {
> -                    let acceptor = Arc::clone(&acceptor);
> -                    async move {
> -                        sock.set_nodelay(true).unwrap();
> -
> -                        let _ = set_tcp_keepalive(sock.as_raw_fd(), PROXMOX_BACKUP_TCP_KEEPALIVE_TIME);
>   
> -                        Ok(tokio_openssl::accept(&acceptor, sock)
> -                            .await
> -                            .ok() // handshake errors aren't be fatal, so return None to filter
> -                        )
> -                    }
> -                });
> -            let connections = proxmox_backup::tools::async_io::HyperAccept(connections);
> +            let connections = accept_connections(listener, acceptor);
> +            let connections = hyper::server::accept::from_stream(connections);
>   
>               Ok(ready
> -                .and_then(|_| hyper::Server::builder(connections)
> +               .and_then(|_| hyper::Server::builder(connections)
>                       .serve(rest_server)
>                       .with_graceful_shutdown(server::shutdown_future())
>                       .map_err(Error::from)
> @@ -170,6 +157,66 @@ async fn run() -> Result<(), Error> {
>       Ok(())
>   }
>   
> +fn accept_connections(
> +    mut listener: tokio::net::TcpListener,
> +    acceptor: Arc<openssl::ssl::SslAcceptor>,
> +) -> tokio::sync::mpsc::Receiver<Result<tokio_openssl::SslStream<tokio::net::TcpStream>, Error>> {
> +
> +    let (sender, receiver) = tokio::sync::mpsc::channel(100);
> +
> +    let accept_counter = Arc::new(AtomicUsize::new(0));
> +
> +    const MAX_PENDING_ACCEPTS: usize = 100;
> +
> +    tokio::spawn(async move {
> +        loop {
> +            match listener.accept().await {
> +                Err(err) => {
> +                    eprintln!("error accepting tcp connection: {}", err);
> +                }
> +                Ok((sock, _addr)) =>  {
> +                    sock.set_nodelay(true).unwrap();
> +                    let _ = set_tcp_keepalive(sock.as_raw_fd(), PROXMOX_BACKUP_TCP_KEEPALIVE_TIME);
> +                    let acceptor = Arc::clone(&acceptor);
> +                    let mut sender = sender.clone();
> +
> +                    if accept_counter.load(Ordering::SeqCst) > MAX_PENDING_ACCEPTS {
> +                        eprintln!("connection rejected - to many open connections");
> +                        continue;
> +                    }
> +                    accept_counter.fetch_add(1, Ordering::SeqCst);
> +
> +                    let accept_counter = accept_counter.clone();
> +                    tokio::spawn(async move {
> +                        let accept_future = tokio::time::timeout(
> +                            Duration::new(10, 0), tokio_openssl::accept(&acceptor, sock));
> +
> +                        let result = accept_future.await;
> +
> +                        match result {
> +                            Ok(Ok(connection)) => {
> +                                if let Err(_) = sender.send(Ok(connection)).await {
> +                                    eprintln!("detect closed connection channel");
> +                                }
> +                            }
> +                            Ok(Err(err)) => {
> +                                eprintln!("https handshakeX failed - {}", err);
> +                            }
> +                            Err(_) => {
> +                                eprintln!("https handshake timeout");
> +                            }
> +                        }
> +
> +                        accept_counter.fetch_sub(1, Ordering::SeqCst);
> +                    });
> +                }
> +            }
> +        }
> +    });
> +
> +    receiver
> +}
> +
>   fn start_stat_generator() {
>       let abort_future = server::shutdown_future();
>       let future = Box::pin(run_stat_generator());
> 




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections
  2020-11-03 12:26 [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections Dietmar Maurer
  2020-11-03 12:51 ` Dominik Csapak
@ 2020-11-03 13:05 ` Wolfgang Bumiller
  2020-11-03 13:25   ` Dietmar Maurer
  2020-11-03 17:45   ` Dietmar Maurer
  1 sibling, 2 replies; 8+ messages in thread
From: Wolfgang Bumiller @ 2020-11-03 13:05 UTC (permalink / raw)
  To: Dietmar Maurer; +Cc: pve-devel

generally ACKed, but I have some notes:

On Tue, Nov 03, 2020 at 01:26:36PM +0100, Dietmar Maurer wrote:
> ---
> 
>  based, on Domink's patch, but with the following changes:
> 
>  - factor out code into separate function accept_connections()
>  - no select with shutdown future (no needed)
>  - remove sender2.send_timeout() - not sure why this was there?
>  - restict number of spawned tasks
> 
>  Seems to work, but I get many handshake errors when connetion
>  with the GUI:
> 
>  > https handshake failed - the handshake failed: unexpected EOF
> 
>  This is because of pve status ping (Thomas will fix that in pve)
> 
>  But I am not sure why I get the following?
>  
>  > https handshakeX failed - the handshake failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:../ssl/record/rec_layer_s3.c:1544:SSL alert number 46
> 
> 
>  src/bin/proxmox-backup-proxy.rs | 81 ++++++++++++++++++++++++++-------
>  1 file changed, 64 insertions(+), 17 deletions(-)
> 
> diff --git a/src/bin/proxmox-backup-proxy.rs b/src/bin/proxmox-backup-proxy.rs
> index 78ea4d53..1f0c16b4 100644
> --- a/src/bin/proxmox-backup-proxy.rs
> +++ b/src/bin/proxmox-backup-proxy.rs
> @@ -1,4 +1,4 @@
> -use std::sync::{Arc};
> +use std::sync::{Arc, atomic::{AtomicUsize, Ordering}};
>  use std::path::{Path, PathBuf};
>  use std::os::unix::io::AsRawFd;
>  
> @@ -116,25 +116,12 @@ async fn run() -> Result<(), Error> {
>      let server = daemon::create_daemon(
>          ([0,0,0,0,0,0,0,0], 8007).into(),
>          |listener, ready| {
> -            let connections = proxmox_backup::tools::async_io::StaticIncoming::from(listener)
> -                .map_err(Error::from)
> -                .try_filter_map(move |(sock, _addr)| {
> -                    let acceptor = Arc::clone(&acceptor);
> -                    async move {
> -                        sock.set_nodelay(true).unwrap();
> -
> -                        let _ = set_tcp_keepalive(sock.as_raw_fd(), PROXMOX_BACKUP_TCP_KEEPALIVE_TIME);
>  
> -                        Ok(tokio_openssl::accept(&acceptor, sock)
> -                            .await
> -                            .ok() // handshake errors aren't be fatal, so return None to filter
> -                        )
> -                    }
> -                });
> -            let connections = proxmox_backup::tools::async_io::HyperAccept(connections);
> +            let connections = accept_connections(listener, acceptor);
> +            let connections = hyper::server::accept::from_stream(connections);

If we move the `from_stream` into the function below...

>  
>              Ok(ready
> -                .and_then(|_| hyper::Server::builder(connections)
> +               .and_then(|_| hyper::Server::builder(connections)
>                      .serve(rest_server)
>                      .with_graceful_shutdown(server::shutdown_future())
>                      .map_err(Error::from)
> @@ -170,6 +157,66 @@ async fn run() -> Result<(), Error> {
>      Ok(())
>  }
>  
> +fn accept_connections(
> +    mut listener: tokio::net::TcpListener,
> +    acceptor: Arc<openssl::ssl::SslAcceptor>,
> +) -> tokio::sync::mpsc::Receiver<Result<tokio_openssl::SslStream<tokio::net::TcpStream>, Error>> {

... then this could probably be shortened to

    ) -> impl Accept {

shortens the line by 80 ;-)

> +
> +    let (sender, receiver) = tokio::sync::mpsc::channel(100);
> +
> +    let accept_counter = Arc::new(AtomicUsize::new(0));
> +
> +    const MAX_PENDING_ACCEPTS: usize = 100;
> +
> +    tokio::spawn(async move {
> +        loop {
> +            match listener.accept().await {
> +                Err(err) => {
> +                    eprintln!("error accepting tcp connection: {}", err);
> +                }
> +                Ok((sock, _addr)) =>  {
> +                    sock.set_nodelay(true).unwrap();
> +                    let _ = set_tcp_keepalive(sock.as_raw_fd(), PROXMOX_BACKUP_TCP_KEEPALIVE_TIME);
> +                    let acceptor = Arc::clone(&acceptor);
> +                    let mut sender = sender.clone();
> +
> +                    if accept_counter.load(Ordering::SeqCst) > MAX_PENDING_ACCEPTS {
> +                        eprintln!("connection rejected - to many open connections");
> +                        continue;
> +                    }
> +                    accept_counter.fetch_add(1, Ordering::SeqCst);

We should think about making a counter guard for this sort of thing,
because from this point onward we're not allowed to use `?` anywhere,
which is quite annoying.

> +
> +                    let accept_counter = accept_counter.clone();
> +                    tokio::spawn(async move {
> +                        let accept_future = tokio::time::timeout(
> +                            Duration::new(10, 0), tokio_openssl::accept(&acceptor, sock));
> +
> +                        let result = accept_future.await;
> +
> +                        match result {
> +                            Ok(Ok(connection)) => {
> +                                if let Err(_) = sender.send(Ok(connection)).await {
> +                                    eprintln!("detect closed connection channel");
> +                                }
> +                            }
> +                            Ok(Err(err)) => {
> +                                eprintln!("https handshakeX failed - {}", err);
> +                            }
> +                            Err(_) => {
> +                                eprintln!("https handshake timeout");
> +                            }
> +                        }

which is why I'd rather thave the part above in its own `async fn`
followed by the `fetch_sub` below, followed by the `eprintln!()`s.

> +
> +                        accept_counter.fetch_sub(1, Ordering::SeqCst);
> +                    });
> +                }
> +            }
> +        }
> +    });
> +
> +    receiver
> +}
> +
>  fn start_stat_generator() {
>      let abort_future = server::shutdown_future();
>      let future = Box::pin(run_stat_generator());
> -- 
> 2.20.1




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections
  2020-11-03 13:05 ` Wolfgang Bumiller
@ 2020-11-03 13:25   ` Dietmar Maurer
  2020-11-03 14:15     ` Wolfgang Bumiller
  2020-11-03 17:45   ` Dietmar Maurer
  1 sibling, 1 reply; 8+ messages in thread
From: Dietmar Maurer @ 2020-11-03 13:25 UTC (permalink / raw)
  To: Wolfgang Bumiller; +Cc: pve-devel

> > -            let connections = proxmox_backup::tools::async_io::HyperAccept(connections);
> > +            let connections = accept_connections(listener, acceptor);
> > +            let connections = hyper::server::accept::from_stream(connections);
> 
> If we move the `from_stream` into the function below...

I have tried to do that for 2 hours, then gave up....
So please tell m e how to make that work!

> >  
> >              Ok(ready
> > -                .and_then(|_| hyper::Server::builder(connections)
> > +               .and_then(|_| hyper::Server::builder(connections)
> >                      .serve(rest_server)
> >                      .with_graceful_shutdown(server::shutdown_future())
> >                      .map_err(Error::from)
> > @@ -170,6 +157,66 @@ async fn run() -> Result<(), Error> {
> >      Ok(())
> >  }
> >  
> > +fn accept_connections(
> > +    mut listener: tokio::net::TcpListener,
> > +    acceptor: Arc<openssl::ssl::SslAcceptor>,
> > +) -> tokio::sync::mpsc::Receiver<Result<tokio_openssl::SslStream<tokio::net::TcpStream>, Error>> {
> 
> ... then this could probably be shortened to
> 
>     ) -> impl Accept {
> 
> shortens the line by 80 ;-)
> 
> > +
> > +    let (sender, receiver) = tokio::sync::mpsc::channel(100);
> > +
> > +    let accept_counter = Arc::new(AtomicUsize::new(0));
> > +
> > +    const MAX_PENDING_ACCEPTS: usize = 100;
> > +
> > +    tokio::spawn(async move {
> > +        loop {
> > +            match listener.accept().await {
> > +                Err(err) => {
> > +                    eprintln!("error accepting tcp connection: {}", err);
> > +                }
> > +                Ok((sock, _addr)) =>  {
> > +                    sock.set_nodelay(true).unwrap();
> > +                    let _ = set_tcp_keepalive(sock.as_raw_fd(), PROXMOX_BACKUP_TCP_KEEPALIVE_TIME);
> > +                    let acceptor = Arc::clone(&acceptor);
> > +                    let mut sender = sender.clone();
> > +
> > +                    if accept_counter.load(Ordering::SeqCst) > MAX_PENDING_ACCEPTS {
> > +                        eprintln!("connection rejected - to many open connections");
> > +                        continue;
> > +                    }
> > +                    accept_counter.fetch_add(1, Ordering::SeqCst);
> 
> We should think about making a counter guard for this sort of thing,
> because from this point onward we're not allowed to use `?` anywhere,
> which is quite annoying.

yes

> 
> > +
> > +                    let accept_counter = accept_counter.clone();
> > +                    tokio::spawn(async move {
> > +                        let accept_future = tokio::time::timeout(
> > +                            Duration::new(10, 0), tokio_openssl::accept(&acceptor, sock));
> > +
> > +                        let result = accept_future.await;
> > +
> > +                        match result {
> > +                            Ok(Ok(connection)) => {
> > +                                if let Err(_) = sender.send(Ok(connection)).await {
> > +                                    eprintln!("detect closed connection channel");
> > +                                }
> > +                            }
> > +                            Ok(Err(err)) => {
> > +                                eprintln!("https handshakeX failed - {}", err);
> > +                            }
> > +                            Err(_) => {
> > +                                eprintln!("https handshake timeout");
> > +                            }
> > +                        }
> 
> which is why I'd rather thave the part above in its own `async fn`
> followed by the `fetch_sub` below, followed by the `eprintln!()`s.
> 
> > +
> > +                        accept_counter.fetch_sub(1, Ordering::SeqCst);
> > +                    });
> > +                }
> > +            }
> > +        }
> > +    });
> > +
> > +    receiver
> > +}
> > +
> >  fn start_stat_generator() {
> >      let abort_future = server::shutdown_future();
> >      let future = Box::pin(run_stat_generator());
> > -- 
> > 2.20.1




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections
  2020-11-03 13:25   ` Dietmar Maurer
@ 2020-11-03 14:15     ` Wolfgang Bumiller
  2020-11-03 15:54       ` Dietmar Maurer
  0 siblings, 1 reply; 8+ messages in thread
From: Wolfgang Bumiller @ 2020-11-03 14:15 UTC (permalink / raw)
  To: Dietmar Maurer; +Cc: pve-devel

On Tue, Nov 03, 2020 at 02:25:21PM +0100, Dietmar Maurer wrote:
> > > -            let connections = proxmox_backup::tools::async_io::HyperAccept(connections);
> > > +            let connections = accept_connections(listener, acceptor);
> > > +            let connections = hyper::server::accept::from_stream(connections);
> > 
> > If we move the `from_stream` into the function below...
> 
> I have tried to do that for 2 hours, then gave up....
> So please tell m e how to make that work!

nvm, the required feature is still unstable, we'd need to

    -> impl Accept<Conn: AsyncRead, Error: std::error::Error>

but trait bounds on associated types in impl returns is unstable...
Link: https://github.com/rust-lang/rust/issues/52662

:(




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections
  2020-11-03 14:15     ` Wolfgang Bumiller
@ 2020-11-03 15:54       ` Dietmar Maurer
  0 siblings, 0 replies; 8+ messages in thread
From: Dietmar Maurer @ 2020-11-03 15:54 UTC (permalink / raw)
  To: Wolfgang Bumiller; +Cc: pve-devel

> On Tue, Nov 03, 2020 at 02:25:21PM +0100, Dietmar Maurer wrote:
> > > > -            let connections = proxmox_backup::tools::async_io::HyperAccept(connections);
> > > > +            let connections = accept_connections(listener, acceptor);
> > > > +            let connections = hyper::server::accept::from_stream(connections);
> > > 
> > > If we move the `from_stream` into the function below...
> > 
> > I have tried to do that for 2 hours, then gave up....
> > So please tell m e how to make that work!
> 
> nvm, the required feature is still unstable, we'd need to
> 
>     -> impl Accept<Conn: AsyncRead, Error: std::error::Error>
> 
> but trait bounds on associated types in impl returns is unstable...
> Link: https://github.com/rust-lang/rust/issues/52662
> 
> :(

Well, I call this a serious compiler bug ...

Anyways, my workaround is a single line of code.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections
  2020-11-03 13:05 ` Wolfgang Bumiller
  2020-11-03 13:25   ` Dietmar Maurer
@ 2020-11-03 17:45   ` Dietmar Maurer
  2020-11-04  5:37     ` Dietmar Maurer
  1 sibling, 1 reply; 8+ messages in thread
From: Dietmar Maurer @ 2020-11-03 17:45 UTC (permalink / raw)
  To: Wolfgang Bumiller; +Cc: pve-devel

> > +                Ok((sock, _addr)) =>  {
> > +                    sock.set_nodelay(true).unwrap();
> > +                    let _ = set_tcp_keepalive(sock.as_raw_fd(), PROXMOX_BACKUP_TCP_KEEPALIVE_TIME);
> > +                    let acceptor = Arc::clone(&acceptor);
> > +                    let mut sender = sender.clone();
> > +
> > +                    if accept_counter.load(Ordering::SeqCst) > MAX_PENDING_ACCEPTS {
> > +                        eprintln!("connection rejected - to many open connections");
> > +                        continue;
> > +                    }
> > +                    accept_counter.fetch_add(1, Ordering::SeqCst);
> 
> We should think about making a counter guard for this sort of thing,
> because from this point onward we're not allowed to use `?` anywhere,
> which is quite annoying.

I wonder if we can simply use an Arc<bool> for that? The Arc already has
an atomic counter with deref on drop!

And we can query that counter with Arc::strong_count

What do you think?




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections
  2020-11-03 17:45   ` Dietmar Maurer
@ 2020-11-04  5:37     ` Dietmar Maurer
  0 siblings, 0 replies; 8+ messages in thread
From: Dietmar Maurer @ 2020-11-04  5:37 UTC (permalink / raw)
  To: Wolfgang Bumiller; +Cc: pve-devel

Answering myself, this works as expected.

I now simply use Arc::new(()) to count references.

> On 11/03/2020 6:45 PM Dietmar Maurer <dietmar@proxmox.com> wrote:
> 
>  
> > > +                Ok((sock, _addr)) =>  {
> > > +                    sock.set_nodelay(true).unwrap();
> > > +                    let _ = set_tcp_keepalive(sock.as_raw_fd(), PROXMOX_BACKUP_TCP_KEEPALIVE_TIME);
> > > +                    let acceptor = Arc::clone(&acceptor);
> > > +                    let mut sender = sender.clone();
> > > +
> > > +                    if accept_counter.load(Ordering::SeqCst) > MAX_PENDING_ACCEPTS {
> > > +                        eprintln!("connection rejected - to many open connections");
> > > +                        continue;
> > > +                    }
> > > +                    accept_counter.fetch_add(1, Ordering::SeqCst);
> > 
> > We should think about making a counter guard for this sort of thing,
> > because from this point onward we're not allowed to use `?` anywhere,
> > which is quite annoying.
> 
> I wonder if we can simply use an Arc<bool> for that? The Arc already has
> an atomic counter with deref on drop!
> 
> And we can query that counter with Arc::strong_count
> 
> What do you think?




^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2020-11-04  5:37 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-03 12:26 [pve-devel] [RFC PATCH] fix #3106: correctly queue incoming connections Dietmar Maurer
2020-11-03 12:51 ` Dominik Csapak
2020-11-03 13:05 ` Wolfgang Bumiller
2020-11-03 13:25   ` Dietmar Maurer
2020-11-03 14:15     ` Wolfgang Bumiller
2020-11-03 15:54       ` Dietmar Maurer
2020-11-03 17:45   ` Dietmar Maurer
2020-11-04  5:37     ` Dietmar Maurer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal