1
- # librdkafka v2.11.0
1
+ # librdkafka v2.10.1
2
2
3
- librdkafka v2.11.0 is a feature release:
3
+ librdkafka v2.10.1 is a maintenance release:
4
4
5
- * Fix for frequent disconnections on push telemetry requests
6
- with particular metric configurations (#4912 ).
7
- * Avoid copy outside boundaries when reading metric names in telemetry
8
- subscription (#5105 )
9
- * Metrics aren't duplicated when multiple prefixes match them (#5104 )
5
+ * Fix to add locks when updating the metadata cache for the consumer
6
+ after no broker connection is available (@marcin-krystianc , #5066 ).
7
+ * Fix to the re-bootstrap case when ` bootstrap.servers ` is ` NULL ` and
8
+ brokers were added manually through ` rd_kafka_brokers_add ` (#5067 ).
9
+ * Fix an issue where the first message to any topic produced via ` producev ` or
10
+ ` produceva ` was delivered late (by up to 1 second) (#5032 ).
11
+ * Fix for a loop of re-bootstrap sequences in case the client reaches the
12
+ ` all brokers down ` state (#5086 ).
13
+ * Fix for frequent disconnections on push telemetry requests
14
+ with particular metric configurations (#4912 ).
15
+ * Avoid copy outside boundaries when reading metric names in telemetry
16
+ subscription (#5105 )
17
+ * Metrics aren't duplicated when multiple prefixes match them (#5104 )
10
18
11
19
12
20
## Fixes
13
21
22
+ ### General fixes
23
+
24
+ * Issues: #5088 .
25
+ Fix for a loop of re-bootstrap sequences in case the client reaches the
26
+ ` all brokers down ` state. The client continues to select the
27
+ bootstrap brokers given they have no connection attempt and doesn't
28
+ re-connect to the learned ones. In case it happens a broker restart
29
+ can break the loop for the clients using the affected version.
30
+ Fixed by giving a higher chance to connect to the learned brokers
31
+ even if there are new ones that never tried to connect.
32
+ Happens since 2.10.0 (#5086 ).
33
+ * Issues: #5057 .
34
+ Fix to the re-bootstrap case when ` bootstrap.servers ` is ` NULL ` and
35
+ brokers were added manually through ` rd_kafka_brokers_add ` .
36
+ Avoids a segmentation fault in this case.
37
+ Happens since 2.10.0 (#5067 ).
38
+
39
+ ### Producer fixes
40
+
41
+ * In case of ` producev ` or ` produceva ` , the producer did not enqueue a leader
42
+ query metadata request immediately, and rather, waited for the 1 second
43
+ timer to kick in. This could cause delays in the sending of the first message
44
+ by up to 1 second.
45
+ Happens since 1.x (#5032 ).
46
+
47
+ ### Consumer fixes
48
+
49
+ * Issues: #5051 .
50
+ Fix to add locks when updating the metadata cache for the consumer.
51
+ It can cause memory corruption or use-after-free in case
52
+ there's no broker connection and the consumer
53
+ group metadata needs to be updated.
54
+ Happens since 2.10.0 (#5066 ).
55
+
14
56
### Telemetry fixes
15
57
16
- * Issues: #5106
58
+ * Issues: #5106 .
17
59
Fix for frequent disconnections on push telemetry requests
18
60
with particular metric configurations.
19
61
A ` NULL ` payload is sent in a push telemetry request when
@@ -22,65 +64,17 @@ librdkafka v2.11.0 is a feature release:
22
64
some metrics are matching the producer but none the consumer
23
65
or the other way around.
24
66
Happens since 2.5.0 (#4912 ).
25
- * Issues: #5102
67
+ * Issues: #5102 .
26
68
Avoid copy outside boundaries when reading metric names in telemetry
27
69
subscription. It can cause that some metrics aren't matched.
28
70
Happens since 2.5.0 (#5105 ).
29
- * Issues: #5103
30
- Metrics aren't duplicated when multiple prefixes match them.
71
+ * Issues: #5103 .
72
+ Telemetry metrics aren't duplicated when multiple prefixes match them.
31
73
Fixed by keeping track of the metrics that already matched.
32
74
Happens since 2.5.0 (#5104 ).
33
75
34
76
35
77
36
- # librdkafka v2.10.1
37
-
38
- librdkafka v2.10.1 is a maintenance release:
39
-
40
- * Fix to add locks when updating the metadata cache for the consumer
41
- after no broker connection is available (@marcin-krystianc , #5066 ).
42
- * Fix to the re-bootstrap case when ` boostrap.servers ` is ` NULL ` and
43
- brokers were added manually through ` rd_kafka_brokers_add ` (#5067 ).
44
- * Fix an issue where the first message to any topic produced via ` producev ` or
45
- ` produceva ` was not delivered late (by up to 1 second) (#5032 ).
46
- * Fix for a loop of re-bootstrap sequences in case the client reaches the
47
- ` all brokers down ` state (#5086 ).
48
-
49
-
50
- ## Fixes
51
-
52
- ### Producer fixes
53
-
54
- * In case of ` producev ` or ` produceva ` , the producer did not enqueue a leader
55
- query metadata request immediately, and rather, waited for the 1 second
56
- timer to kick in. This could cause delays in the sending of the first message
57
- by up to 1 second. (#5032 ).
58
-
59
- ### Consumer fixes
60
-
61
- * Issues: #5051
62
- Fix to add locks when updating the metadata cache for the consumer.
63
- It can cause memory corruption or use-after-free in case
64
- there's no broker connection and the consumer
65
- group metadata needs to be updated.
66
- Happens since 2.10.0 (#5066 ).
67
- * Issues: #5057
68
- Fix to the re-bootstrap case when ` boostrap.servers ` is ` NULL ` and
69
- brokers were added manually through ` rd_kafka_brokers_add ` .
70
- Avoids a segmentation fault in this case.
71
- Happens since 2.10.0 (#5067 ).
72
- * Issues: #5088
73
- Fix for a loop of re-bootstrap sequences in case the client reaches the
74
- ` all brokers down ` state. The client continues to select the
75
- bootstrap brokers given they have no connection attempt and doesn't
76
- re-connect to the learned ones. In case it happens a broker restart
77
- can break the loop for the clients using the affected version.
78
- Fixed by giving a higher chance to connect to the learned brokers
79
- even if there are new ones that never tried to connect.
80
- Happens since 2.10.0 (#5086 ).
81
-
82
-
83
-
84
78
# librdkafka v2.10.0
85
79
86
80
librdkafka v2.10.0 is a feature release:
0 commit comments