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
next prev parent 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