[
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)
