Carl Trieloff wrote:
Etienne Antoniutti Di Muro wrote:
Having said so, some starter ideas about clustering, as follow:
if the C++ broker comes with a pretty complete clustering solution,
the idea of "borrowing" something
from there could be useful....otherwise should we implement from
scratch a NEW virtual synchrony solution ?! (I like virtual synchrony,
Alan ;) ) -- I would not underestimate the burden of such an
implementation.
I would say that the first step is to investigate existing open-source virtual
synchrony implementations Java and adopting one of those. With that in place,
Java could adopt a similar design to the C++ broker. That kind of scrutiny would
also be very healthy for the C++ broker, there's always room for improvement.
I don't think that writing a virtual synchrony implementation from scratch is
the right way to go.
I'd be strong there any existing open-source virtual synchrony solutions for
Java? I'd be
That is a good idea, two things to look into is if we can put a Java API
onto AIS, or at the Cluster.so
level. Understanding these two options might be good even if they don't
work out as they will give
you insight into how the C++ clustering works
That's also worth looking into. If we put a JNI interface over openais and/or
some subset of the existing cluster.so we could in principal support mixed
java/C++ clusters. Note however that IMO that is _not_ a very likely deployment
scenario, and JNI tends to be annoying at best and a show-stopper at worst for
many/most Java developers and users, so I think a native Java EVS protocol is
also worth considering. It actually might not be that hard to allow a choice of
EVS implementations depending on requirements.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
