You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Etienne Antoniutti Di Muro <et...@adaptivebytes.com> on 2009/03/10 16:23:07 UTC
Re: want to contribute ;)
Hi everybody,
sorry for delay, but as I am switching jobs, I can enjoy some much
needed free time.
I just took 2 weeks off, and I'll be on vacation again on Easter break :D:D
Thank you all, for the welcome!
Having read all the discussion, I have to say that I'd rather build my karma
starting with the clustering requirements analysis and discussion (I
know I'll be much more comfortable there),
and meanwhile getting acquainted with the codebase.
I do not really think a deep understanding of the current broker code
is really necessary at first.
Moreover I see the clustering thing as an independent aspect with
respect to the broker,
so there's no need for me to jump into the coding stuff right away.
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.
However this depends on the modularity of the existing C++ clustering
and the freedom we have to organically integrate
with it.I am in sync with Aidan on this topic.
So should we arrange the white board for discussion, then ? With JIRA ?
http://cwiki.apache.org/qpid/clusteringha.html can be our starting point.
Dave, is *REALLY* good to hear from you!! The Arjuna alumni thing is
fun, who is missing so far?
Arnaud.....well, thanks!
Cheers!
Etienne
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: want to contribute ;)
Posted by Rajith Attapattu <ra...@gmail.com>.
The guy who wrote this was active on Qpid list a while ago and was
interested in helping us out.
Once we start clustering for the java side, it would be worth to ping
him if we want to use evs4j.
Rajith
On Wed, Mar 11, 2009 at 9:55 AM, Gordon Sim <gs...@redhat.com> wrote:
> Alan Conway wrote:
>>
>> 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?
>
> "EVS4J is a pure-Java(tm) implementation of the Totem single ring protocol"
>
> http://code.google.com/p/evs4j/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: want to contribute ;)
Posted by Gordon Sim <gs...@redhat.com>.
Alan Conway wrote:
> 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?
"EVS4J is a pure-Java(tm) implementation of the Totem single ring protocol"
http://code.google.com/p/evs4j/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: want to contribute ;)
Posted by Manuel Teira Paz <mt...@tid.es>.
Alan Conway escribió:
> 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.
>
I completely agree. I've used deployments with JNI parts (native JDBC
drivers) and one of the problems we run into was memory management:
Since the memory allocation of the native part shortcuts the java
garbage collector, it is easy to run into unexpected situations, and
even the JVM going out of memory.
Just my two cents on it.
--
Manuel
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: want to contribute ;)
Posted by Alan Conway <ac...@redhat.com>.
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:dev-subscribe@qpid.apache.org
Re: want to contribute ;)
Posted by Carl Trieloff <cc...@redhat.com>.
Etienne Antoniutti Di Muro wrote:
> Hi everybody,
> sorry for delay, but as I am switching jobs, I can enjoy some much
> needed free time.
> I just took 2 weeks off, and I'll be on vacation again on Easter break :D:D
>
> Thank you all, for the welcome!
>
> Having read all the discussion, I have to say that I'd rather build my karma
> starting with the clustering requirements analysis and discussion (I
> know I'll be much more comfortable there),
> and meanwhile getting acquainted with the codebase.
> I do not really think a deep understanding of the current broker code
> is really necessary at first.
> Moreover I see the clustering thing as an independent aspect with
> respect to the broker,
> so there's no need for me to jump into the coding stuff right away.
>
> 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.
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
my 2 cents,
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org