Gaston, I would be interested in getting some more detailed information about the clustering you’ve built into Openfire. Did you use your own clustering framework, or did you use an existing framework like Terracotta?
Building our clustering framework from scratch would have been a Pharaonic task. We instead decided to go with Coherence from Tangosol (now part of Oracle). As I said in the clustering podcast, having a clustering framework was just the beginning since a huge amount of refactoring work was still required.
What about the gateways to other IM services? We’re currently running gateway instances together with ejabberd nodes on all of our servers, but we’re thinking about setting up dedicated gateway nodes to separate the gateways from core ejabberd. Would this also be a configuration scenario with Openfire Enterprise?
Gateways are just like any other plugin for Openfire. Plugins may provide zero, one or many XMPP services. Plugins may be installed in one, many or all cluster nodes. When you install the plugin in all cluster nodes then the services provided by the plugin will be available in all cluster nodes. However, if you install the plugin in some cluster nodes then even though the service will be available for all cluster nodes those nodes that are not actually hosting the service will need to forward requests to the closest cluster node hosting the service. So lets say that you have a cluster of 10 nodes and the plugin is installed in only 2. End users connected to any cluster node will be able to use the service. However, users that are not connected to cluster nodes hosting the actual service will need to forward their traffic to the closest cluster node hosting the service.
In the case of gateways I think that it makes sense to have the gateway plugin installed in all cluster nodes. That is the perfect way to reduce the load on each cluster node since each local user will use the local gateway service thus distributing the load across the cluster. Even if you prefer to move the gateway service to a service grid I think that that could not be most efficient way of taking advantage of the hardware. Let me give you an example to illustrate what I’m saying.
Let’s say that you have 10 machines available. You use 5 machines to run the XMPP server and then 5 machines to run the gateway plugin. Now let’s assume that your 1M users use a lot the gateway service. In this architecture you end up with 5 XMPP servers doing a lot of remote calls to the service grid that has only 5 machines to attend the requests of your users. On the other hand, if you are using the 10 machines to host the XMPP server and the gateway plugin then you are avoiding lots of remote calls (i.e. traffic and finally throughput) and you now also have 10 machines doing gateway work. Moreover, afaik some legacy networks (ie. AOL, MSN, etc.) place a limit in the number of connections that a single IP address may generate. Having more cluster nodes hosting the gateway service is another way of avoiding that limitation.
Next question: How do you handle database connectivity? Are you using database clustering middleware like e.g. C-JDBC?
We handle DB connectivity just like you handle it with any application server. So lets say that in a standard web application you have 3 layers (front layer that is browsers, middle layer that is application server like Websphere, and the last layer that is the DB). You can then enable clustering in the DB layer and not in the application layer if your bottleneck is the DB. Or you can enable clustering in the application server layer and not in the DB (because your DB does not support it or it is too expensive for your project) but you are still offering a better experience to the end users in case an application server goes down. Or you can go with the whole package and enable clustering in the application server layer and the DB layer.
Having said all that, Openfire does not care if your DB is a single machine or if there is a cluster of machines. If your DB does not have native support for clustering you can then use C-JDBC with Openfire.