>> There are also other implementations of Group Communication
>> Toolkits, and Spread is not the best one, only that is the only one
>> that I know that is written in C/C++. I would wonder if it were
>> possible to compile JGroups with gcj to a lib file, as Lucene
>> people did to their engine.
>
> Would you have time for a quick compare&contrast of JGroups, Spread
> and Ensemble?

I'll try... I just checked the current docs of Spread, looks like things
have significantly changed since I have looked at them before. From the
first look it looks feature-wise similar to JGroups.

- I have almost nothing to say about Ensemble. However, Ensemble is
successor of Horus, a GCT developed at Cornell, where Bela Ban did his
Post-Doc. See http://www.cs.cornell.edu/Info/Projects/HORUS/People.html.
So I suspect that conceptually JGroups and Ensemble have a lot of in common.

- The Spread and JGroups are based on the concept of virtual synchrony
and have similar properties. Both can deliver messages reliably and
unreliably, the message ordering can be FIFO, Causal and Total Order.
Spread has also "safe" message delivery, need to check whether JGroups
has something similar. The Spread API offers very "spartan" API compared
to JGroups, but one should be able to add those building blocks on top.

- Spread uses point-to-point TCP connections and, optionally,
IP-multicast. JGroups can use IP-multicast as well as point-to-point TCP
connections.

- The performance numbers of JGroups and Spread look similar for TCP
(about 80% of theoretical network capacity). The UDP in JGroups 2.4.x
performed worser compared to TCP, but they were expecting better
performance with 2.6 for UDP with new algorithm that will deal with UDP
packet dropping on the switches.

So, with some quick reading, looks like Spread is a real option. That
was not so few years ago.

And to make final choice one has to set up own cluster and do the
testing. There are different issues that arise in GC (e.g. false
suspections under the load, group splitting/merge which leads to
split-brain syndrome and so on).

> Am I missing popular choices with the above three?

- Apache Tribes should be checked. The code is used for Tomcat session
clustering, on the API level similar to JGroups (Filip Hanik, former
JGroups developer), the network protocol stack is simpler.

- The Appia project, as an attempt to replace JGroups. However I have no
information about them.

- Terracotta is a competitor for JBoss Cache (now belongs to Spring
Source). The protocol stack is somewhat more complex, but from the first
look I cannot say a lot about it.

Roman