Skip to content
代码片段 群组 项目
  1. 8月 24, 2022
  2. 8月 08, 2022
  3. 8月 02, 2022
  4. 7月 30, 2022
  5. 7月 17, 2022
  6. 7月 09, 2022
  7. 6月 30, 2022
  8. 6月 16, 2022
    • Bruno Cadonna's avatar
      MINOR: Pin ducktape version to < 0.9 (#12242) · 53b816a0
      Bruno Cadonna 创作于
      With newer ducktape versions than < 0.9 system tests
      may run into authentication issues with the AK system test
      infrastructure.
      
      The version will be bumped up once we have infrastructure
      in place for newer paramiko versions brought in by ducktape
      0.9.
      
      Reviewers: Lucas Bradstreet <lucas@confluent.io>, Matthias J. Sax <mjsax@apache.org>, Kvicii <Karonazaba@gmail.com>
      53b816a0
  9. 6月 08, 2022
    • Philip Nee's avatar
      HOTFIX: only try to clear discover-coordinator future upon commit (#12244) (#12259) (#723) · ef2b913f
      Philip Nee 创作于
      
      This is a cherrypick commit of 3.1. Another way of fixing KAFKA-13563 other than #11631.
      
      Instead of letting the consumer to always try to discover coordinator in pool with either mode (subscribe / assign), we defer the clearance of discover future upon committing async only. More specifically, under manual assign mode, there are only three places where we need the coordinator:
      
      commitAsync (both by the consumer itself or triggered by caller), this is where we want to fix.
      commitSync, which we already try to re-discovery coordinator.
      committed (both by the consumer itself based on reset policy, or triggered by caller), which we already try to re-discovery coordinator.
      The benefits are that for manual assign mode that does not try to trigger any of the above three, then we never would be discovering coordinator. The original fix in #11631 would let the consumer to discover coordinator even if none of the above operations are required.
      
      Reviewers: Luke Chen <showuon@gmail.com>, David Jacot <djacot@confluent.io>
      
      Co-authored-by: default avatarGuozhang Wang <wangguoz@gmail.com>
      ef2b913f
  10. 5月 24, 2022
  11. 5月 12, 2022
  12. 5月 11, 2022
    • Ismael Juma's avatar
      MINOR: reload4j build dependency fixes (#12144) · bafa69ed
      Ismael Juma 创作于
      * Replace `log4j` with `reload4j` in `copyDependantLibs`. Since we have
        some projects that have an explicit `reload4j` dependency, it
        was included in the final release release tar - i.e. it was effectively
        a workaround for this bug.
      * Exclude `log4j` and `slf4j-log4j12` transitive dependencies for
        `streams:upgrade-system-tests`. Versions 0100 and 0101
        had a transitive dependency to `log4j` and `slf4j-log4j12` via
        `zkclient` and `zookeeper`. This avoids classpath conflicts that lead
        to [NoSuchFieldError](https://github.com/qos-ch/reload4j/issues/41) in
        system tests.
      
      Reviewers: Jason Gustafson <jason@confluent.io>
      bafa69ed
  13. 5月 04, 2022
  14. 4月 29, 2022
  15. 4月 28, 2022
    • Ismael Juma's avatar
      KAFKA-13794: Fix comparator of inflightBatchesBySequence in TransactionsManager (round 3) (#12096) · b068124a
      Ismael Juma 创作于
      Conceptually, the ordering is defined by the producer id, producer epoch
      and the sequence number. This set should generally only have entries
      for the same producer id and epoch, but there is one case where
      we can have conflicting `remove` calls and hence we add this as
      a temporary safe fix.
      
      We'll follow-up with a fix that ensures the original intended invariant.
      
      Reviewers: Jason Gustafson <jason@confluent.io>, David Jacot
      <djacot@confluent.io>, Luke Chen <showuon@gmail.com>
      b068124a
  16. 4月 21, 2022
  17. 4月 09, 2022
  18. 4月 07, 2022
  19. 4月 06, 2022
  20. 3月 31, 2022
  21. 3月 30, 2022
    • Ismael Juma's avatar
      KAFKA-13418: Support key updates with TLS 1.3 (#11966) · e714cb5d
      Ismael Juma 创作于
      Key updates with TLS 1.3 trigger code paths similar to renegotiation with TLS 1.2.
      Update the read/write paths not to throw an exception in this case (kept the exception
      in the `handshake` method).
      
      With the default configuration, key updates happen after 2^37 bytes are encrypted.
      There is a security property to adjust this configuration, but the change has to be
      done before it is used for the first time and it cannot be changed after that. As such,
      it is best done via a system test (filed KAFKA-13779).
      
      To validate the change, I wrote a unit test that forces key updates and manually ran
      a producer workload that produced more than 2^37 bytes. Both cases failed without
      these changes and pass with them.
      
      Note that Shylaja Kokoori attached a patch with the SslTransportLayer fix and hence
      included them as a co-author of this change.
      
      Reviewers: Rajini Sivaram <rajinisivaram@googlemail.com>
      
      Co-authored-by: Shylaja Kokoori
      e714cb5d
  22. 3月 25, 2022
    • Randall Hauch's avatar
      KAFKA-13770: Restore compatibility with KafkaBasedLog using older Kafka brokers (#11946) · e176f4b2
      Randall Hauch 创作于
      The `retryEndOffsets(…)` method in `TopicAdmin` recently added (KAFKA-12879, #11797) to allow the `KafkaBasedLog.start()` method to retry any failures reading the last offsets for a topic. However, this introduce a regression when talking to older brokers (0.10.x or earlier).
      
      The `KafkaBasedLog` already had logic that expected an `UnsupportedVersionException` thrown by the admin client when a Kafka API is not available on an older broker, but the new retry logic in `TopicAdmin` did not account for this and wrapped the exception, thereby breaking the `KafkaBasedLog` logic and preventing startup.
      
      The fix is to propagate this `UnsupportedVersionException` from the `TopicAdmin.retryEndOffsets(…)` method. Added a new unit test that first replicated the problem before the fix, and verified the fix corrects the problem.
      e176f4b2
  23. 3月 24, 2022
    • Yang Yu's avatar
      KAFKA-13761: KafkaLog4jAppender deadlocks when idempotence is enabled (#11939) · 8e1edef9
      Yang Yu 创作于
      When a log entry is appended to a Kafka topic using KafkaLog4jAppender, the producer.send operation
      may hit a deadlock if the producer network thread also tries to append a log at the same log level.
      This issue is triggered when idempotence is enabled for the KafkaLog4jAppender and the producer
      tries to acquire the TransactionManager lock.
      
      This is a temporary workaround to avoid deadlocks by disabling idempotence explicitly in
      KafkaLog4jAppender.
      
      Reviewers: Luke Chen <showuon@gmail.com>, Ismael Juma <ismael@juma.me.uk>
      8e1edef9
    • Konstantine Karantasis's avatar
      KAFKA-13759: Disable idempotence by default in producers instantiated by Connect (#11933) · 9656bbd4
      Konstantine Karantasis 创作于
      With AK 3.0, idempotence was enabled by default in Kafka producers. However, if idempotence is enabled, Connect won't be able to communicate via its producers with Kafka brokers older than version 0.11. Perhaps more importantly, for brokers older than version 2.8 the IDEMPOTENT_WRITE ACL is required to be granted to the principal of the Connect worker.
      
      Therefore this commit disables producer idempotence by default to all the producers instantiated by Connect. Users can still choose to enable producer idempotence by explicitly setting the right worker and/or connector properties.
      
      The changes were tested via existing unit, integration and system tests.
      
      Reviewers: Randall Hauch <rhauch@gmail.com>
      9656bbd4
  24. 3月 23, 2022
  25. 3月 22, 2022
加载中