Update LoopingResumingIterator.java

[HiremathPanchaxari]

fix for java.util.NoSuchElementException: #hasNext() returned true, but there are no more entries that haven't been iterated.

Description...

Checklist

• [ ] Documentation (if applicable)
• [ ] Changelog

[astubbs]

Hi, welcome to the project! Do you have a test case for this that exposes a problem?

[HiremathPanchaxari]

This is in reference to https://github.com/confluentinc/parallel-consumer/issues/419 which got resolved in 0.5.2.3. We are getting java.util.NoSuchElementException: #hasNext() in LoopingResumingIterator.java file

Here we are processing for messages > 40k messages per hour.

Version: 0.5.2.3

During the load test of messages > 40k per hour, the consumer closes down with following exceptions seen. So i have made attempt to fix it. Kindly review it

java.util.NoSuchElementException: #hasNext() returned true, but there are no more entries that haven't been iterated. at io.confluent.csid.utils.LoopingResumingIterator.getNextAndMaybeLoop(LoopingResumingIterator.java:151) at io.confluent.csid.utils.LoopingResumingIterator.findStartingPointAndNextValue(LoopingResumingIterator.java:102) at io.confluent.csid.utils.LoopingResumingIterator.next(LoopingResumingIterator.java:94) at io.confluent.parallelconsumer.state.ShardManager.getWorkIfAvailable(ShardManager.java:211) at io.confluent.parallelconsumer.state.WorkManager.getWorkIfAvailable(WorkManager.java:139) at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.retrieveAndDistributeNewWork(AbstractParallelEoSStreamProcessor.java:781) at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.controlLoop(AbstractParallelEoSStreamProcessor.java:704) at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.lambda$supervisorLoop$5(AbstractParallelEoSStreamProcessor.java:658) at java.base/java.util.concurrent.FutureTask.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source)

[astubbs]

Ok, cool. Do you have a test case for this that exposes a problem?

[HiremathPanchaxari]

I don't have one.

[astubbs]

I don't have one.

Could you make a unit test that exposes the issue?

[HiremathPanchaxari]

ya. sure. i can get build to verify on labs ?

[astubbs]

ya. sure. i can get build to verify on labs ?

If you mean Jenkins, yes our build servers will run the test suite.

[HiremathPanchaxari]

yes. what i will be version of it.

[astubbs]

yes. what i will be version of it.

pardon me?

[HiremathPanchaxari]

what is version of PR and how can use it my project pom for verifying the fix?

[HiremathPanchaxari]

@astubbs - I have added the test case.

[HiremathPanchaxari]

@astubbs is there any pending my side?

[astubbs]

@astubbs - I have added the test case.

@astubbs is there any pending my side?

Thanks, I'll try take a look at it asap.

[HiremathPanchaxari]

@astubbs - please let me know. I am waiting for build. thanks

[astubbs]

@astubbs - please let me know. I am waiting for build. thanks

can you give me write access to your fork? I'll push some additions to your branch

[astubbs]

Were you able to write a load test that reproduced the issue? (Can just be a load test against the iterator system)

[astubbs]

I've pushed my changes here, which should solve this issue. #200 will fix all these sorts of things though - much simpler.

https://github.com/confluentinc/astubbs/parallel-consumer branch: bugs/looper-simplify

Please take a look and see what you think of my changes.