smallrye-reactive-messaging icon indicating copy to clipboard operation
smallrye-reactive-messaging copied to clipboard

Suspected memory leak in KafkaThrottledLatestProcessedCommit

Open tilakchowdary opened this issue 9 months ago • 13 comments

I have observed that our heap slowly increasing with KafkaThrottledLatestProcessedCommit

Here is the heap map Screenshot 2024-05-17 at 1 54 35 PM Any inputs are greatly appreciated

tilakchowdary avatar May 17 '24 20:05 tilakchowdary

We would need to see the application. There is a poison pill mechanism that makes sure we do not accumulate too much.

So make sure your messages are acknowledged.

cescoffier avatar May 19 '24 15:05 cescoffier

Yes, probably your messages are not acknowledged properly, so not cleared from tracked messages.

ozangunalp avatar May 20 '24 08:05 ozangunalp

@cescoffier @ozangunalp Thanks for the suggestion. As I understand if it was due to messages are not being acknowledged properly it would result in TooManyMessagesWithoutAckException. However, In our case we don't see this issue and we see uninterrupted records consumption. From heap analysis only the processedOffsets field was leaking. I suspect concurrency usage of KafkaThrottledLatestProcessedCommit. Methods processed(long offset) and clearLesserSequentiallyProcessedOffsetsAndReturnLargestOffset() - Calling these concurrently by multiple threads resulting inconsistent view of processedOffsets.

tilakchowdary avatar May 21 '24 06:05 tilakchowdary

Aren't these methods getting called from event loops ?

cescoffier avatar May 21 '24 06:05 cescoffier

@cescoffier Thanks for clarification. Yes they are. Now I am not sure where is the issue. Will try to come up with a test case.

tilakchowdary avatar May 21 '24 06:05 tilakchowdary

If you've specific logs linked to this issue it can be handy. Otherwise, I don't see why this might happen.

ozangunalp avatar May 21 '24 08:05 ozangunalp

@ozangunalp maybe if concurrency > 2, so multiple event loops. But still, should not lead to a leak.

cescoffier avatar May 21 '24 16:05 cescoffier

I've thought of that, but with concurrency > 2 sub-channels have their own copy of the commit handler and their own context acting on tracked records.

ozangunalp avatar May 21 '24 16:05 ozangunalp

Yeah, that's what I just saw.

cescoffier avatar May 21 '24 17:05 cescoffier

I think issue is that with IncomingKafkaRecordBatch only latestOffsetRecords of that batch are stored in OffsetStore.receivedOffsets and subsequently removed from processedOffsets. But processedOffsets will have all Offsets not just the latestOffsetRecords.

tilakchowdary avatar May 22 '24 23:05 tilakchowdary

I'll verify batch consuming for leaks. Are you acking individual messages and not the batch as a whole?

ozangunalp avatar May 23 '24 09:05 ozangunalp

@ozangunalp Yes acking individual messages

tilakchowdary avatar May 23 '24 14:05 tilakchowdary