ableegoldman commented on a change in pull request #11424:
URL: https://github.com/apache/kafka/pull/11424#discussion_r798443526
##########
File path:
streams/test-utils/src/main/java/org/apache/kafka/streams/TopologyTestDriver.java
##########
@@ -329,7 +330,7 @@ private TopologyTestDriver(final InternalTopologyBuilder
builder,
final ThreadCache cache = new ThreadCache(
logContext,
- Math.max(0,
streamsConfig.getLong(StreamsConfig.CACHE_MAX_BYTES_BUFFERING_CONFIG)),
+ Math.max(0,
streamsConfig.getLong(StreamsConfig.STATESTORE_CACHE_MAX_BYTES_CONFIG)),
Review comment:
> since it's a test case so it shouldn't really matter. Isn't that the
case?
Well if someone is using the TTD to write unit tests and those tests start
to fail after they upgrade because the caching is different, I would say that's
compatibility change.
Although I read the TTD's javadocs earlier and remembered that it actually
processes records synchronously, which effectively means that the only thing
that matters/affects the TTD results is whether the cache size is non-zero or
has been set to 0 -- and setting it to 0 only matters if it's correctly set to
0 in the TopologyConfig, not the value here. Which is a long way of saying that
in hindsight, this config/bug doesn't really impact anything after all. In
fact, imho we should probably just hard-code the TTD's ThreadCache cache size
to 0 -- but let's not wrap that change into an already rather large PR in case
there's something I'm not taking into account here.
So tl;dr, for future reference do still need to maintain backwards
compatibility in the TTD since it's part of the public interface. But it just
so happens that this particular bug doesn't actually break anything "real" or
have any visible impact (at least AFAICT
--
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
