public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Christian Ebner <c.ebner@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>,
	Max Carrara <m.carrara@proxmox.com>
Subject: Re: [pbs-devel] [PATCH v4 proxmox-backup 4/5] client: reader: add finish method to signal client state to server
Date: Wed, 9 Apr 2025 16:27:24 +0200	[thread overview]
Message-ID: <1d61fea1-db7e-4615-8330-250b862a226f@proxmox.com> (raw)
In-Reply-To: <D925PBMYWMNL.SUU07VVP4K@proxmox.com>

On 4/9/25 15:53, Max Carrara wrote:
> On Tue Apr 8, 2025 at 2:58 PM CEST, Christian Ebner wrote:
>> Signal the server that the client has finished its operation and is
>> about to close the connection. This allows the server side to react
>> accordingly.
>>
>> Termination of the reader connection after successuful completion is
>> now no longer logged as connection error, which has caused confusion
>> [0].
>>
>> Report in the community forum:
>> [0] https://forum.proxmox.com/threads/158306/
>>
>> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
>> ---
>> changes since version 3:
>> - no changes
>>
>>   pbs-client/src/backup_reader.rs | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/pbs-client/src/backup_reader.rs b/pbs-client/src/backup_reader.rs
>> index 18442ebca..3474c8ce3 100644
>> --- a/pbs-client/src/backup_reader.rs
>> +++ b/pbs-client/src/backup_reader.rs
>> @@ -77,6 +77,12 @@ impl BackupReader {
>>           Ok(BackupReader::new(h2, abort, crypt_config))
>>       }
>>   
>> +    /// Terminate reader session by signaling server via `finish` api call before closing connection
>> +    pub async fn finish(self: Arc<Self>) -> Result<(), Error> {
>> +        let _value = self.post("finish", None).await?;
>> +        Ok(())
>> +    }
> 
> There are two concerns I have with this approach here:
> 
>    1. While I like moving out of `self` here (I actually love it when
>       state is represented via the type system) calling `post` here like
>       this might cause a race: `self: Arc<Self>` might still be
>       referenced somewhere else, as in, there might still be some other
>       operations going on.
> 
>    2. Calling `finish()` is not enforced. In patch 05 you're calling
>       `finish()` in 9 locations in total if I counted correctly, which
>       means that there are 9 locations where haphazard changes could
>       introduce subtle bugs.
> 
> What I'd instead suggest is enforcing the call to happen through the
> type system -- here's a *very* rough example:
> 
>      with_new_reader(..., |reader: &BackupReader| {
>          // Do stuff in here ...
>      
>          // Return a result upon successful completion, which then signals
>          // to with_new_reader() that finish() should be called
>          Ok(...)
>      })
>      
>      fn with_new_reader<F>(..., func: F) -> Result<(), Error>
>      where
>          F: FnOnce(BackupReader) -> Result<(), Error> {
>      
>          // [...] set up reader, then call func() on it
>          let reader = ...
>      
>          match func(&reader) {
>      	Ok(()) => reader.finish().await,
>      	Err(...) => ...,
>          }
>      }
> 
> The idea behind this is that the closure enforces the scope in which the
> reader is used for operations. Once the closure ends, `finish()` is
> called depending on the result the closure returns. Instead of just
> returning `()`, you could also add some kind of enum representing the
> possible "exiting" values / states of the reader, in case there's more
> stuff to handle (now or in the future).
> 
> The thing is though... implementing this would require a rather large
> set of changes throughout our code, because we currently pass around
> `Arc<BackupReader>` quite a lot (*sigh*), which really gets in the way
> when one wants to enforce a certain order of operations (i.e. preventing
> `finish()` from being called too early).
> 
> Since all of the methods of `BackupReader` take `&self` you could check
> if you can get away with s/Arc<BackupReader>/&BackupReader/.
> 
> Let me know what you think!

Thanks for your suggestions. Given that this will however require more 
in-depth changes and has a larger regression potential this will be 
postponed to after the next point release (as discussed of list with 
Thomas).


_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel


  reply	other threads:[~2025-04-09 14:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 12:58 [pbs-devel] [PATCH v4 proxmox-backup 0/5] handle reader client disconnects Christian Ebner
2025-04-08 12:58 ` [pbs-devel] [PATCH v4 proxmox-backup 1/5] client: reader: drop dead code Christian Ebner
2025-04-08 12:58 ` [pbs-devel] [PATCH v4 proxmox-backup 2/5] backup debug: diff: refactor backup reader creation Christian Ebner
2025-04-08 12:58 ` [pbs-devel] [PATCH v4 proxmox-backup 3/5] api: reader: handle reader client disconnects Christian Ebner
2025-04-08 12:58 ` [pbs-devel] [PATCH v4 proxmox-backup 4/5] client: reader: add finish method to signal client state to server Christian Ebner
2025-04-09 13:53   ` Max Carrara
2025-04-09 14:27     ` Christian Ebner [this message]
2025-04-08 12:58 ` [pbs-devel] [PATCH v4 proxmox-backup 5/5] client: backup reader: call finish before dropping backup readers Christian Ebner
2025-04-09 12:53 ` [pbs-devel] [PATCH v4 proxmox-backup 0/5] handle reader client disconnects Fiona Ebner
2025-04-09 12:55   ` Fiona Ebner
2025-04-09 13:20     ` Thomas Lamprecht
2025-04-09 13:35       ` Fiona Ebner
2025-04-09 13:25   ` Christian Ebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1d61fea1-db7e-4615-8330-250b862a226f@proxmox.com \
    --to=c.ebner@proxmox.com \
    --cc=m.carrara@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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