From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id B8D42E6EB for ; Tue, 26 Sep 2023 09:55:29 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 998C335F78 for ; Tue, 26 Sep 2023 09:55:29 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 26 Sep 2023 09:55:28 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id B09754469C for ; Tue, 26 Sep 2023 09:55:28 +0200 (CEST) Date: Tue, 26 Sep 2023 09:55:22 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox Backup Server development discussion References: <20230921082157.33718-1-g.goller@proxmox.com> In-Reply-To: <20230921082157.33718-1-g.goller@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1695714131.wbzdf9yjca.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.063 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 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 widget-toolkit] fix #4961: disks: increase timeout to 1min 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: , X-List-Received-Date: Tue, 26 Sep 2023 07:55:29 -0000 On September 21, 2023 10:21 am, Gabriel Goller wrote: > Increase the timeout of the api call to `../nodes/localhost/disks/list` > to 1min. When having a lot of disks the default timeout of 30sec is > not enough. >=20 > Signed-off-by: Gabriel Goller > --- > src/panel/DiskList.js | 1 + > 1 file changed, 1 insertion(+) >=20 > diff --git a/src/panel/DiskList.js b/src/panel/DiskList.js > index c5a0050..5785297 100644 > --- a/src/panel/DiskList.js > +++ b/src/panel/DiskList.js > @@ -70,6 +70,7 @@ Ext.define('Proxmox.DiskList', { > type: 'proxmox', > extraParams: extraParams, > url: url, > + timeout: 60*1000, that alone won't be enough, since we also have a 30s timeout for proxying requests in a PVE cluster (and this component is used there). see https://bugzilla.proxmox.com/show_bug.cgi?id=3D3045 and https://bugzilla.proxmox.com/show_bug.cgi?id=3D4447 for some previous discussion (with similar API endpoints). IMHO the most complete solution would be some sort of light-weight/ephemeral task mechanism: - runs in a worker, like regular task (possibly with a bounded queue of allowed in-flight requests?) - not visible in the regular task list (or only via a special parameter?) - status is pollable, but once completed, results are returned once and discarded, and not stored with the regular task logs/results - result is discarded after $timeout if not polled in time this would allow us to make *every* currently sync API handler (optionally!) async by just spawning such a task and making it the clients responsibility to request async handling and taking care of polling to retrieve the result. then we could selectively switch over certain parts of our GUI, add client-side caching and an explicit refresh button. if the server responds quickly, not much changed except an additional fork and some state housekeeping. there are other solutions as well of course (e.g., some web UIs use a long-lived WebSocket connection and pipeline requests/responses in an async fashion over that). > }); > me.store.load(); > }, > --=20 > 2.39.2 >=20 >=20 >=20 > _______________________________________________ > pbs-devel mailing list > pbs-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel >=20 >=20 >=20