** Description changed:
+ [Impact]
+ * On slow system, zsysctl client can timeout while the daemon is still doing
a lot of active work.
+ * The daemon has now 2 phases:
+ - Not started: specific timeout for the daemon to start before the client
exits.
+ - After startup, when proceeding client request: pulse in the grpc command
from the daemon when any log is processed (just replaced by pulse bytes).
+
+ [Test Case]
+
+ * 1. Create a bunch of datasets so that requests always timeout
+ * 2. Upgrade to the new zsys version
+ * 3. Redo the same request -> it should be slow to execute but don’t timeout.
+
+ [Regression Potential]
+ * GRPC exchange hasn’t changed
+ * However, we are now sending "." in non debug mode to the client to pulse
progress.
+ * We were already running a lot of command with -vv, sending more data
(debug logs)
+
+ ---
+
The client can timeout while the daemon is still doing a lot of active
work.
There are 3 cases to take into account:
- daemon not started: give a timeout for the daemon to start before the
client exits. Ideally, we would pulse back to the client, but the entrypoint
isn’t reached out yet
- once the call starts:
- If other calls are in progress and there is mutex, ideally pulse it to the
client (or give a new timeout)
+ If other calls are in progress and there is mutex, ideally pulse it to the
client (or give a new timeout)
- when it’s our turn:
the pulse to the daemon can be done by the log progress which we will thus
always send to the client.
Note that if we wait for too long, we can imagine a pulsing progress bar
on the CLI with which steps we are at.
This needs to change GRPC messages back but will drastically reduce
timeouts that people can get when having a lot of datasets or in code
path we didn’t optimize yet.
** Also affects: zsys (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: zsys (Ubuntu Focal)
Importance: Undecided => High
** Changed in: zsys (Ubuntu Focal)
Assignee: (unassigned) => Didier Roche (didrocks)
** Changed in: zsys (Ubuntu)
Assignee: (unassigned) => Didier Roche (didrocks)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to zsys in Ubuntu.
https://bugs.launchpad.net/bugs/1875564
Title:
Enhance timeout handling to avoid error rpc error: code =
DeadlineExceeded desc = context deadline exceeded while the daemon is
doing work
Status in zsys package in Ubuntu:
Fix Released
Status in zsys source package in Focal:
New
Bug description:
[Impact]
* On slow system, zsysctl client can timeout while the daemon is still doing
a lot of active work.
* The daemon has now 2 phases:
- Not started: specific timeout for the daemon to start before the client
exits.
- After startup, when proceeding client request: pulse in the grpc command
from the daemon when any log is processed (just replaced by pulse bytes).
[Test Case]
* 1. Create a bunch of datasets so that requests always timeout
* 2. Upgrade to the new zsys version
* 3. Redo the same request -> it should be slow to execute but don’t timeout.
[Regression Potential]
* GRPC exchange hasn’t changed
* However, we are now sending "." in non debug mode to the client to pulse
progress.
* We were already running a lot of command with -vv, sending more data
(debug logs)
---
The client can timeout while the daemon is still doing a lot of active
work.
There are 3 cases to take into account:
- daemon not started: give a timeout for the daemon to start before the
client exits. Ideally, we would pulse back to the client, but the entrypoint
isn’t reached out yet
- once the call starts:
If other calls are in progress and there is mutex, ideally pulse it to the
client (or give a new timeout)
- when it’s our turn:
the pulse to the daemon can be done by the log progress which we will thus
always send to the client.
Note that if we wait for too long, we can imagine a pulsing progress
bar on the CLI with which steps we are at.
This needs to change GRPC messages back but will drastically reduce
timeouts that people can get when having a lot of datasets or in code
path we didn’t optimize yet.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1875564/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
