DependencyChangesRequest holds a strong reference on to its parameter org.simantics.db.ChangeSet which can pile up in QueryProcessor and consume a lot of memory
|Status:||On hold||Start date:|
|Assignee:||Antti Villberg||% Done:|
|Category:||DB client||Spent time:||-|
|Velocity based estimate||-|
- transform the diagram element a bit
When this sequence is executed at full speed without any sleep, the DB client starts piling up DepdenciesRelation.DependencyChangeRequest instances in its query cache (
readMap). The DependencyChangesRequest instances are shallowly not very large but the retained heap size is pretty much the amount of memory retained by class ClientChangesImpl, which is at least 128KB. In the mentioned test, the JVM ran into OOM, when it had around 22500 instances of DependencyChangesRequests cached resulting in a total retained heap of almost 3GB just because of these ClientChangesImpl instances.
- Make it possible to retrieve change set ID through ChangeSet interface
- Change the identity of DependencyChangesRequests from ChangeSet to ChangeSet ID
- Nullify ChangeSet parameter from DependencyChangesRequest after its execution
This will work because each DependencyChangesRequest for a certain change set will be cached for the time when each of GenericChangeListener is invoked that instantiates DependencyChangesRequest.
Of course this does not help with the fact that currently scripts can execute changes at such a rapid rate that the DB client caches will consume all JVM memory and the DB client query cache collector just does not have enough time to free up the necessary cache entries. However, this would be substantial reduction of used memory in cases where lots of requests are performed via script, which can happen also when executing model creation scripts etc.