Serious memory leak in Resource in node.js and other environments caused by RequestScheduler.activeRequests

[bkuster]

The Issue

When using sampleTerrainMostDetailed often (thousands of times), the memory usage slowly rises.

Inspections

In node this leads to a large external memory usage over time. We managed to replicate the problem in the browser (see this sandcastle gist). This leads to the following profile over 90 seconds:

For some reason, the listeners keep on rising, we are currently trying to get to the bottom of this and would welcome any input.

[jbo023]

Hi,
we have done some further investigation:

The Problem seems to be the new Ressource Class, we changed the CesiumTerrainProvider to use fetch instead of the Ressource class, and the Problem seems to be gone, for sampleTerrainMostDetailed.
See : virtualcitySYSTEMS@293cdde

[shunter]

Your sample code never runs the render loop, which means that RequestScheduler.update() is never called, which is the function that cleans up activeRequests.

[jbo023]

@shunter Thanks, when i add RequestScheduler.update() after each sampleTerrain call the memory footprint keeps stable. Maybe this could be documented for methods which can be used without the render loop?

[bkuster]

Could there be a way for the RequestScheduler to auto update in node environments? Running cesium headless and having the need to clean up after it manually seems unintuitive.

[mramato]

I somehow missed this issue the first time around but @kring just ran into it.

Couldn't we just have RequestSchedule run update on itself no more than once a frame? Rather than installing a constant even into the event loop, we could have it use process.nextTick and only install the one time handler after a request has resolved.

I may not be explaining it well, but I think this is an easy fix.