Background; there's a closed-source server I'm working on that uses this package through the jwx package github.com/lestrrat-go/jwx. It uses the cache to refresh JWT info periodically. The upstream server being fetched from sometimes is flaky and does not respond (separate issue from this). But because of that hanging request, any attempts to get the cache item are forced to wait, in this case 1 full minute. Because clients of my server have a similar http request timeout, their requests time out because of the wait.
I looked into the code, and I can see that the v1.0.4 httprc code uses the same function, and that it tries to acquire the semaphore even in paths that do not need to make a network request. I made a minimal repro of the issue (https://github.com/natenjoy/httprc-cache-issue) that can be run by cloning the reproduction repo and running go run main.go. There's some more details in the README.md of the repo.
Background; there's a closed-source server I'm working on that uses this package through the jwx package
github.com/lestrrat-go/jwx. It uses the cache to refresh JWT info periodically. The upstream server being fetched from sometimes is flaky and does not respond (separate issue from this). But because of that hanging request, any attempts to get the cache item are forced to wait, in this case 1 full minute. Because clients of my server have a similar http request timeout, their requests time out because of the wait.I looked into the code, and I can see that the v1.0.4 httprc code uses the same function, and that it tries to acquire the semaphore even in paths that do not need to make a network request. I made a minimal repro of the issue (https://github.com/natenjoy/httprc-cache-issue) that can be run by cloning the reproduction repo and running
go run main.go. There's some more details in theREADME.mdof the repo.I also have a proposed fix so that the semaphore is only acquired if the hetwork is going to be hit: https://github.com/lestrrat-go/httprc/pull/25