i3wangyi commented on issue #367: Add transient cache for CustomRestClient implementation URL: https://github.com/apache/helix/pull/367#issuecomment-518406925 > > > The parallel request still need to be considered. Say you are implementing the locking by keys. We need 100 participants partition level status called from single instance health check. Then you will read one instance partition level status after the other. It is still sequential read. > > > > > > The sequential read comes from how the upper class uses the CustomRestClientImpl. Currently, it is sequential but it's the scope of next PR. In this PR, my purpose is to add the cache implementation so we can change the implementation of the upper class (ServiceImpl) and make it parallel. > > We need to think about it as a whole piece. I can image that you parallel the requests by using thread pool for each key. But in that case, you may end up with have multiple idling threads hanging there because of locking on the same key. From the decouple point of view, the PR focuses on CustomRestClient's change and its responsibility IMO is to ensure the same request won't get called twice. It's the upper class' job to make the right parallel requests and I'm planning to address it later in the next PR piece by piece. Is your idea to dedupe the # of threads based on requests, in that case, the dedupe logic needs to be handled in the upper layer.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
