I want use Openfire in large scale, with hazelcast plugin since it has a side effect on other nodes so can’t response to any count of users, I think if migrate it from mono architecture to the microservice architecture scalability problem solved. Thanks to anyone who has any advice for this migration.
I’m not exactly sure what you’re asking for here. Are you suggesting to think of an entirely new/different way to be able to horizontally scale Openfire, only because an API that should return a user count is not behaving as expected? Maybe it’s worth trying to fix that, instead of radically changing things? What is the specific challenge that you’re facing?
thanks, Guus for your response
In Openfire servers, on some server maybe MUC service the main process, and on another node maybe user direct messaging the main process and MUS service need NoSQL for message archiving and … so I think microservice architecture can solve.
I believe that you’re right that MUC, when ran in a cluster, depends on a single node performing most of the orchestration. For most all other functionalities, cluster nodes can each perform a significant amount of work. Where that’s not the case, we can always see if we can improve things.
I’m not sure where your reference to NoSQL originates. Openfire does currently not support any NoSQL-based backend.
A redesign of the architecture will have a significant cost. Not only will it take (a lot of?) effort to implement, we’ll also need to worry about compatibility with third-party code, think about upgrade paths, and so on.
If we can improve things, we should definitely try, but at this stage, your suggestion of having a microservice architecture seems more of a goal in itself. If that’s the case, then I think we should careful consider if we want to move this way: changes for changes sake are often ill-advised.
Without a detailed description of exactly why we should do this, what the architecture should look like, how we can minimize the impact of the change for existing third-party developers, and what the expected effort involved is, I am skeptical of the feasibility of this idea.
Guus, You’re absolutely right, move architecture to microservice has a lot of implementation but how can solve MUC problem for groups with thousands of users. when one of this group run in a node of a server, this node be very slow and this slowed node impact to the cluster performance.
There are a lot of steps between where we are now, and concluding that changing Openfire to conform to a microservice-architecture is a good idea.
We should start by defining the actual problem that we’re trying to solve, what characteristics are observed in the existing code, and what the the desired behavior is. We can then start to evaluate what changes could realise the desired behavior. For each of the identified changes, we should evaluate what the associated costs are, and, finally, if we thing that those costs outweigh the benefits. Only then can we select the best solution to the problem.
The steps you mentioned are logical and I am looking forward to the results, even in theory.
thanks a lot
To be clear: I will not work on this, as I think it will prove to not be worth the effort. If you feel otherwise, I invite you to lay out your plans and motivation.
Openfire copy session on each node, this reduces scalibility and causes a lot of performance issues.
Migrate to microservice architecture can solve these issues.
1 Like
I quite agree
This causes each node to have memory overhead on the other nodes. Openfire with one node works very better than cluster mode.