Tigase Auto scaling external components
we are evaluating the possibility to use auto scaling with Tigase.
As I understand it's easy to do with tigase-server cluster:
just add --cluster-mode = true to init.properties and in this case all nodes will use DB to sync the info about all nodes in realtime, no need to restart nodes.
But question is about external components.
Let's say we have 2 nodes of tigase-server and 2 nodes of MUC as external components.
Tigase-Server nodes have next settings in init.properties:
--comp-name-1 = ext --comp-class-1 = tigase.server.ext.ComponentProtocol --external = muc.chat.example.com:muc-secret:listen:5270:IP:ReceiverBareJidLB
MUC components have next settings in init.properties:
--comp-name-1 = muc --comp-class-1 = tigase.muc.MUCComponent --external = muc.chat.example.com:muc-secret:connect:5270:chat.example.com;chat-node-1;chat-node-2:accept
As we can see, all external components have hardcoded hostnames of tigase-server nodes: chat-node-1;chat-node-2
Is there any way to update this info in a real time without MUC rebooting?
Added by Artur Hefczyc almost 4 years ago
Actually, there are positive answers to all questions here. The whole external component logic and framework was designed with dynamic load balancing, scalability and at run-time reconfiguration in mind.
In theory (it was not extensively tested), once you have configuration on the server side applied you can connect, disconnect the external component instances at any time without a need to restart the main server. I mean, let's say you want to scale this way MUC component. Your main Tigase server is: example.com and MUC component is: muc.example.com. Then, if you have the external component configured as muc.example.com, you can connect multiple instances of external MUC with this name and Tigase should distribute load correctly. Also, when you connect a new instance it would be included in the pool automatically. However, the MUC component example is not a good one, because the code does not take care about existing rooms in case of connecting/disconnecting component instances. However, we can imagine many other external components (message archive) which would work in such setup very well.
The second question - reconfiguration without rebooting also have a positive answer. You can make the ComponentProtocol component to store it's configuration in database, where it can be updated at runtime (through admin ad-hoc commands) and there is no need to restart the server to apply changes. Again, in theory, as the feature is not commonly used and it was well tested at the time of implementation and not too much afterwards. I suggest to check it out and let us know of any problems.