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 D47FA98AAC for ; Mon, 17 Apr 2023 13:40:40 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B5D6B3B89B for ; Mon, 17 Apr 2023 13:40:40 +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 ; Mon, 17 Apr 2023 13:40:36 +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 9913D454E5 for ; Mon, 17 Apr 2023 13:40:36 +0200 (CEST) From: Dominik Csapak To: pmg-devel@lists.proxmox.com Date: Mon, 17 Apr 2023 13:40:35 +0200 Message-Id: <20230417114035.3051763-1-d.csapak@proxmox.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.015 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: [pmg-devel] [RFC PATCH pmg-api] api: cluster status: add timeout to api call X-BeenThere: pmg-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Mail Gateway development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2023 11:40:40 -0000 we query each other host in the cluster for it's status, but if we reach the 30s limit of the pmgproxy, we get a communication failure(0) error in the gui. To prevent this, add a (much) shorter timeout to each api call, which makes sure that the whole status call succeeds. Signed-off-by: Dominik Csapak --- sending as RFC because i am not sure if this is the best approach: we could have very asymmetric http call times, which would maybe all go through without timeout, but we cannot really know that beforehand. Another approach could be to give as much time as we have left (with buffer) and subtract the time we took for each call. This would be a problem if the first takes so long that we don't have any time left for the other calls... src/PMG/API2/Cluster.pm | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/PMG/API2/Cluster.pm b/src/PMG/API2/Cluster.pm index 84dafab..5e0a987 100644 --- a/src/PMG/API2/Cluster.pm +++ b/src/PMG/API2/Cluster.pm @@ -217,6 +217,9 @@ __PACKAGE__->register_method({ $res = [ $ni ]; } + # 30 seconds minus 5 seconds buffer time, split evenly for the other hosts + my $timeout = 25 / (scalar(@$res) - 1); + my $rpcenv = PMG::RESTEnvironment->get(); my $authuser = $rpcenv->get_user(); my $ticket = $rpcenv->get_ticket(); @@ -231,6 +234,7 @@ __PACKAGE__->register_method({ ticket => $ticket, cookie_name => 'PMGAuthCookie', host => $ni->{ip}, + timeout => $timeout, cached_fingerprints => { $ni->{fingerprint} => 1, }); -- 2.30.2