Ah ok so answering my own question I guess. The docs say
currentBytesPerSecond and the like are how quickly the output buffer is
filled so that really has nothing to do with how many bytes are actually
making it out onto the link. Is there some other metric I could use for
Hi Chris,(1) Majority of our maintenances -- like this one tonight,
which happens about once a month, are zero-downtime maintenances. An
existing session may get an automatic reconnect, but it should be
transparent to the end user. Our goal with the Health page is to over
communicate, but you bring up a good point here as the announcement
seems more ominous than what I've described. I'll take the action to
discuss with our operations team so we are clearer on the expected
experience in the futur...
Hey Nigel - Thanks for the response. I figured it out this morning...
While I don't have any callbacks set on the audio subscriber (or
publisher), when adding the second webcam subscriber I blindly copied
over all of the callbacks for userBooted, streamChance and streamDelete
which I didn't really need on the second subscriber. The callback for
userBooted on the camera also deletes the user's audio stream via the
I updated AccountManager.keepalive to capture any errors raised by the
underlying call to do_initialize and return the value from trying to
login again if a username is supplied. Otherwise I just return
false.Should catch the case that I was seeing, but time will tell...
Have to see if happen againThanks
The data is stored only in memory only. When "persisted" we check the
node configuration and if transient we don't save that node to disk.If
you are really concerned about a security breach you should probably
encrypt your messages before sending them via LCCS (it should be easy to
subclass the current models and encrypt/decrypt the items on the fly).
I'm pretty sure they will make an announcement when they're ready. You
can follow an RSS feed of all announcements using the following
What I meant is that there is a limit on how many connections (sockets)
you can have open on a single server, and a single room cannot span to
multiple servers so in that sense you cannot have rooms with an
unlimited number of client connected. But other than that we don't
artificially limit the number of concurrent users connected to a room.