You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Move check_crcs and auto_create_topics to build_common_props (both supported by KafkaShareConsumer)
- Add CONSUMER_GROUP_ONLY_OPTIONS + validate_consumer_group_config! to raise on share_group_acknowledgement_on_error with consumer_group mode
- Release unprocessed records on shutdown in share_group_thread_runner instead of blocking on queue
- Replace ternary with if/else for @share_group_ack_error_type assignment
- Update consumer_threads docs with clearer partition/thread guidance per mode
- Update share group acknowledgement docs to clarify pipeline queue visibility boundary
- Update share_group_acknowledgement_on_error docs to frame around pipeline semantics
- Add note about broker/group-level equivalents for incompatible share_group options
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: docs/input-kafka.asciidoc
+18-18Lines changed: 18 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -58,10 +58,11 @@ you could run multiple Logstash instances with the same `group_id` to spread the
58
58
physical machines. Messages in a topic will be distributed to all Logstash instances with
59
59
the same `group_id`.
60
60
61
-
In `consumer_group` mode, you should ideally have as many threads as the number of partitions
62
-
for a perfect balance -- more threads than partitions means that some threads will be idle.
63
-
This does not apply in `share_group` mode, where any thread can fetch from any partition, so
64
-
the number of threads is not bounded by the partition count.
61
+
The number of consumer threads this input should spawn for fetching events and pushing them into the pipeline's queue.
62
+
63
+
When configured with `consumer_mode => consumer_group`, each partition in the topic can only be assigned to a single consumer at a time, so if the _total_ number of consumer threads across all consumers in the group exceeds the number of partitions, some of those threads will be idle.
64
+
65
+
This constraint doesn't apply when configured with `consumer_mode => share_group` which is not partition-oriented.
65
66
66
67
[id="plugins-{type}s-{plugin}-share-groups"]
67
68
==== Kafka Share Groups (queue semantics)
@@ -76,10 +77,9 @@ Requirements:
76
77
* Kafka brokers 4.0 or later with `group.share.enable=true`
77
78
* The `group_id` setting identifies the share group name
78
79
79
-
Share group consumers must acknowledge each record. Successful records are always acknowledged
80
-
as `ACCEPT`. The <<plugins-{type}s-{plugin}-share_group_acknowledgement_on_error>> option
81
-
controls acknowledgement for records that fail processing (`release` for redelivery or `reject`
82
-
to permanently discard).
80
+
Share group consumers must acknowledge each record.
81
+
After an event is accepted by the pipeline's queue, it is acknowledged as `ACCEPT` to ensure that no other consumer in the share group receives it.
82
+
When an event is either _not_ accepted by the pipeline's queue or an error occurs before it is offered to the queue, the <<plugins-{type}s-{plugin}-share_group_acknowledgement_on_error>> option controls how the event is acknowledged (`release` for redelivery or `reject` to permanently discard).
83
83
84
84
Example configuration:
85
85
@@ -350,7 +350,13 @@ Setting any of the following options in the pipeline config raises a configurati
350
350
`share_group` mode, since they do not apply to the Share Group protocol: `group_protocol`,
@@ -910,16 +916,10 @@ and a rebalance operation is triggered for the group identified by `group_id`
910
916
* Default value is `release`
911
917
* Only applicable when <<plugins-{type}s-{plugin}-consumer_mode>> is `share_group`
912
918
913
-
Controls how a record is acknowledged when an error occurs while processing it.
914
-
915
-
`release` (default): The record is released back to the share group for redelivery to any
916
-
available consumer. Use this when processing errors are transient and the record should
917
-
be retried.
918
-
919
-
`reject`: The record is permanently discarded and will not be redelivered. Use this when
920
-
the record is malformed and retrying would never succeed.
919
+
Controls how a record is acknowledged when the event is either not accepted by the pipeline's queue or an error occurs before it is offered.
921
920
922
-
Successfully processed records are always acknowledged as ACCEPT regardless of this setting.
921
+
* `release` (default): The record is released back to the share group for redelivery to any available consumer. This strategy favors consistency over availability, which can allow a single malformed event to be retried indefinitely.
922
+
* `reject`: The record is permanently discarded and will not be redelivered. This strategy favors availability over consistency and risks data loss.
0 commit comments