Tigase Auto scaling external components

Igor Khomenko
Added about 4 years ago

Hi there,

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 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

--comp-name-1 = ext
--comp-class-1 = tigase.server.ext.ComponentProtocol
--external =

MUC components have next settings in

--comp-name-1 = muc
--comp-class-1 = tigase.muc.MUCComponent
--external =;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?

Replies (4)

Added by Wojciech Kapcia TigaseTeam about 4 years ago

Currently external component configuration is not automatic and can't be updated without rebooting instance.

Added by Igor Khomenko about 4 years ago


would be great to have a feature to dinamicaly get these hostnames from db, for example from cluster_nodes table


Added by Artur Hefczyc TigaseTeam about 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.

  1. 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: and MUC component is: Then, if you have the external component configured as, 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.

  2. 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.

Added by Igor Khomenko about 4 years ago

Thanks Artur,

ComponentProtocol sounds great, will check it