Hi Ilya, Great! Thank you for the JIRA ticket.
Kind regards, Kamil Mišúth On 2020-08-11 18:38, Ilya Kasnacheev wrote:
Hello! I think you are correct. I have filed https://issues.apache.org/jira/browse/IGNITE-13352 Regards, -- Ilya Kasnacheev вт, 11 авг. 2020 г. в 13:35, kimec.ethome.sk [1] <ki...@ethome.sk>:Greetings, we have came across a resource leak involving ScanQueryIterator instances. The code presumably causing the leak is along the following lines: ---- public List<Cache.Entry<String, Entity>> someMethod() { Iterator<Cache.Entry<String, Entity>> iter = someIgniteCache.iterator(); List<Cache.Entry<String, Entity>> entities = new ArrayList<>(); while (iter.hasNext()) { entities.add(iter.next()); } return entities; ---- I can assess from multiple heap dumps that none of the ScanQueryIterator instances gets garbage collected and all remain hard referenced from locIters HashSet of GridCacheQueryManager overseeing someIgniteCache. The iterator returned from someIgniteCache.iterator() is closable and when explicitly calling close(), the hard reference gets removed from locIters as expected, but the code above does not do that. I cannot figure out whether the underlying ScanQueryIterator should be automatically removed from locIters or not. There is also WeakQueryCloseableIterator for which weak references are handled somewhat automatically. As it stands, the above code generates millions of not collectable ScanQueryIterator instances after few weeks which we cannot get rid of by any other means than JVM restart. Is the code above breaking the contract of the iterator or is this an Ignite issue? Many thanks for any pointers. Kind regards, Kamil MišúthLinks: ------ [1] http://kimec.ethome.sk
