Skip to content
代码片段 群组 项目
  1. 7月 05, 2022
    • Chris Egerton's avatar
      KAFKA-13613: Remove hard dependency on HmacSHA256 algorithm for Connect (#11894) · ec22af94
      Chris Egerton 创作于
      Reviewers: Mickael Maison <mickael.maison@gmail.com>

, Tom Bentley <tbentley@redhat.com>
      未验证
      ec22af94
    • Thomas Cooper's avatar
      Upgrade Netty and Jackson versions for CVE fixes [KAFKA-14044] (#12376) · aa735062
      Thomas Cooper 创作于
      Reviewers: Luke Chen <showuon@gmail.com>
      未验证
      aa735062
    • Matthew de Detrich's avatar
      KAFKA-13957: Fix flaky shouldQuerySpecificActivePartitionStores test (#12289) · 4e6326f8
      Matthew de Detrich 创作于
      
      Currently the tests fail because there is a missing predicate in the retrievableException which causes the test to fail, i.e. the current predicates
      
      containsString("Cannot get state store source-table because the stream thread is PARTITIONS_ASSIGNED, not RUNNING"),
      containsString("The state store, source-table, may have migrated to another instance"),
      containsString("Cannot get state store source-table because the stream thread is STARTING, not RUNNING")
      
      wasn't complete. Another one needed to be added, namely "The specified partition 1 for store source-table does not exist.". This is because its possible for
      
      assertThat(getStore(kafkaStreams2, storeQueryParam2).get(key), is(nullValue()));
      
      or
      
      assertThat(getStore(kafkaStreams1, storeQueryParam2).get(key), is(nullValue()));
      
      (depending on which branch) to be thrown, i.e. see
      
      org.apache.kafka.streams.errors.InvalidStateStorePartitionException: The specified partition 1 for store source-table does not exist.
      
      	at org.apache.kafka.streams.state.internals.WrappingStoreProvider.stores(WrappingStoreProvider.java:63)
      	at org.apache.kafka.streams.state.internals.CompositeReadOnlyKeyValueStore.get(CompositeReadOnlyKeyValueStore.java:53)
      	at org.apache.kafka.streams.integration.StoreQueryIntegrationTest.lambda$shouldQuerySpecificActivePartitionStores$5(StoreQueryIntegrationTest.java:223)
      	at org.apache.kafka.streams.integration.StoreQueryIntegrationTest.retryUntil(StoreQueryIntegrationTest.java:579)
      	at org.apache.kafka.streams.integration.StoreQueryIntegrationTest.shouldQuerySpecificActivePartitionStores(StoreQueryIntegrationTest.java:186)
      
      This happens when the stream hasn't been initialized yet. I have run the test around 12k times using Intellij's JUnit testing framework without any flaky failures. The PR also does some minor refactoring regarding moving the list of predicates into their own functions.
      
      Co-authored-by: default avatarBruno Cadonna <cadonna@apache.org>
      
      Reviewer: Bruno Cadonna <cadonna@apache.org>
      未验证
      4e6326f8
  2. 7月 04, 2022
  3. 7月 03, 2022
  4. 7月 02, 2022
  5. 7月 01, 2022
  6. 6月 30, 2022
  7. 6月 29, 2022
  8. 6月 28, 2022
  9. 6月 26, 2022
  10. 6月 25, 2022
  11. 6月 24, 2022
  12. 6月 23, 2022
  13. 6月 22, 2022
    • David Jacot's avatar
      MINOR: Fix AlterPartitionManager topic id handling in response handler (#12317) · 3072b3d2
      David Jacot 创作于
      https://github.com/apache/kafka/commit/f83d95d9a28267f7ef7a7b1e584dcdb4aa842210 introduced topic ids in the AlterPartitionRequest/Response and we just found a bug in the request handling logic. The issue is the following.
      
      When the `AlterPartitionManager` receives the response, it builds the `partitionResponses` mapping `TopicIdPartition` to its result. `TopicIdPartition` is built from the response. Therefore if version < 2 is used, `TopicIdPartition` will have the `ZERO` topic id. Then the `AlterPartitionManager` iterates over the item sent to find their response. If an item has a topic id in its `TopicIdPartition` and version < 2 was used, it cannot find it because one has it and the other one has not.
      
      This patch fixes the issue by using `TopicPartition` as a key in the `partitionResponses` map. This ensures that the result can be found regardless of the topic id being set or not.
      
      Note that the case where version 2 is used is handled correctly because we already have logic to get back the topic name from the topic id in order to construct the `TopicPartition`.
      
      `testPartialTopicIds` test was supposed to catch this but it didn't due to the ignorable topic id field being present. This patch fixes the test as well.
      
      Reviewers: Kvicii <42023367+Kvicii@users.noreply.github.com>, Jason Gustafson <jason@confluent.io>
      未验证
      3072b3d2
  14. 6月 21, 2022
  15. 6月 20, 2022
  16. 6月 18, 2022
    • Guozhang Wang's avatar
      KAFKA-13880: Remove DefaultPartitioner from StreamPartitioner (#12304) · cfdd5679
      Guozhang Wang 创作于
      There are some considerata embedded in this seemingly straight-forward PR that I'd like to explain here. The StreamPartitioner is used to send records to three types of topics:
      
      1) repartition topics, where key should never be null.
      2) changelog topics, where key should never be null.
      3) sink topics, where only non-windowed key could be null and windowed key should still never be null.
      Also, the StreamPartitioner is used as part of the IQ to determine which host contains a certain key, as determined by the case 2) above.
      
      This PR's main goal is to remove the deprecated producer's default partitioner, while with those things in mind such that:
      
      We want to make sure for not-null keys, the default murmur2 hash behavior of the streams' partitioner stays consistent with producer's new built-in partitioner.
      For null-keys (which is only possible for non-window default stream partition, and is never used for IQ), we would fix the issue that we may never rotate to a new partitioner by setting the partition as null hence relying on the newly introduced built-in partitioner.
      
      Reviewers: Artem Livshits <84364232+artemlivshits@users.noreply.github.com>, Matthias J. Sax <matthias@confluent.io>
      未验证
      cfdd5679
  17. 6月 17, 2022
  18. 6月 16, 2022
加载中