fix: cachedFetcher.update() no longer blocks token reads during DB refresh#1535
fix: cachedFetcher.update() no longer blocks token reads during DB refresh#1535NETIZEN-11 wants to merge 11 commits intohyperledger-labs:mainfrom
Conversation
c05df30 to
3b791af
Compare
|
@adecaro Would love a review on this. Thanks! |
|
Hi @NETIZEN-11 , thanks for submitting this 🙏 Thanks much 🙏 |
|
@NETIZEN-11 , please, run |
429f175 to
727e53d
Compare
|
@adecaro implemented the fix. Would love a review! |
adecaro
left a comment
There was a problem hiding this comment.
LGTM. Thanks a lot @NETIZEN-11
|
@NETIZEN-11 , the linter is still failing. Please, double check. You can run locally |
|
Hi @NETIZEN-11 , unfortunately, the checks are still reporting issues 😞 |
25ab751 to
d65a96e
Compare
|
Hi @adecero, Thanks for your feedback 🙏 All checks should be passing now. Please take another look. Thanks! |
d65a96e to
d09034e
Compare
|
Hi @NETIZEN-11 , thanks a lot for this PR. Could you please check the failed test? |
|
the unit-tests pass on my machine, it must be that the test is not tuned for a slower machine like the one the CI is using perhaps. @NETIZEN-11 , please, fix this ASAP 🙏 |
ca8232d to
f407b2f
Compare
|
@adecrao Thanks for the review!
Let me know if any further changes are needed. |
|
Hi @NETIZEN-11 , I'm having a second pass. I still don't understand what we are gaining. If a go routing is updating, it means that other readers might try to update as well because the cache is empty or not fresh enough. These other go routines then will block on the signal of the updating being completing. Do you see my point? I'm still wrapping my mind around 😅 |
|
yes, if an update is in progress, other readers will satisfy the condition that triggers an update. Now, after the first go routine that acquired the lock completes, these lines (in the original code) guarantee that the other waiting for mu will not need a new db query. |
|
@adecaro Thanks for explaining! The sync.Cond implementation ensures that once the first goroutine completes its DB refresh and |
|
Hi @NETIZEN-11 , so, I think your patch helps when the refresh is invoked when the cache is not yet exhausted. Fair enough. We need to cleanup the code to remove duplications and make the code more robust. Please, have another pass on the code. Many thanks for the effort 🙏 |
743dc63 to
f4b5c51
Compare
Signed-off-by: Nitesh <nitesh@example.com>
Signed-off-by: Nitesh <nitesh@example.com>
Signed-off-by: Nitesh <nitesh@example.com>
Signed-off-by: Nitesh <nitesh@example.com>
…cachedFetcher This commit introduces a sync.Cond mechanism to ensure only one database refresh runs at a time in cachedFetcher, preventing redundant work and timeouts on CI. It also adds proper error handling in groupTokensByKey to prevent updating the cache with incomplete data, and resolves several linting and configuration issues. Signed-off-by: Nitesh <nitesh@example.com>
Signed-off-by: Nitesh <nitesh@example.com>
Signed-off-by: Nitesh <nitesh@example.com>
Signed-off-by: Nitesh <nitesh@example.com>
f4b5c51 to
c90cc2f
Compare
|
Hi @NETIZEN-11 , I'll review your latest changes ASAP. Sorry for the delay 🙏 |
|
Hi @NETIZEN-11 , please, resolve the conflicts 🙏 |
|
Hi @NETIZEN-11 , I left a few more comments. Sorry for being picky. This code is on the critical path of a token transaction's lifecycle. We need to make it as clean as possible. Thanks for the understanding 🙏 |
Signed-off-by: Nitesh Kumar <niteshkumar121411@gmail.com>
|
Hi @adecaro, I’ve addressed all the review comments and pushed the updates. Could you please take another look when you get a chance? Thank u! |
|
Hi @NETIZEN-11 , thanks for the changes. We still have linter issues. Please, run |
|
Hi @NETIZEN-11 , please, don't forget to fix the lint issues. Thanks 🙏 |
|
Hi @NETIZEN-11 , please, let me know if you can continue on this PR. Many thanks 🙏 |
|
Hi @adecaro, I’ve been dealing with some health issues recently, so it’s taking me a little more time. I’m working on fixing this as soon as possible. Thank you for your patience 🙏 |
Hi @NETIZEN-11 , your personal health first. Have a speedy recovery 🙏 |
What was fixed
The
cachedFetcher.update()function intoken/services/selector/sherdlock/fetcher.gowas holding a write lock for the entire duration of the database query. This meant whenever the cache needed to refresh (e.g., on a slow DB), all token read operations would block waiting for the lock.How it was fixed
Fix: #1547
Tests added
TestCachedFetcher_UpdateDoesNotBlockReaders: verifies that concurrent readers can still acquire the lock while update() is waiting on the databaseTestCachedFetcher_UpdateReacquiresLockAfterDB: verifies the cache is correctly updated after the lock is re-acquired