0.15.17

Maintenance release

Improved how “stale” rooms are cleared when using multiple processes:

The Problem

On previous versions, whenever a new process starts up, all existing rooms would be "health-checked", and removed in cause of failure - one by one. Depending on the number of rooms available, this could cause stress on Redis, and end up clearing rooms that shouldn't be cleared.

The Solution

Now, rather than "health-checking" all the rooms, each process is "health-checked" instead. Then, in case of failure, rooms are cleared from the cache in batches, instead of one-by-one.

Also, now whenever a user tries to “join or create” and a “stale” room is found, the remote process is immediately health-checked and the “join or create” is re-tried. When this happens, the request will take more time to complete, but it won’t result in an error to join. (previously, the {roomId} is already full error used to appear in such scenario!)

Internal changes

• Setting the autoDipose property will now reset the auto-dispose timeout. d3ff4a5
• Fixed global stats counter during room.disconnect() and early “leaves” (#719)
• room.disconnect() returns a resolved promise if room is already disposing
• presence.hdel() now returns a boolean if successful or not
• Added driver.cleanup(processId) method to remove cached rooms by processId
• devMode bug fix: prevent roomHistory.clients is not iterable error