consumerconfigtable.md

BoostrapServers or "bootstrap.servers"
Tells the library which Kafka server cluster to connect to
GroupId or"group.id"
The consumer group the consumer is a member of
PartitionAssignmentStrategy or "partition.assignment.strategy"
Consumers in the same consumer group must have the same assignment strategy If a consumer attempts to join a group with a different assignment strategy, it will throw InconsistentGroupProtocolException Rebalancing can happen in a few scenarios: Adding a new Consumer to the group Removing a Consumer from the group Adding a new Partition to the Topic Rebalancing has two types: Eager: All consumers stop consuming (go idle) Assignment of partitions expire Consumers need to rejoin the group before partition re-assignment occurs. Cooperative Rebalance: Consumers of partitions that are not being reassigned continue consuming Only the specific partitions which need to be reassigned will not be consumed during rebalance	The partition assignment strategy is exposed through the PartitionAssignmentStrategy enum with the following values: PartitionAssignmentStrategy.Range: Assigns partitions 1-to-1 with consumers per topic in order of consumer id. It "starts over" the assignment at the beginning of the consumer list on every topic. So if you have 3 consumers, 2 topics, and 2 partitions per topic, only consumers 1 and 2 would have any partitions. See more here Some consumers can end up not being used PartitionAssignmentStrategy.RoundRobin: Assigns partitions to consumers in a round-robin fashion, even across topics (only if your consumers are listening to multiple topics) Rebalancing can result in many partition assignments being changed to accommodate even one consumer dying PartitionAssignmentStrategy.CooperativeSticky: Assigns partitions to consumers incrementally. Rebalancing distributes partitions in the following ways: In the case of a consumer leaving the group - it's partitions are reassigned to the incrementally to the remaining group members one by one. In the case of a consumer joining the group - partitions are taken one by one from all previously existing members of the group until the newly joined member has roughly the same number of partitions assigned. This is the preferred strategy in pretty much all cases. Default: [Range,CooperativeSticky]
AutoOffsetReset or "auto.offset.reset"
When a consumer group is newly added to a topic, it needs to know where to start If the topic has no initial offset value, then this option will determine which messages the new consumer group's consumer should start at	Available options: earliest: consume from the beginning of the topic partition latest: consumer from the end of the topic partition none: Throw an exception if no offset is set for the group
EnablePartitionEof or"enable.partition.eof"
Emit RD_KAFKA_RESP_ERR__PARTITION_EOF event when the consumer reaches the end of a partition We'll cover this in the exercises	True orFalse
EnableAutoCommit or"enable.auto.commit"
If true, will periodically commit the offset of the last message handed to a consumer We'll cover this in the exercises	True orFalse
EnableAutoOffsetStore or"enable.auto.offset.store"
Forces it to automatically store the offset of the last message handed to a consumer We'll cover this in the exercises	True orFalse
FetchMinBytes or"fetch.min.bytes"
Used for batching The minimum amount of data the server should return for a fetch request If insufficient data is available the request will wait for that much data to accumulate before answering the request Unless fetch.wait.max.ms expires WARNING: Bigger batches are more effective as network requests are optimized but may in extreme circumstances introduce some latency
FetchWaitMaxMs or "fetch.wait.max.ms"
Maximum time the broker may wait to fill the response with fetch.min.bytes of data	Defaults to 100