all lists on 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal