Extend the signaling setting API to allow somewhat clustering#3292
Conversation
18d030a to
2be5e72
Compare
2be5e72 to
30fee5c
Compare
30fee5c to
d4d8cca
Compare
|
Should be functional now. We still pick a random one for the first participant, but that is hard to make right without a real usecase in hand. But adjusting that should be rather easy in the end, so testing it for now should be fine. Most effects should be noticable without the clustering. By replacing: |
|
Would be nice if you can have a quick look and spill your opinion @danxuliu |
d4d8cca to
5a7365e
Compare
5a7365e to
22c44b3
Compare
|
Added a commit to check the config.php for a hardcoded list to allow overwriting the random for some known big conversations which can then be assigned specifically to always end up on the set machines |
f73b07f to
154502c
Compare
So we can use it to decide which HPB to talk to Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Now a single signaling connection is kept open no matter how many signaling servers are available. When joining a conversation the signaling settings for that conversation are always got, as the signaling server could have changed since the last time it was joined. If the conversation uses a different signaling server than the one currently open that connection is closed and a connection to the new signaling server is started. If a different conversation is joined while waiting for joining to a previous one the previous one is cancelled and only the latest one is taken into account. All the other signaling operations (joining a call, leaving a call or leaving a conversation) are taken into account only if they act on a conversation that belongs to the current signaling server. Otherwise they are ignored. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
8c9e598 to
40fa7c6
Compare
danxuliu
left a comment
There was a problem hiding this comment.
After the last changes there are no ghost sessions and forced reconnections work. However, during a forced reconnection now the UI goes back to the chat view and then shows again the call view (the same that happened in Talk 7).
Other than that and the unit tests everything seems to work now.
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
Ran unit tests locally, they pass and random integration tests also still worked, so merging |
|
Jumping in here...Running latest version of NC and Talk (19 + 9) and Redis but i can't find a possibilty to add more than one signaling server in talk settings. Do i miss something? |
|
The HPB can handle a few hundred users by default without any bigger problems. If you need the clustering you should get in contact with our sales team for a Nextcloud Talk Enterprise Subscription: |
|
Ah, well, not really necessary, just stumbled upon this in the release notes and wanted to try to satisfy my curiosity and improve knowledge about everything ;) |
Fix #2591
Fix #3463