[ https://issues.apache.org/jira/browse/STORM-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Balamurugan Kurunathan updated STORM-2994: ------------------------------------------ Comment: was deleted (was: Still, this issue reproducing for me with the latest version of storm-kafka-client-1.2.2 I can able to reproduce the same issue. ProcessingGuarantee - AT_LEAST_ONCE MaxUncommittedOffsets - 1000 KafkaSpout kafkaSpout = new KafkaSpout<>(kafkaSpoutConfig); builder.setSpout("spout", kafkaSpout, 4); builder.setBolt("Bolt_one", new Bolt_one(), 2).shuffleGrouping("spout", "myTopic"); builder.setBolt("Bolt_final", new Bolt_final(), 4).shuffleGrouping("Bolt_one"); After a certain amount of time, it stopped committing the acknowledged tuple. But in my topology, it shows all 1000 tuples are processed and acknowledged. It is reproducing only for a huge load of each tuple took 3 to 4 sec to acknowledge. "topic-partition has NO offsets ready to be committed" after the kafka consumer lag reached the MaxUncommittedOffsets. Note: Bolt_one can process the tuple in a few microseconds compare to Bolt_final. ) > KafkaSpout consumes messages but doesn't commit offsets > ------------------------------------------------------- > > Key: STORM-2994 > URL: https://issues.apache.org/jira/browse/STORM-2994 > Project: Apache Storm > Issue Type: Bug > Components: storm-kafka-client > Affects Versions: 2.0.0, 1.1.2, 1.0.6, 1.2.1 > Reporter: Rui Abreu > Assignee: Rui Abreu > Priority: Major > Labels: pull-request-available > Fix For: 2.0.0, 1.1.3, 1.0.7, 1.2.2 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > A topology that consumes from two different Kafka clusters: 0.10.1.1 and > 0.10.2.1. > Spouts consuming from 0.10.2.1 have a low lag (and regularly commit offsets) > The Spout that consumes from 0.10.1.1 exhibits either: > 1- Unknown lag > 2- Lag that increments as the Spout reads messages from Kafka > > In DEBUG, Offset manager logs: "topic-partition has NO offsets ready to be > committed", despite continuing to consume messages. > Several configuration tweaks were tried, including setting maxRetries to 1, > in case messages with a lower offset were being retried (logs didn't show it, > though) > offsetCommitPeriodMs was also lowered to no avail. > The only configuration that works is to have > ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG=true, but this is undesired since > we lose processing guarantees. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)