High Availability designs for external components


We have been working on a design for an external component that we are creating. From what we see the openfire codebase only support the “accept” pattern for external components. The XEP for external components does talk about the pattern where the openfire server “connects” to the external component (much like S2S). What that would allow for is a farm of external components to be sitting and waiting for an open fire server to connect. If the external component fails, the openfire server would simply open a new connection out to the farm and get an available component. This seems supported in Tigase and noted here: http://www.tigase.org/content/load-balancing-external-components-cluster-mode

So I had 2 question for the openfire community:

  • Has anyone thought about this already? this is something that I think we would contribute back if there is interest.
  • Do you see any pitfalls that we will encounter?

Note an alternative design woudl be to have multiple instances of the external component connected into openfire with some logic to route content to the components. this works but seems like artifically adding some level of availability.

On a related topic, has anyone needed to implment some form of component presence/health/availability that the client can subscribe to and potentially take action? We have been looking at the component providing presence or even using Pubsub, but rather keep it with the standards.



Hi Phil,

I have thought about this as well to an extent. http://community.igniterealtime.org/message/172176#172176 shows how to allow multiple as you suggest it is quite easy and it seems that you’ve alerady read this.

From what I can tell of that link to Tigase it’s pretty much the same thing. Althoug with the internal clustering that Tigase provides it seems connecting many to many is a lot easier (if not possible; compared to Openfire and maybe not possible at all)

I’ve not looked inside the specific OF code that handles components yet, though I’d start at ConnectionManagerImpl.java where the component listeners are instantiated and started. I’m not Java guru but it seems to bind a new ComponentConnectionHandler to the SocketAcceptor (which is a Mina interface that I haven’t looked at. From what I can tell it’s a threaded server socket acceptor)

It seems that the component ends up as an entry in the Local routing table, though I’m not sure how the allow multiple logic actually works… that’s for another day for me.


Thanks James, there are some helpful points there to check out. We have been still just talking about re-using some of the S2S code to initiate an outgoing connection to an external component. I will keep you posted if this is something you will need in the future.

I re read your question and I realise I didn’t really come close to addressing it.

For server to server, there is no way to explicitly make Openfire connect to another server. It has to be able to do a DNS SRV lookup for the domain of a non local JID. THen it initiates S2S over port 5279 or something similar (not got docs on hand)

You’d have to modify the code of the component listener I’d think to get that type of functionality. I’d think you’d want to keep the shared secret key or some other type to auth going as components have a lot of free reign insde the server.

This is indeed something I am looking at. I liked OF because it’s extreemly well documented and I needed to hack it internally as well as make external components, the lack of out of the box clustering will only be a problem later on down the track but it will be a problem. I’ll bookmark this discussion and add anything I find