search

chenejac / VIVOTestMigration

0 stars 0 forks source link

VIVO-1976: Memory leak in RDFServiceGraph.createRDFServiceModel() #1859

Closed chenejac closed 3 years ago

chenejac commented 3 years ago

Brian Lowe (Migrated from VIVO-1976) said:

Round 1: With max heap set to 768M, after a search reindex of a ~6M triple VIVO (and full GC), heap use had risen from approx. 100M at Tomcat startup to 515M.  A second search reindex slowed to a crawl as heap approached maximum and GC activity increased.  Heap dump showed bizarrely long (100K+) lists of registered listeners on RDFServiceGraphs.

Round 2: With the below section of code commented out in RDFServiceGraph.createRDFServiceModel(), repeat the above steps.

After first search reindex (and full GC), heap had grown only to 200M.

After second search reindex (and full GC), heap remained at exactly 200M.

m.register(new StatementListener() {   @Override   public void notifyEvent(Model m, Object event) {     ChangeSet changeSet = g.getRDFService().manufactureChangeSet();     changeSet.addPreChangeEvent(event);     try {     g.getRDFService().changeSetUpdate(changeSet);     } catch (RDFServiceException e) {       throw new RuntimeException(e);    }  }{{}} });

It does not seem immediately obvious what the above code is trying to accomplish.  Is it still necessary (or was it ever)?  If so, we need to make sure it doesn't keep registering new models with the same underlying graph's event manager.

 

chenejac commented 3 years ago

Benjamin Gross said:

Looks like it was added around the time of v1.5. 

[https://github.com/vivo-project/Vitro/commit/f55916b8d8ce90ada1dcb4240a917c9bcb597618]

 

Wonder if this is why I've been experiencing memory issues in v1.11+ and curious why if the code is so old why it hasn't been a problem in the past. Perhaps related to a Jena upgrade along the line?

chenejac commented 3 years ago

Brian Lowe said:

Pull request: https://github.com/vivo-project/Vitro/pull/224