I had noticed that the memory usage reported by Union Admin
was on a steady upward path, occasionally falling back when
a garbage collect happened, but to higher levels than earlier.
In other words, it was a sawtooth graph like this:
15 20 25 ... 18 23 28 ... 21 26 31 ... and so on.
After a few days, it would have climbed into the 50's, 60's and higher.
I'm not sure how high it could get, because for various other reasons,
there would be periodic restarts, starting the process over.
After some experiments, I concluded that letting rooms DIE ON EMPTY,
and then re-creating them was the cause of the problem, and after changing
my app so that I leave empty rooms around and re-use them, it appears
that the memory usage remains more or less steady, topping out so far
(after just a few days) around 30-35 MB, then falling below 20 again sometimes.
The question then is: which side of the API does the leak lie on?
i.e. Is my code written incorrectly, or is the leak inside Union?
Here is what I do to create a new room:
Create a roomdef:
var roomDef = new RoomDef();
Set up about 8 attributes like this (each using a new AttributeDef):
var attr = new AttributeDef();
attr.setName(nm);
attr.setValue(val);
attr.setFlags(Attribute.FLAG_SHARED | Attribute.FLAG_SERVER_ONLY);
roomDef.addAttribute(attr);
var md = new ModuleDef(); (again a new one each time)
md.setType(ModuleDef.SCRIPT);
md.setSource("blah.js"); // same thing every time too
roomDef.addModule(md);
server.createRoom(roomDef);
This might occur dozens of times per day, amounting to hundreds in a few days.
When I reduced those hundreds to under a dozen (total), the perpetual increases
in memory use stopped. Just now, with the instance running for 3d 20h,
and having had 1200 client connections, and probably (but no longer known exactly)
400-500 room re-uses, the memory reported was just 18 MB, not much more than
when the server is first started.