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 <[email protected]>: > 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šúth >
