You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@shasderias Hmmm, I'm not sure if this is blocking or if it's just ... slow. In my testing I did observe things timing out, but after adding some print logs, the call to AddResource seem to all be returning eventually, in order.
And if I give it enough workers, let's just say 50 (via httprc.WithWorkers(50)) it seems to pass immediately.
I acknowledge there's something to be desired, but I have a feeling it's just bad performance. (which I'll work on, but just want to make sure if we're seeing the same symptoms)
I'm a little short on time now, but my gut feeling is:
this is a true deadlock as in, I think there's a genuine race condition that has a chance of causing a program to halt;
this is probably not (just) a performance problem;
I'm not surprised that adding print statements make the problem goes away, as terminal I/O takes a comparatively "long time", which can mask the deadlock;
the preceding point is also true for adding workers; one goroutine for each resource monitored = no chance for the goroutines to "fight" over jobs.
I've also managed to repro on go run and on a Windows machine on 1.23.1.
I'll have a bit more time after the 19th, will try to validate the above/investigate further then if it's still necessary.
Describe the bug
Calling
jwk.(Cache).Register()
many times with thejwk.WithWaitReady(false)
option may result in a deadlock.Please attach the output of
go version
(also reproducible on 1.23.1)
To Reproduce / Expected behavior
Repro Repo
Run the following test.
Expected: the program to terminate.
Actual: the program deadlocks (see log below).
The issue is also reproducible with:
go test -v
run from the command line;The issue does not appear to reproduce with
go run
, although it may be the case that the problem is still present, just less likely to occur.The program does not always deadlock in the same iteration of the for loop.
The text was updated successfully, but these errors were encountered: