Memory leak if you create too many sublevels

[mcollina]

Sublevels are never removed from the the global db.sublevels, thus if we create a lot of them (e.g. one for each user), we will leak memory.

How about a unsublevel method that removes the named sublevel?
This can be called when the users logout or similar.

[dominictarr]

sublevel#close() would be better, since it's analogous to what leveldb should do in that situation.
the most important thing here would be to remove all the hooks that have been created from this sublevel.

would merge a pull request for this feature!

[mcollina]

Regarding hooks, I think it can be done in two parts in sublevel:

1. store in an array all the hooks for each sublevel.
2. closing all nested sublevels and remove all their hooks.

However, we can add a simple new method in level-hooks: hooks.removeHooks(pattern), then specify pattern as /subname.*/. In this way a sublevel really has not to do much regarding hooks.

Which one do you prefer?

[dominictarr]

2 that is a great idea! way simpler!

You should probably just match the string prefix rather than a regexp, but, whatever does the job.

[juliangruber]

I'm for .close

[juliangruber]

you could also write a LRU kind of plugin to auto close sublevels

[dominictarr]

hmm, actually, I think that would work!

[dominictarr]

you'd just have to check if there are any streams/hooks currently open to them.

[timoxley]

Without looking at the code, I'm wondering if sublevels need to be stored on the db at all? could they instead exist only as references returned from db.sublevel(). if I want to keep it around or delete it I can manage the reference myself. Would probably still need the ability to enable/disable hooks.

[dominictarr]

@timoxley sublevels arn't stored in the database (except for the data inside the sublevel, of course)
however, there is the matter of the hooks, which I think @mcollina's approach will beat.

So, I don't have a strong need for this feature my self, but I'll be happy to merge,
and to help someone implement this, but someone needs to take the lead here.