vamossagar12 commented on pull request #11211: URL: https://github.com/apache/kafka/pull/11211#issuecomment-1074869243
> > the computation is done again on the cached data > > What computation do you mean? In the end, we just iterate? And for both cases (also with cache) we need to have an interator for the inner store, because the cache might not have all data -- thus, we need to "peek" into both iterators to see what the next key is to "merge" both together correctly -- if the key exists in the underlying store and the cache, we return the data from the cache, but we still need to skip over the key in the underlying store to ensure the merging is done correctly. (Not sure if your question was referring to this part of the "merge logic"?) @mjsax , thanks yeah that's what I meant. Sorry I didn't check the entire implementation before posting. Another question on this is regarding the bug on Caching store. I know I need to send out another PR for this but just for my understanding. You mentioned if a certain key is found in both inner store and cache then we want to return from the cache. But if a key is expired from the inner store (what this PR addresses for persistent stores) but is still present in the cache, then do we keep it or remove it from the cache? And do we return that key? The reason I ask this is I think the cached store is maintained by a different config - cache.max_bytes and the expiry of items from the cache is decided by that config. So, there may be chances when the innerstore has a certain key expired but due to this config's threshold not being met, the key isn't removed from the cache. To keep them in sync, we can remove the item from the cache. -- 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. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
