[
https://issues.apache.org/jira/browse/KAFKA-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516727#comment-16516727
]
Brett Rann commented on KAFKA-7044:
-----------------------------------
OK for my reproducible case, after doing a git bisect the bug is introduced in
this commit:
[https://github.com/apache/kafka/commit/677881afc52485aef94150be50d6258d7a340071#diff-b45245913eaae46aa847d2615d62cde0R164]
Pinging [~hachikuji] who authored the commit and [~rsivaram] who reviewed it.
The PR is: https://github.com/apache/kafka/pull/4557
( that commit is interestingly is after your change to that :612 block of
ConsumerGroupCommand.scala [~vahid])
I was interested by the Long2long part of the debug output (that I get and Jeff
posted also) so searched for big Long that in that commit.
{noformat}
+ final Long timestamp; // null if the broker does not support returning
timestamps{noformat}
While I was trying to read code I don't understand much, I changed that to
little long and kicked off a build. Obviously not the right fix, it's
referenced as Long in many places in that code and other files, but builds are
cheap right?
Then I saw that it wasn't introduced in that PR, it was just moved a little to
make the comment a single liner:
{noformat}
- final Long timestamp;{noformat}
The thing is. That build with it changed to little long works. :) Whaa?
My scala dev here says "assigning null to a java long actually sets it to 0 so
you're accidentally getting rid of the null before it has a chance to cause
heck".
So:
* I don't know what it that commit introduced the issue; It's somewhere in
that commit for me.
* given what my dev says, setting it to 0 instead of null might be one way to
avoid the null conversion
* or working out how that PR broke it and fixing it properly
It does seem that having null Long's is a trap waiting if there's going to be a
conversion to long at some other point though.
I"m happy to build and test a fix if someone comes up with one, against the
group where we're having the issue. Or to collect more info if needed.
> kafka-consumer-groups.sh NullPointerException describing round robin or
> sticky assignors
> ----------------------------------------------------------------------------------------
>
> Key: KAFKA-7044
> URL: https://issues.apache.org/jira/browse/KAFKA-7044
> Project: Kafka
> Issue Type: Bug
> Components: tools
> Affects Versions: 1.1.0
> Environment: CentOS 7.4, Oracle JDK 1.8
> Reporter: Jeff Field
> Assignee: Vahid Hashemian
> Priority: Minor
>
> We've recently moved to using the round robin assignor for one of our
> consumer groups, and started testing the sticky assignor. In both cases,
> using Kafka 1.1.0 we get a null pointer exception *unless* the group being
> described is rebalancing:
> {code:java}
> kafka-consumer-groups --bootstrap-server fqdn:9092 --describe --group
> groupname-for-consumer
> Error: Executing consumer group command failed due to null
> [2018-06-12 01:32:34,179] DEBUG Exception in consumer group command
> (kafka.admin.ConsumerGroupCommand$)
> java.lang.NullPointerException
> at scala.Predef$.Long2long(Predef.scala:363)
> at
> kafka.admin.ConsumerGroupCommand$KafkaConsumerGroupService$$anonfun$getLogEndOffsets$2.apply(ConsumerGroupCommand.scala:612)
> at
> kafka.admin.ConsumerGroupCommand$KafkaConsumerGroupService$$anonfun$getLogEndOffsets$2.apply(ConsumerGroupCommand.scala:610)
> at
> scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
> at
> scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
> at scala.collection.immutable.List.foreach(List.scala:392)
> at scala.collection.TraversableLike$class.map(TraversableLike.scala:234)
> at scala.collection.immutable.List.map(List.scala:296)
> at
> kafka.admin.ConsumerGroupCommand$KafkaConsumerGroupService.getLogEndOffsets(ConsumerGroupCommand.scala:610)
> at
> kafka.admin.ConsumerGroupCommand$ConsumerGroupService$class.describePartitions(ConsumerGroupCommand.scala:328)
> at
> kafka.admin.ConsumerGroupCommand$ConsumerGroupService$class.collectConsumerAssignment(ConsumerGroupCommand.scala:308)
> at
> kafka.admin.ConsumerGroupCommand$KafkaConsumerGroupService.collectConsumerAssignment(ConsumerGroupCommand.scala:544)
> at
> kafka.admin.ConsumerGroupCommand$KafkaConsumerGroupService$$anonfun$10$$anonfun$13.apply(ConsumerGroupCommand.scala:571)
> at
> kafka.admin.ConsumerGroupCommand$KafkaConsumerGroupService$$anonfun$10$$anonfun$13.apply(ConsumerGroupCommand.scala:565)
> at scala.collection.immutable.List.flatMap(List.scala:338)
> at
> kafka.admin.ConsumerGroupCommand$KafkaConsumerGroupService$$anonfun$10.apply(ConsumerGroupCommand.scala:565)
> at
> kafka.admin.ConsumerGroupCommand$KafkaConsumerGroupService$$anonfun$10.apply(ConsumerGroupCommand.scala:558)
> at scala.Option.map(Option.scala:146)
> at
> kafka.admin.ConsumerGroupCommand$KafkaConsumerGroupService.collectGroupOffsets(ConsumerGroupCommand.scala:558)
> at
> kafka.admin.ConsumerGroupCommand$ConsumerGroupService$class.describeGroup(ConsumerGroupCommand.scala:271)
> at
> kafka.admin.ConsumerGroupCommand$KafkaConsumerGroupService.describeGroup(ConsumerGroupCommand.scala:544)
> at kafka.admin.ConsumerGroupCommand$.main(ConsumerGroupCommand.scala:77)
> at kafka.admin.ConsumerGroupCommand.main(ConsumerGroupCommand.scala)
> [2018-06-12 01:32:34,255] DEBUG Removed sensor with name connections-closed:
> (org.apache.kafka.common.metrics.Metrics){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
