public inbox for pmg-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>, pmg-devel@lists.proxmox.com
Subject: Re: [pmg-devel] [RFC PATCH pmg-api] api: cluster status: add timeout to api call
Date: Wed, 17 May 2023 12:36:44 +0200	[thread overview]
Message-ID: <5b5b5336-c97e-f232-b1fd-7ae4ef9cc5aa@proxmox.com> (raw)
In-Reply-To: <20230417114035.3051763-1-d.csapak@proxmox.com>

Am 17/04/2023 um 13:40 schrieb Dominik Csapak:
> 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 <d.csapak@proxmox.com>
> ---
> 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...

this would be nicer though, as it actually reflects what we want to control,
namely not exceeding the total timeout of 30 (minus some), rather than giving
each the same averaged piece.

A even better solution could be to do all request async and await them with a
single 28s timeout for all "futures", maybe using an AnyEvent->timer() for the
timeout, an AnyEvent::HTTP::http_get in a loop for requests and an
AnyEvent->condvar to await either. The most complexity might be re-doing the
finger print checking again via the AnyEvent::TLS context, but checking our
API http-server's proxy_request method it doesn't seem _that_ bad either.




      reply	other threads:[~2023-05-17 10:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-17 11:40 Dominik Csapak
2023-05-17 10:36 ` Thomas Lamprecht [this message]

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=5b5b5336-c97e-f232-b1fd-7ae4ef9cc5aa@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pmg-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