[ 
https://issues.apache.org/jira/browse/KAFKA-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881721#comment-17881721
 ] 

Matthias J. Sax commented on KAFKA-17499:
-----------------------------------------

Thanks for the follow up. Two comments:
 * There should also be a memory leak in 3.7 if you don't close the iterator – 
I am not sure right now, why you only see it in 3.8 – closing iterators is (and 
always was) the user's responsibility; thus, I don't think there is any 
regression bug in 3.8
 * Why do you think the commit you linked would be the root cause of the change 
in behavior? Looking into the commit, I could not spot any remove `close()` 
calls or newly added try-with-resource statement that would have close an 
iterator in 3.7

Not sure what the next step for this ticket should be? I tend to say, we should 
close it as "not a problem", but I am also confused (there might actually be a 
bug in 3.7 for which KS incorrectly closes an iterator...) and curious about 
the details.

> Memory leak when using ReadOnlyKeyValueStore `all()` method
> -----------------------------------------------------------
>
>                 Key: KAFKA-17499
>                 URL: https://issues.apache.org/jira/browse/KAFKA-17499
>             Project: Kafka
>          Issue Type: Bug
>          Components: streams
>    Affects Versions: 3.8.0
>            Reporter: James Cook
>            Assignee: Bill Bejeck
>            Priority: Major
>         Attachments: Screenshot 2024-09-09 at 08.31.57.png, Screenshot 
> 2024-09-09 at 08.32.16.png, Screenshot 2024-09-09 at 08.32.25.png, Screenshot 
> 2024-09-09 at 08.35.07.png
>
>
> There is a memory leak when using the `.all()` method of 
> ReadOnlyKeyValueStore (specifically MeteredTimestampedKeyValueStore).
> I have recreated the problem in a small app here: 
> [https://github.com/jamescookie/kafka-stream-memory-leak]
> When I run the test method using 3.8.0, I get this memory footprint:
> !Screenshot 2024-09-09 at 08.31.57.png!
> In a little over 90 seconds the number of `java.util.TreeMap$Entry` grows to 
> over 10 million:
> !Screenshot 2024-09-09 at 08.32.16.png!
> !Screenshot 2024-09-09 at 08.32.25.png!
>  
> When running against 3.7.1, this does not happen:
> !Screenshot 2024-09-09 at 08.35.07.png!
>  
> The workaround (and correct way of coding) is to wrap a try-with-resources 
> statement around the `store.all()`.
> I think this has been caused by this 
> [commit|https://github.com/apache/kafka/pull/15219/files] to fix KAFKA-15770
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to