Running multiple shards is not a feasible solution to us. What I want is a “cluster” like Jicofo. I would like run this idea by the community. Currently Jicofo is implemented as a component, so no more than one instance can be run against an XMPP server. We are thinking to use Hazelcast to form a cluster group. All instances of Jicofo connecting to one XMPP will share data among themselves using Hazelcast, but only the “senior” member in the cluster group will have its component started. If this senior member instance dies, Hazelcast will promote a next instance in the cluster group to a senior member. The new senior member then will have its component started. I understand that the code may not be structured in a way that we can separates the component start easily. But, will this approach work? If this approach is reasonable, how should I proceed? Any comments are welcome.
Another idea is not to use component at all; just to have the “focus” user logs in each Jicofo instance with different resource part in the JID (i.e. firstname.lastname@example.org/some-uuid) All IQ’s to Jicofo address to the bare JID of “focus” user (to="email@example.com"). This way, all “focus” sessions get the request, but only the senior member (maybe using a MUC to determine it) of Jicofo will handle the IQ request. All other “focus” sessions are dormant until one becomes a senior member. This approach uses XMPP routing capability in the cluster mode; however, it requires changes to the current architecture. If it is a viable approach, it probably will be a longer term goal.
Please bear with my naive ideas.