[ https://issues.apache.org/jira/browse/KAFKA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17164370#comment-17164370 ]
Pardhu Madipalli commented on KAFKA-6764: ----------------------------------------- I am observing this behavior with kafka broker with SSL enabled even with a new consumer group also. I produced a few messages. Then I created a new consumer with a new group. Then *kafka-console-consumer --from-beginning* is not displaying any messages. But when I tried with *--partition 0* I could see it reading the messages. Then I killed my broker with ssl and created a new broker without ssl. This time, even if I did not specify *--partition 0*, I can see all the messages as expected. In both the cases only a single broker is running. Topic partitions and replication factor are both 1. > ConsoleConsumer behavior inconsistent when specifying --partition with > --from-beginning > ---------------------------------------------------------------------------------------- > > Key: KAFKA-6764 > URL: https://issues.apache.org/jira/browse/KAFKA-6764 > Project: Kafka > Issue Type: Bug > Components: consumer > Reporter: Larry McQueary > Assignee: Larry McQueary > Priority: Minor > Labels: newbie > > Per its usage statement, {{kafka-console-consumer.sh}} ignores > {{\-\-from-beginning}} when the specified consumer group has committed > offsets, and sets {{auto.offset.reset}} to {{latest}}. However, if > {{\-\-partition}} is also specified, {{\-\-from-beginning}} is observed in > all cases, whether there are committed offsets or not. > This happens because when {{\-\-from-beginning}} is specified, {{offsetArg}} > is set to {{OffsetRequest.EarliestTime}}. However, {{offsetArg}} is [only > passed to the > constructor|https://github.com/apache/kafka/blob/fedac0cea74feeeece529ee1c0cefd6af53ecbdd/core/src/main/scala/kafka/tools/ConsoleConsumer.scala#L76-L79] > for {{NewShinyConsumer}} when {{\-\-partition}} is also specified. Hence, it > is honored in this case and not the other. > This case should either be handled consistently, or the usage statement > should be modified to indicate the actual behavior/usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)