From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id C3C141FF161 for ; Wed, 4 Dec 2024 14:49:50 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 012988E1D; Wed, 4 Dec 2024 14:49:50 +0100 (CET) Date: Wed, 04 Dec 2024 14:49:12 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox Backup Server development discussion References: <20241204083149.58754-1-c.ebner@proxmox.com> <20241204083149.58754-4-c.ebner@proxmox.com> In-Reply-To: <20241204083149.58754-4-c.ebner@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1733319977.r426m80cai.astroid@yuna.none> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.048 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pbs-devel] [PATCH v2 proxmox-backup 3/3] client: reader: signal server before client disconnect X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On December 4, 2024 9:31 am, Christian Ebner wrote: > Signal the server that the client has successfully finished its > operation and is about to close the connection. This allows the server > side to react and clean up the connection, without returning and > logging an error state, as that can cause confusion [0], as this is > not an error but normal behaviour. > > Report in the community forum: > [0] https://forum.proxmox.com/threads/158306/ > > Signed-off-by: Christian Ebner > --- > changes since version 1: > - no changes > > Note: > I am not sure this is the best approach, as this might block the > thread until the server responds or it runs into a time out. > > The alternative would require completely reworking all backup reader > related call sides. Or maybe there is another alternative? > > pbs-client/src/backup_reader.rs | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/pbs-client/src/backup_reader.rs b/pbs-client/src/backup_reader.rs > index 88cba599b..63106c999 100644 > --- a/pbs-client/src/backup_reader.rs > +++ b/pbs-client/src/backup_reader.rs > @@ -27,6 +27,8 @@ pub struct BackupReader { > > impl Drop for BackupReader { > fn drop(&mut self) { > + // Ignore errors > + let _ = proxmox_async::runtime::block_on(self.post("finish", None)); should we maybe make this explicit, like we do in the BackupWriter? I know that it's a bit less "obvious" here compared to writer sessions what constitutes success/being finished ;) means a bit more churn now to adapt the users of BackupReader, but would make it possible to differentiate server side whether a reader session was exited normally or via an error? we could even provide some sort of message via the finish API call that the server could log if desired, differentiating between: - regular finish (no error/warning) - finish called with a warning message (warning) - finish not called, reader went away (error) ? > self.abort.abort(); > } > } > -- > 2.39.5 > > > > _______________________________________________ > pbs-devel mailing list > pbs-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel > > > _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel