From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH widget-toolkit] fix #4961: disks: increase timeout to 1min
Date: Tue, 26 Sep 2023 09:55:22 +0200 [thread overview]
Message-ID: <1695714131.wbzdf9yjca.astroid@yuna.none> (raw)
In-Reply-To: <20230921082157.33718-1-g.goller@proxmox.com>
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.
>
> Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
> ---
> src/panel/DiskList.js | 1 +
> 1 file changed, 1 insertion(+)
>
> 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=3045 and
https://bugzilla.proxmox.com/show_bug.cgi?id=4447 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();
> },
> --
> 2.39.2
>
>
>
> _______________________________________________
> pbs-devel mailing list
> pbs-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
>
>
>
next prev parent reply other threads:[~2023-09-26 7:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-21 8:21 Gabriel Goller
2023-09-26 7:55 ` Fabian Grünbichler [this message]
2023-09-26 8:15 ` Dominik Csapak
2023-09-26 13:42 ` Thomas Lamprecht
2023-09-28 12:57 ` Gabriel Goller
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=1695714131.wbzdf9yjca.astroid@yuna.none \
--to=f.gruenbichler@proxmox.com \
--cc=pbs-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