From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pbs-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
by lore.proxmox.com (Postfix) with ESMTPS id C3C141FF161
for <inbox@lore.proxmox.com>; 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?= <f.gruenbichler@proxmox.com>
To: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com>
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
<pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pbs-devel-bounces@lists.proxmox.com
Sender: "pbs-devel" <pbs-devel-bounces@lists.proxmox.com>
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 <c.ebner@proxmox.com>
> ---
> 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