Multiple Jicofo Same Jibri


In current arhitecture Jibri’s register to Jicofo through prosody. In a multiple shard configuration (different prosody, different jicofo, diffrent JVB ) same Jibris register to multiple prosodies. Each jicofo caches available jibri. When a conference needs a recording, Jicofo chooes one available jibri through its own cache. But same jibri may have been already chosen by another shard. In that case jibri returns busy. Jicofo tries to find another Jibri for 5 times. (This is configurative, I know) But because of same jibris are chosen by different shards and we try like 5 times, although there is an available jibri, jicofo can not find an available jibri. And Recording can not be started.
So, how would it be a central module to chose available Jibri? All jicofo’s ask to central module to find the available Jibri. I believe, it would be more faster and errorless solution.
What is your opinion?


Does each Jibri have a unique nickname? Jibri status is polled before selection; if the status returns “busy”, then it’s not selected. If your shard is using the same pool of Jibris, there shouldn’t be any conflict - if a jibri instance is busy, it doesn’t get selected (jibris are not tied to ‘cache’).

I mis-spelled maybe. On JibriDetector.selectJibri method, one of the available Jibri’s are selected. And a startIQ is sent to Jibri to start the recording. But, same Jibri may have been selected by another shard, and Jibri may not be published a BUSY state yet. So Jibri returns I am BUSY to the second conference. When Jicofo gets busy event, it goes and selects another available jibri. This retry is done for max 5 times.

By the way, we try to connect 500 Jibri instance with 4 different shards. We try to run a traffic test. Under heavy traffic, 4 shards are choosing same Jibri over and over again. And Jicofos gets busy for 5 times, and records don’t start.

I believe choosing available jibri from a central place would be a good effect.

Maybe “selecting a random one from available Jibris instead of the oldest one” suits better for some cases.

IMO implementing a central place makes things more complicated.

But in a heavy traffic it still gets chance to select same jibri from different shards.

Why don’t you use auto-scaling Jibri pool for each shard?

Can you explain it more? How is auto-scaling works?

It depends on your deployment environment but the main idea is the same. There are always N free Jibri instances for each shard. When the number of free instances is less than this limit then something (depends on your env) will start new instances and when the number of free instances is more than some limit, some instances will be shutdown.

Are you suggesting to split Jibri’s to different shards? Try to observe free Jibri instance count on each shard and start or stop new instances for a specific shard?

Yes, each Jibri will only connect to one shard, not multiple shards…

Yes and this number should not be static. You can update this count according to some criterias (e.g. day of week, hour or shard)

Yes but not manually. For example by using some scripts which handle this through your deployment environment’s API, etc.