librdkafka
No description set
- Devel package for openSUSE:Factory
-
2
derived packages
- Links to openSUSE:Factory / librdkafka
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout devel:libraries:c_c++/librdkafka && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
_link | 0000000124 124 Bytes | |
librdkafka.changes | 0000017789 17.4 KB | |
librdkafka.spec | 0000003440 3.36 KB | |
v1.6.1.tar.gz | 0002920909 2.79 MB |
Revision 24 (latest revision is 41)
Dirk Mueller (dirkmueller)
committed
(revision 24)
- update to 1.6.1: * Fatal idempotent producer errors are now also fatal to the transactional producer. This is a necessary step to maintain data integrity prior to librdkafka supporting KIP-360. Applications should check any transactional API errors for the is_fatal flag and decommission the transactional producer if the flag is set. * The consumer error raised by `auto.offset.reset=error` now has error-code set to `ERR__AUTO_OFFSET_RESET` to allow an application to differentiate between auto offset resets and other consumer errors. * Admin API and transactional `send_offsets_to_transaction()` coordinator requests, such as TxnOffsetCommitRequest, could in rare cases be sent multiple times which could cause a crash. * `ssl.ca.location=probe` is now enabled by default on Mac OSX since the librdkafka-bundled OpenSSL might not have the same default CA search paths as the system or brew installed OpenSSL. Probing scans all known locations. * Fatal idempotent producer errors are now also fatal to the transactional producer. * The transactional producer could crash if the transaction failed while `send_offsets_to_transaction()` was called. * Group coordinator requests for transactional `send_offsets_to_transaction()` calls would leak memory if the underlying request was attempted to be sent after the transaction had failed. * When gradually producing to multiple partitions (resulting in multiple underlying AddPartitionsToTxnRequests) sub-sequent partitions could get stuck in pending state under certain conditions. These pending partitions would not send queued messages to the broker and eventually trigger message timeouts, failing the current transaction. This is now fixed. * Committing an empty transaction (no messages were produced and no offsets were sent) would previously raise a fatal error due to invalid state
Comments 0