Trustin Lee
Trustin Lee
That's be awesome, @amitvc !
And we could make it a subtask of this issue.
@dependabot rebase
@dependabot rebase
Thanks for the detailed report! I'm curious if the problem goes away if you remove the capping logic [here](https://github.com/line/armeria/blob/armeria-1.32.5/core/src/main/java/com/linecorp/armeria/internal/common/InboundTrafficController.java#L49). Also, do you have a reproducer we can play with?
@JihwanByun My understanding is that acquiring a lock is already as expensive as `System.nanoTime()`. Therefore, we can stick to the initial idea: 1. Record the current time on successful lock...
At second thought, I feel like we should take the lock/unlock time into account, because it could be useful to find the potential contention that would make it effectively 'blocking'....
It looks like the mappings in `statuscodes.md` were removed long time ago: https://github.com/grpc/grpc/commit/bb04e070b3177d7bd8e69c4086dc420f662b8f28 The latest mappings are here: https://github.com/grpc/grpc/blob/v1.66.2/doc/http-grpc-status-mapping.md and `429 Too Many Requests` is mapped into `UNAVAILABLE`. That being...
I asked a question at https://groups.google.com/g/grpc-io (pending approval). Let's wait for gRPC team's answer.
I like the approach here and the feedback from @jrhee17 and @ikhoon. Thanks for bringing back to the table, @novoj! 🙇