I’ve been able to dynamically add and remove connections from a videobridge to multiple shards using REST calls to
/colibri/muc-client/*, but I’m yet to work out how to list existing connections. Is this possible?
Background: I’m dynamically adding JVBs to shards as they spin up based on service discovery, and then remove connections if a JMS instance fail and no longer discoverable. This would be a lot more reliable if we can compare discovered services against configured/connected servers before taking action.
I did a bit of uneducated nosing around and stumbled on
MucClientManager in jicoco appears to be behind the
/remove REST apis for
/colibri/muc-client, as well as the “mucs_configured” and “mucs_joined” stats.
And indeed, there doesn’t seem to be a public method for listing out the muc clients held by the manager.
@damencho @bbaldino : any chance you would consider a PR to add
listMucClients method to MucClientManager in jicoco and then exposing this as a REST API on
/colibri/muc-client in videobridge?
Or am I going about this all wrong?
@damencho @bbaldino : to offer something more concrete, here’s an initial attempt.
A small method added to MucClientManager in jicoco:
And exposing it in as
/colibri/muc-client/ids in jvb:
Would you consider a PR for these changes?
I’ve tested this in my deployment and it appears to work.
Out of curiosity, what’s the use case? It’s not showing whether or not the MUC actually connected successfully here, right? Basically just which MUC IDs were configured? (Or maybe only successfully connected MUCs make it into that list–I don’t remember)
I’m building out the ability for JVBs to dynamically register signalling nodes as they come online and drop ones that have become unhealthy or scaled down. Service discovery gives me ids and IPs of healthy nodes, so my hope is that I can simply periodically diff this vs what’s already added to the videobridge then add/remove accordingly.
Without an API to list the registered IDs, I’d need to maintain that state separately which could get out of sync in various circumstances. Having the API makes this a lot simpler to implement and a lot more reliable.
Indeed. All configured or added MUC IDs will be returned. I was initially aiming for connection status too, but that was beyond my current knowledge of the codebase, so I went for a quick win instead
In fact, it probably would suffice since I only reallu want to drop the configs if the signalling node is unhealthy. If the connection failure was due to other circumstances, it might be better to leave it configure since I’ll then get logs of the failures and they should reconnect if the issue was temporary.
@bbaldino Any thoughts on whether this is something you’d happy to take a PR for?
To recap, we are looking for a quick and reliably way to list MUC client ids already registered in JVB. This is to allow periodic reconciliation against list of known JMS instances (derived from service discovery) so we can add/remove accordingly as instances get replaced or scaled out.
We don’t actually need to know if MUC client connection was successful and just need to expose ids from the MucClientManager, so the change should be low risk.
The approach seems reasonable to me (I’d suggest to use
/list for consistency with
/remove). I think we can accept it as a PR.
Fantastic! I will make the necessary changes and submit a PR shortly. Thanks.