You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by GitBox <gi...@apache.org> on 2021/10/13 23:45:50 UTC

[GitHub] [kafka] guozhangwang commented on a change in pull request #9293: POC: Allow bypassing the cache layer in IQ

guozhangwang commented on a change in pull request #9293:
URL: https://github.com/apache/kafka/pull/9293#discussion_r728524198



##########
File path: streams/src/main/java/org/apache/kafka/streams/state/internals/MeteredKeyValueStore.java
##########
@@ -46,43 +46,90 @@
  * @param <K>
  * @param <V>
  */
-public class MeteredKeyValueStore<K, V>
-    extends WrappedStateStore<KeyValueStore<Bytes, byte[]>, K, V>
+public class MeteredKeyValueStore<K, V, OwnType extends MeteredKeyValueStore<K, V, OwnType>>

Review comment:
       I had a slight (? well, maybe not so slight) different idea, which assumes that we only want to have the control at the whole app level, rather than a per-store level at IQ APIs only: suppose we just have, e.g. a config on Streams that enables bypass or not for IQ, then upon calling the get/range/etc APIs at the cached layer:
   
   1) Whether the current thread is a stream thread, if yes, never bypass the cache.
   2) If not, depend on the config to decide whether bypass the cache.
   
   Doing so we then would not need the unwrap/rewrap and the template types as well. The question then goes back to: whether we would need bypassing at the per-store or global level? Personally I think it's not necessary for a finer-grained control, mainly because that in the long run with the new IQ API and the caller likely to have a totally different way to handle consistency / staleness, i.e. we would deprecate `staleStore` per store or global configs in the long run anyways, and the API calls itself is associated with a token to indicate whether allow staleness or bypass 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-unsubscribe@kafka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org