Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/confluentinc/librdkafka/releases below:

Website Navigation

• Releases
• Tags

Releases · confluentinc/librdkafka · GitHub

librdkafka v2.11.0 is a feature release:

• KIP-1102 Enable clients to rebootstrap based on timeout or error code (#4981).
• KIP-1139 Add support for OAuth jwt-bearer grant type (#4978).
• Fix for poll ratio calculation in case the queues are forwarded (#5017).
• Fix data race when buffer queues are being reset instead of being
  initialized (#4718).
• Features BROKER_BALANCED_CONSUMER and SASL_GSSAPI don't depend on
  JoinGroup v0 anymore, missing in AK 4.0 and CP 8.0 (#5131).
• Improve HTTPS CA certificates configuration by probing several paths
  when OpenSSL is statically linked and providing a way to customize their location
  or value (#5133).

• Issues: #4522.
  A data race happened when emptying buffers of a failing broker, in its thread,
  with the statistics callback in main thread gathering the buffer counts.
  Solved by resetting the atomic counters instead of initializing them.
  Happening since 1.x (#4718).
• Issues: #4948
  Features BROKER_BALANCED_CONSUMER and SASL_GSSAPI don't depend on
  JoinGroup v0 anymore, missing in AK 4.0 and CP 8.0. This PR partially
  fixes the linked issue, a complete fix for all features will follow.
  Rest of fixes are necessary only for a subsequent Apache Kafka major
  version (e.g. AK 5.x).
  Happening since 1.x (#5131).

• Issues: #5109
  Fix for poll ratio calculation in case the queues are forwarded.
  Poll ratio is now calculated per-queue instead of per-instance and
  it allows to avoid calculation problems linked to using the same
  field.
  Happens since 2.6.0 (#5017).

Release asset checksums:

• v2.11.0.zip SHA256 9e76a408f0ed346f21be5e2df58b672d07ff9c561a5027f16780d1b26ef24683
• v2.11.0.tar.gz SHA256 592a823dc7c09ad4ded1bc8f700da6d4e0c88ffaf267815c6f25e7450b9395ca

librdkafka v2.10.1 is a maintenance release:

• Fix to add locks when updating the metadata cache for the consumer
  after no broker connection is available (@marcin-krystianc, #5066).
• Fix to the re-bootstrap case when bootstrap.servers is NULL and
  brokers were added manually through rd_kafka_brokers_add (#5067).
• Fix an issue where the first message to any topic produced via producev or
  produceva was delivered late (by up to 1 second) (#5032).
• Fix for a loop of re-bootstrap sequences in case the client reaches the
  all brokers down state (#5086).
• Fix for frequent disconnections on push telemetry requests
  with particular metric configurations (#4912).
• Avoid copy outside boundaries when reading metric names in telemetry
  subscription (#5105)
• Metrics aren't duplicated when multiple prefixes match them (#5104)

• Issues: #5088.
  Fix for a loop of re-bootstrap sequences in case the client reaches the
  all brokers down state. The client continues to select the
  bootstrap brokers given they have no connection attempt and doesn't
  re-connect to the learned ones. In case it happens a broker restart
  can break the loop for the clients using the affected version.
  Fixed by giving a higher chance to connect to the learned brokers
  even if there are new ones that never tried to connect.
  Happens since 2.10.0 (#5086).
• Issues: #5057.
  Fix to the re-bootstrap case when bootstrap.servers is NULL and
  brokers were added manually through rd_kafka_brokers_add.
  Avoids a segmentation fault in this case.
  Happens since 2.10.0 (#5067).

• In case of producev or produceva, the producer did not enqueue a leader
  query metadata request immediately, and rather, waited for the 1 second
  timer to kick in. This could cause delays in the sending of the first message
  by up to 1 second.
  Happens since 1.x (#5032).

• Issues: #5051.
  Fix to add locks when updating the metadata cache for the consumer.
  It can cause memory corruption or use-after-free in case
  there's no broker connection and the consumer
  group metadata needs to be updated.
  Happens since 2.10.0 (#5066).

• Issues: #5106.
  Fix for frequent disconnections on push telemetry requests
  with particular metric configurations.
  A NULL payload is sent in a push telemetry request when
  an empty one is needed. This causes disconnections every time the
  push is sent, only when metrics are requested and
  some metrics are matching the producer but none the consumer
  or the other way around.
  Happens since 2.5.0 (#4912).
• Issues: #5102.
  Avoid copy outside boundaries when reading metric names in telemetry
  subscription. It can cause that some metrics aren't matched.
  Happens since 2.5.0 (#5105).
• Issues: #5103.
  Telemetry metrics aren't duplicated when multiple prefixes match them.
  Fixed by keeping track of the metrics that already matched.
  Happens since 2.5.0 (#5104).

Release asset checksums:

• v2.10.1.zip SHA256 7cb72c4f3d162f50d30d81fd7f7ba0f3d9e8ecd09d9b4c5af7933314e24dd0ba
• v2.10.1.tar.gz SHA256 75f59a2d948276504afb25bcb5713a943785a413b84f9099d324d26b2021f758

librdkafka v2.10.0 is a feature release:

• KIP-848 has transitioned from Early Access to Preview.
• Added support for regex-based subscriptions.
• Implemented client-side member ID generation as per KIP-1082.
• rd_kafka_DescribeConsumerGroups() now supports KIP-848-style consumer groups. Two new fields have been added:
  • Group type – Indicates whether the group is classic or consumer.
  • Target assignment – Applicable only to consumer protocol groups (defaults to NULL).
• Group configuration is now supported in AlterConfigs, IncrementalAlterConfigs, and DescribeConfigs. (#4939)
• Added Topic Authorization Error support in the ConsumerGroupHeartbeat response.
• Removed usage of the partition.assignment.strategy property for the consumer group protocol. An error will be raised if this is set with group.protocol=consumer.
• Deprecated and disallowed the following properties for the consumer group protocol:
  • session.timeout.ms
  • heartbeat.interval.ms
  • group.protocol.type
    Attempting to set any of these will result in an error.
• Enhanced handling for subscribe() and unsubscribe() edge cases.

Note

The KIP-848 consumer is currently in Preview and should not be used in production environments. Implementation is feature complete but contract could have minor changes before General Availability.

• Identify brokers only by broker id (#4557, @mfleming)
• Remove unavailable brokers and their thread (#4557, @mfleming)
• Commits during a cooperative incremental rebalance aren't causing
  an assignment lost if the generation id was bumped in between (#4908).
• Fix for librdkafka yielding before timeouts had been reached (#4970)
• Removed a 500ms latency when a consumer partition switches to a different
  leader (#4970)
• The mock cluster implementation removes brokers from Metadata response
  when they're not available, this simulates better the actual behavior of
  a cluster that is using KRaft (#4970).
• Doesn't remove topics from cache on temporary Metadata errors but only
  on metadata cache expiry (#4970).
• Doesn't mark the topic as unknown if it had been marked as existent earlier
  and topic.metadata.propagation.max.ms hasn't passed still (@marcin-krystianc, #4970).
• Doesn't update partition leaders if the topic in metadata
  response has errors (#4970).
• Only topic authorization errors in a metadata response are considered
  permanent and are returned to the user (#4970).
• The function rd_kafka_offsets_for_times refreshes leader information
  if the error requires it, allowing it to succeed on
  subsequent manual retries (#4970).
• Deprecated api.version.request, api.version.fallback.ms and
  broker.version.fallback configuration properties (#4970).
• When consumer is closed before destroying the client, the operations queue
  isn't purged anymore as it contains operations
  unrelated to the consumer group (#4970).
• When making multiple changes to the consumer subscription in a short time,
  no unknown topic error is returned for topics that are in the new subscription but weren't in previous one (#4970).
• Prevent metadata cache corruption when topic id changes
  (@kwdubuc, @marcin-krystianc, @GerKr, #4970).
• Fix for the case where a metadata refresh enqueued on an unreachable broker
  prevents refreshing the controller or the coordinator until that broker
  becomes reachable again (#4970).
• Remove a one second wait after a partition fetch is restarted following a
  leader change and offset validation (#4970).
• Fix the Nagle algorithm (TCP_NODELAY) on broker sockets to not be enabled
  by default (#4986).

• Issues: #4212
  Identify brokers only by broker id, as happens in Java,
  avoid to find the broker with same hostname and use the same thread
  and connection.
  Happens since 1.x (#4557, @mfleming).
• Issues: #4557
  Remove brokers not reported in a metadata call, along with their thread.
  Avoids that unavailable brokers are selected for a new connection when
  there's no one available. We cannot tell if a broker was removed
  temporarily or permanently so we always remove it and it'll be added back when
  it becomes available again.
  Happens since 1.x (#4557, @mfleming).
• Issues: #4970
  librdkafka code using cnd_timedwait was yielding before a timeout occurred
  without the condition being fulfilled because of spurious wake-ups.
  Solved by verifying with a monotonic clock that the expected point in time
  was reached and calling the function again if needed.
  Happens since 1.x (#4970).
• Issues: #4970
  Doesn't remove topics from cache on temporary Metadata errors but only
  on metadata cache expiry. It allows the client to continue working
  in case of temporary problems to the Kafka metadata plane.
  Happens since 1.x (#4970).
• Issues: #4970
  Doesn't mark the topic as unknown if it had been marked as existent earlier
  and topic.metadata.propagation.max.ms hasn't passed still. It achieves
  this property expected effect even if a different broker had
  previously reported the topic as existent.
  Happens since 1.x (@marcin-krystianc, #4970).
• Issues: #4907
  Doesn't update partition leaders if the topic in metadata
  response has errors. It's in line with what Java client does and allows
  to avoid segmentation faults for unknown partitions.
  Happens since 1.x (#4970).
• Issues: #4970
  Only topic authorization errors in a metadata response are considered
  permanent and are returned to the user. It's in line with what Java client
  does and avoids returning to the user an error that wasn't meant to be
  permanent.
  Happens since 1.x (#4970).
• Issues: #4964, #4778
  Prevent metadata cache corruption when topic id for the same topic name
  changes. Solved by correctly removing the entry with the old topic id from metadata cache
  to prevent subsequent use-after-free.
  Happens since 2.4.0 (@kwdubuc, @marcin-krystianc, @GerKr, #4970).
• Issues: #4970
  Fix for the case where a metadata refresh enqueued on an unreachable broker
  prevents refreshing the controller or the coordinator until that broker
  becomes reachable again. Given the request continues to be retried on that
  broker, the counter for refreshing complete broker metadata doesn't reach
  zero and prevents the client from obtaining the new controller or group or transactional coordinator.
  It causes a series of debug messages like:
  "Skipping metadata request: ... full request already in-transit", until
  the broker the request is enqueued on is up again.
  Solved by not retrying these kinds of metadata requests.
  Happens since 1.x (#4970).
• The Nagle algorithm (TCP_NODELAY) is now disabled by default. It caused a
  large increase in latency for some use cases, for example, when using an
  SSL connection.
  For efficient batching, the application should use linger.ms,
  batch.size etc.
  Happens since: 0.x (#4986).

• Issues: #4059
  Commits during a cooperative incremental rebalance could cause an
  assignment lost if the generation id was bumped by a second join
  group request.
  Solved by not rejoining the group in case an illegal generation error happens
  during a rebalance.
  Happening since v1.6.0 (#4908)
• Issues: #4970
  When switching to a different leader a consumer could wait 500ms
  (fetch.error.backoff.ms) before starting to fetch again. The fetch backoff wasn't reset when joining the new broker.
  Solved by resetting it, given it's not needed to backoff
  the first fetch on a different node. This way faster leader switches are
  possible.
  Happens since 1.x (#4970).
• Issues: #4970
  The function rd_kafka_offsets_for_times refreshes leader information
  if the error requires it, allowing it to succeed on
  subsequent manual retries. Similar to the fix done in 2.3.0 in
  rd_kafka_query_watermark_offsets. Additionally, the partition
  current leader epoch is taken from metadata cache instead of
  from passed partitions.
  Happens since 1.x (#4970).
• Issues: #4970
  When consumer is closed before destroying the client, the operations queue
  isn't purged anymore as it contains operations
  unrelated to the consumer group.
  Happens since 1.x (#4970).
• Issues: #4970
  When making multiple changes to the consumer subscription in a short time,
  no unknown topic error is returned for topics that are in the new subscription
  but weren't in previous one. This was due to the metadata request relative
  to previous subscription.
  Happens since 1.x (#4970).
• Issues: #4970
  Remove a one second wait after a partition fetch is restarted following a
  leader change and offset validation. This is done by resetting the fetch
  error backoff and waking up the delegated broker if present.
  Happens since 2.1.0 (#4970).

Note: there was no v2.9.0 librdkafka release,
it was a dependent clients release only

Release asset checksums:

• v2.10.0.zip SHA256 e30944f39b353ee06e70861348011abfc32d9ab6ac850225b0666e9d97b9090d
• v2.10.0.tar.gz ...

librdkafka v2.8.0 is a maintenance release:

• Socket options are now all set before connection (#4893).
• Client certificate chain is now sent when using ssl.certificate.pem
  or ssl_certificate or ssl.keystore.location (#4894).
• Avoid sending client certificates whose chain doesn't match with broker
  trusted root certificates (#4900).
• Fixes to allow to migrate partitions to leaders with same leader epoch,
  or NULL leader epoch (#4901).
• Support versions of OpenSSL without the ENGINE component (Chris Novakovic, #3535
  and @remicollet, #4911).

• Socket options are now all set before connection, as documentation
  says it's needed for socket buffers to take effect, even if in some
  cases they could have effect even after connection.
  Happening since v0.9.0 (#4893).
• Issues: #3225.
  Client certificate chain is now sent when using ssl.certificate.pem
  or ssl_certificate or ssl.keystore.location.
  Without that, broker must explicitly add any intermediate certification
  authority certificate to its truststore to be able to accept client
  certificate.
  Happens since: 1.x (#4894).

• Issues: #4796.
  Fix to allow to migrate partitions to leaders with NULL leader epoch.
  NULL leader epoch can happen during a cluster roll with an upgrade to a
  version supporting KIP-320.
  Happening since v2.1.0 (#4901).
• Issues: #4804.
  Fix to allow to migrate partitions to leaders with same leader epoch.
  Same leader epoch can happen when partition is
  temporarily migrated to the internal broker (#4804), or if broker implementation
  never bumps it, as it's not needed to validate the offsets.
  Happening since v2.4.0 (#4901).

Note: there was no v2.7.0 librdkafka release

Release asset checksums:

• v2.8.0.zip SHA256 5525efaad154e277e6ce30ab78bb00dbd882b5eeda6c69c9eeee69b7abee11a4
• v2.8.0.tar.gz SHA256 5bd1c46f63265f31c6bfcedcde78703f77d28238eadf23821c2b43fc30be3e25

Note: given this patch version contains only a single fix, it's suggested to upgrade to latest backward compatible release instead, as it contains all the issued fixes.
Following semver 2.0, all our patch and minor releases are backward compatible and our minor releases may also contain fixes.
Please note that 2.x versions of librdkafka are also backward compatible with 1.x as the major version release was only for the upgrade to OpenSSL 3.x.

librdkafka v2.2.1 is a maintenance release backporting:

• Fix for idempotent producer fatal errors, triggered after a possibly persisted message state (#4438).
• Update bundled lz4 (used when ./configure --disable-lz4-ext) to
  v1.9.4, which contains
  bugfixes and performance improvements (#4726).
• Upgrade OpenSSL to v3.0.13 (while building from source) with various security fixes,
  check the release notes
  (@janjwerner-confluent, #4690).
• Upgrade zstd to v1.5.6, zlib to v1.3.1, and curl to v8.8.0 (@janjwerner-confluent, #4690).
• Upgrade Linux dependencies: OpenSSL 3.0.15, CURL 8.10.1 (#4875).

Release asset checksums:

• v2.2.1.zip SHA256 2d7fdb54b17be8442b61649916b94eda1744c21d2325795d92f9ad6dec4e5621
• v2.2.1.tar.gz SHA256 c6f0ccea730ce8f67333e75cc785cce28a8941d5abf041d7a9b8fef91d4778e8

librdkafka v2.6.1 is a maintenance release:

• Fix for a Fetch regression when connecting to Apache Kafka < 2.7 (#4871).
• Fix for an infinite loop happening with cooperative-sticky assignor
  under some particular conditions (#4800).
• Fix for retrieving offset commit metadata when it contains
  zeros and configured with strndup (#4876)
• Fix for a loop of ListOffset requests, happening in a Fetch From Follower
  scenario, if such request is made to the follower (#4616, #4754, @kphelps).
• Fix to remove fetch queue messages that blocked the destroy of rdkafka
  instances (#4724)
• Upgrade Linux dependencies: OpenSSL 3.0.15, CURL 8.10.1 (#4875).
• Upgrade Windows dependencies: MSVC runtime to 14.40.338160.0,
  zstd 1.5.6, zlib 1.3.1, OpenSSL 3.3.2, CURL 8.10.1 (#4872).
• SASL/SCRAM authentication fix: avoid concatenating
  client side nonce once more, as it's already prepended in server sent nonce (#4895).
• Allow retrying for status code 429 ('Too Many Requests') in HTTP requests for
  OAUTHBEARER OIDC (#4902).

• SASL/SCRAM authentication fix: avoid concatenating
  client side nonce once more, as it's already prepended in
  server sent nonce.
  librdkafka was incorrectly concatenating the client side nonce again, leading to this fix being made on AK side, released with 3.8.1, with endsWith instead of equals.
  Happening since v0.0.99 (#4895).

• Issues: #4870
  Fix for a Fetch regression when connecting to Apache Kafka < 2.7, causing
  fetches to fail.
  Happening since v2.6.0 (#4871)
• Issues: #4783.
  A consumer configured with the cooperative-sticky partition assignment
  strategy could get stuck in an infinite loop, with corresponding spike of
  main thread CPU usage.
  That happened with some particular orders of members and potential
  assignable partitions.
  Solved by removing the infinite loop cause.
  Happening since: 1.6.0 (#4800).
• Issues: #4649.
  When retrieving offset metadata, if the binary value contained zeros
  and librdkafka was configured with strndup, part of
  the buffer after first zero contained uninitialized data
  instead of rest of metadata. Solved by avoiding to use
  strndup for copying metadata.
  Happening since: 0.9.0 (#4876).
• Issues: #4616
  When an out of range on a follower caused an offset reset, the corresponding
  ListOffsets request is made to the follower, causing a repeated
  "Not leader for partition" error. Fixed by sending the request always
  to the leader.
  Happening since 1.5.0 (tested version) or previous ones (#4616, #4754, @kphelps).
• Issues:
  Fix to remove fetch queue messages that blocked the destroy of rdkafka
  instances. Circular dependencies from a partition fetch queue message to
  the same partition blocked the destroy of an instance, that happened
  in case the partition was removed from the cluster while it was being
  consumed. Solved by purging internal partition queue, after being stopped
  and removed, to allow reference count to reach zero and trigger a destroy.
  Happening since 2.0.2 (#4724).

Release asset checksums:

• v2.6.1.zip SHA256 b575811865d9c0439040ccb2972ae6af963bc58ca39d433243900dddfdda79cf
• v2.6.1.tar.gz SHA256 0ddf205ad8d36af0bc72a2fec20639ea02e1d583e353163bf7f4683d949e901b

librdkafka v2.6.0 is a feature release:

• KIP-460 Admin Leader Election RPC (#4845)
• [KIP-714] Complete consumer metrics support (#4808).
• [KIP-714] Produce latency average and maximum metrics support for parity with Java client (#4847).
• [KIP-848] ListConsumerGroups Admin API now has an optional filter to return only groups
  of given types.
• Added Transactional id resource type for ACL operations (@JohnPreston, #4856).
• Fix for permanent fetch errors when using a newer Fetch RPC version with an older
  inter broker protocol (#4806).

• Issues: #4806
  Fix for permanent fetch errors when brokers support a Fetch RPC version greater than 12
  but cluster is configured to use an inter broker protocol that is less than 2.8.
  In this case returned topic ids are zero valued and Fetch has to fall back
  to version 12, using topic names.
  Happening since v2.5.0 (#4806)

Release asset checksums:

• v2.6.0.zip SHA256 e9eb7faedb24da3a19d5f056e08630fc2dae112d958f9b714ec6e35cd87c032e
• v2.6.0.tar.gz SHA256 abe0212ecd3e7ed3c4818a4f2baf7bf916e845e902bb15ae48834ca2d36ac745

librdkafka v2.5.3 is a maintenance release.

• Fix an assert being triggered during push telemetry call when no metrics matched on the client side. (#4826)

• Issue: #4833
  Fix a regression introduced with KIP-714 support in which an assert is triggered during PushTelemetry call. This happens when no metric is matched on the client side among those requested by broker subscription.
  Happening since 2.5.0 (#4826).

Release asset checksums:

• v2.5.3.zip SHA256 5b058006fcd403bc23fc1fcc14fe985641203f342c5715794af51023bcd047f9
• v2.5.3.tar.gz SHA256 eaa1213fdddf9c43e28834d9a832d9dd732377d35121e42f875966305f52b8ff

Note: there were no v2.5.1 and v2.5.2 librdkafka releases

Warning

This version has introduced a regression in which an assert is triggered during PushTelemetry call. This happens when no metric is matched on the client side among those requested by broker subscription.

You won't face any problem if:

• Broker doesn't support KIP-714.
• KIP-714 feature is disabled on the broker side.
• KIP-714 feature is disabled on the client side. This is enabled by default. Set configuration enable.metrics.push to false.
• If KIP-714 is enabled on the broker side and there is no subscription configured there.
• If KIP-714 is enabled on the broker side with subscriptions that match the KIP-714 metrics defined on the client.

Having said this, we strongly recommend using v2.5.3 and above to not face this regression at all.

librdkafka v2.5.0 is a feature release.

• KIP-951
  Leader discovery optimisations for the client (#4756, #4767).
• Fix segfault when using long client id because of erased segment when using flexver. (#4689)
• Fix for an idempotent producer error, with a message batch not reconstructed
  identically when retried (#4750)
• Removed support for CentOS 6 and CentOS 7 (#4775).
• KIP-714 Client
  metrics and observability (#4721).

• CentOS 6 and CentOS 7 support was removed as they reached EOL
  and security patches aren't publicly available anymore.
  ABI compatibility from CentOS 8 on is maintained through pypa/manylinux,
  AlmaLinux based.
  See also Confluent supported OSs page (#4775).

• Update bundled lz4 (used when ./configure --disable-lz4-ext) to
  v1.9.4, which contains
  bugfixes and performance improvements (#4726).
• KIP-951
  With this KIP leader updates are received through Produce and Fetch responses
  in case of errors corresponding to leader changes and a partition migration
  happens before refreshing the metadata cache (#4756, #4767).

• Issues: confluentinc/confluent-kafka-dotnet#2084
  Fix segfault when a segment is erased and more data is written to the buffer.
  Happens since 1.x when a portion of the buffer (segment) is erased for flexver or compression.
  More likely to happen since 2.1.0, because of the upgrades to flexver, with certain string sizes like a long client id (#4689).

• Issues: #4736
  Fix for an idempotent producer error, with a message batch not reconstructed
  identically when retried. Caused the error message "Local: Inconsistent state: Unable to reconstruct MessageSet".
  Happening on large batches. Solved by using the same backoff baseline for all messages
  in the batch.
  Happens since 2.2.0 (#4750).

Release asset checksums:

• v2.5.0.zip SHA256 644c1b7425e2241ee056cf8a469c84d69c7f6a88559491c0813a6cdeb5563206
• v2.5.0.tar.gz SHA256 3dc62de731fd516dfb1032861d9a580d4d0b5b0856beb0f185d06df8e6c26259

librdkafka v2.4.0 is a feature release:

• KIP-848: The Next Generation of the Consumer Rebalance Protocol.
  Early Access: This should be used only for evaluation and must not be used in production. Features and contract of this KIP might change in future (#4610).
• KIP-467: Augment ProduceResponse error messaging for specific culprit records (#4583).
• KIP-516
  Continue partial implementation by adding a metadata cache by topic id
  and updating the topic id corresponding to the partition name (#4676)
• Upgrade OpenSSL to v3.0.12 (while building from source) with various security fixes,
  check the release notes.
• Integration tests can be started in KRaft mode and run against any
  GitHub Kafka branch other than the released versions.
• Fix pipeline inclusion of static binaries (#4666)
• Fix to main loop timeout calculation leading to a tight loop for a
  max period of 1 ms (#4671).
• Fixed a bug causing duplicate message consumption from a stale
  fetch start offset in some particular cases (#4636)
• Fix to metadata cache expiration on full metadata refresh (#4677).
• Fix for a wrong error returned on full metadata refresh before joining
  a consumer group (#4678).
• Fix to metadata refresh interruption (#4679).
• Fix for an undesired partition migration with stale leader epoch (#4680).
• Fix hang in cooperative consumer mode if an assignment is processed
  while closing the consumer (#4528).

• With KIP 467, INVALID_MSG (Java: CorruptRecordExpection) will
  be retried automatically. INVALID_RECORD (Java: InvalidRecordException) instead
  is not retriable and will be set only to the records that caused the
  error. Rest of records in the batch will fail with the new error code
  _INVALID_DIFFERENT_RECORD (Java: KafkaException) and can be retried manually,
  depending on the application logic (#4583).

• With this new protocol the role of the Group Leader (a member) is removed and
  the assignment is calculated by the Group Coordinator (a broker) and sent
  to each member through heartbeats.

  The feature is still not production-ready.
  It's possible to try it in a non-production enviroment.

  A guide is available
  with considerations and steps to follow to test it (#4610).

• Issues: confluentinc/confluent-kafka-go#981.
  In librdkafka release pipeline a static build containing libsasl2
  could be chosen instead of the alternative one without it.
  That caused the libsasl2 dependency to be required in confluent-kafka-go
  v2.1.0-linux-musl-arm64 and v2.3.0-linux-musl-arm64.
  Solved by correctly excluding the binary configured with that library,
  when targeting a static build.
  Happening since v2.0.2, with specified platforms,
  when using static binaries (#4666).
• Issues: #4684.
  When the main thread loop was awakened less than 1 ms
  before the expiration of a timeout, it was serving with a zero timeout,
  leading to increased CPU usage until the timeout was reached.
  Happening since 1.x.
• Issues: #4685.
  Metadata cache was cleared on full metadata refresh, leading to unnecessary
  refreshes and occasional UNKNOWN_TOPIC_OR_PART errors. Solved by updating
  cache for existing or hinted entries instead of clearing them.
  Happening since 2.1.0 (#4677).
• Issues: #4589.
  A metadata call before member joins consumer group,
  could lead to an UNKNOWN_TOPIC_OR_PART error. Solved by updating
  the consumer group following a metadata refresh only in safe states.
  Happening since 2.1.0 (#4678).
• Issues: #4577.
  Metadata refreshes without partition leader change could lead to a loop of
  metadata calls at fixed intervals. Solved by stopping metadata refresh when
  all existing metadata is non-stale. Happening since 2.3.0 (#4679).
• Issues: #4687.
  A partition migration could happen, using stale metadata, when the partition
  was undergoing a validation and being retried because of an error.
  Solved by doing a partition migration only with a non-stale leader epoch.
  Happening since 2.1.0 (#4680).

• Issues: #4686.
  In case of subscription change with a consumer using the cooperative assignor
  it could resume fetching from a previous position.
  That could also happen if resuming a partition that wasn't paused.
  Fixed by ensuring that a resume operation is completely a no-op when
  the partition isn't paused.
  Happening since 1.x (#4636).
• Issues: #4527.
  While using the cooperative assignor, given an assignment is received while closing the consumer
  it's possible that it gets stuck in state WAIT_ASSIGN_CALL, while the method is converted to
  a full unassign. Solved by changing state from WAIT_ASSIGN_CALL to WAIT_UNASSIGN_CALL
  while doing this conversion.
  Happening since 1.x (#4528).

Release asset checksums:

• v2.4.0.zip SHA256 24b30d394fc6ce5535eaa3c356ed9ed9ae4a6c9b4fc9159c322a776786d5dd15
• v2.4.0.tar.gz SHA256 d645e47d961db47f1ead29652606a502bdd2a880c85c1e060e94eea040f1a19a

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4