[
https://issues.apache.org/jira/browse/KAFKA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16609249#comment-16609249
]
Suman B N commented on KAFKA-6764:
----------------------------------
consumer.subscribe() should be called whenever group id is specified no matter
whether partition/offset is specified or not. If partition/offset is specified,
then it should be seek(TopicPartition) accordingly.
Console-consumer without group id can be assigned partition/offset based on
config specifed. Unless specified, subscribe() is honoured in current scenario.
That provides consistent behaviour as follows:
* With group-id, always subscribe and auto-assign. Seek based on
partition/offset config.
* Without group-id (Auto Commit Offset is always disabled):
** Partition/Offset specified, then assign.
** Partition/Offset not specified, then subscribe.
> 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
(v7.6.3#76005)