Hi Tielman The result sets are supposed to properly close when you do close(), if it's not the case, it could be related to some internals (eg. subqueries). Do you have a test case to reproduce the problem?
Thanks Luigi 2018-01-05 22:30 GMT+01:00 Tielman Van Vleck <[email protected]>: > Am I doing something wrong or is it possible OResultSets in 3.0RC1 aren't > always released when you call .close()? I believe I am calling it on every > result set created, yet am still blowing up: > > 2018-01-05 14:48:59:848 WARNI {db=phenlp_rels} This database instance has > 10 open command/query result sets, please make sure you close them with > OResultSet.close() > > 2018-01-05 14:48:59:866 WARNI {db=phenlp_rels} This database instance has > 20 open command/query result sets, please make sure you close them with > OResultSet.close() > > 2018-01-05 14:48:59:882 WARNI {db=phenlp_rels} This database instance has > 30 open command/query result sets, please make sure you close them with > OResultSet.close() > > ... > > 2018-01-05 15:20:29:195 WARNI {db=phenlp_rels} This database instance has > 10410 open command/query result sets, please make sure you close them with > OResultSet.close() > > 2018-01-05 15:20:29:195 WARNI {db=phenlp_rels} This database instance has > 10410 open command/query result sets, please make sure you close them with > OResultSet.close() > > 2018-01-05 15:20:32:591 WARNI {db=phenlp_rels} This database instance has > 10410 open command/query result sets, please make sure you close them with > OResultSet.close()java.lang.OutOfMemoryError: GC overhead limit exceeded > > Dumping heap to java_pid21078.hprof ... > > Heap dump file created [3026507582 <(302)%20650-7582> bytes in 16.011 > secs] > > Exception in thread 'OrientDB WAL Flush Task (phenlp_rels)' > > java.lang.OutOfMemoryError: GC overhead limit exceeded > > at com.orientechnologies.orient.core.storage.impl.local. > paginated.wal.OLogSegmentV2.preparePageForFlush(OLogSegmentV2.java:275) > > at com.orientechnologies.orient.core.storage.impl.local. > paginated.wal.OLogSegmentV2.access$500(OLogSegmentV2.java:30) > > at com.orientechnologies.orient.core.storage.impl.local. > paginated.wal.OLogSegmentV2$WriteTask.run(OLogSegmentV2.java:160) > > at com.orientechnologies.common.concur.executors.SubExecutorService$ > RunnableTask.run(SubExecutorService.java:296) > > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > > at java.util.concurrent.ScheduledThreadPoolExecutor$ > ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > > at java.util.concurrent.ScheduledThreadPoolExecutor$ > ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > > at java.util.concurrent.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1149) > > at java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:624) > > at java.lang.Thread.run(Thread.java:748) > > I assumed I was missing one, but in the debugger, it appears they still > persist even after calling .close() - of course that could be just what is > in my client vs. on the server. > > Many thanks, > Tielman > > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
