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/17 10:19:43 UTC
Java broker clustering (was: RE: want to contribute ;) )
Hello,
having a mixed java - C++ implementation leads to the following
(abridged version):
pros:
- ease of maintenance;
- compactness and organic architecture of the project,
cons:
- less portability;
- building complexity and distribution;
However these choices can be postponed to the design stage as for now we
need to define basic clustering requirements.
As food for thought, I'd suggest:
- clustering for dependability: pretty obvious;
- clustering and performance: which trade-offs ?
- clustering adaptability: at which level ?
- adaptability policies: none / some / mid - smart / "zero policy
(a.k.a ad hoc control theory)" / autonomic ?
Can we start a whiteboard discussion on this ?
Cheers,
Etienne
On Wed, Mar 11, 2009 at 2:55 PM, 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
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Java broker clustering (was: RE: want to contribute ;) )
Posted by Carl Trieloff <cc...@redhat.com>.
>
> I'm quite new to this list, how can we set up an open discussion ?
> Just the list ? Jira ? What else ?
list or JIRA is fine for discussion
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Java broker clustering (was: RE: want to contribute ;) )
Posted by Etienne Antoniutti Di Muro <et...@adaptivebytes.com>.
Hi Marnie,
you've got everything, perfectly!
I was just trying to sum up, previous discussions:
The idea of "borrowing" some existing components, i.e. the virtual
sync implementation,
from the C++ clustering has been suggested, in order to keep a compact
codebase and
minimize maintenance.
However we are fully in sync that having a mixed java and C++ implementation
might be a big PRO from an architectural point of view,
but is a big CON for a working approach
Plus you are right, cluster set up is a mayhem that exponentially
grows with the cluster dimension,
so this would raise deployment issues to the N power.
I see your point about HA,
but from a theoretical point of view HA without RELIABILITY is quite pointless,
moreover you can have BOTH with not much extra spending.
Depending on the proper configuration of the cluster,
scalability and throughput can be maximized, with respect to the
available cluster nodes,
at the same time ensuring reliability "inherited" from the virtual
synchrony paradigm.
The trade off is the need to setup a number of configuration parameters that can
become a cumbersome activity, unless some adaptation policy is defined to
help with static initialization and dynamic run time system adjustments.
I'm quite new to this list, how can we set up an open discussion ?
Just the list ? Jira ? What else ?
Regards,
Etienne
On Tue, Mar 17, 2009 at 11:14 AM, Marnie McCormack
<ma...@googlemail.com> wrote:
> Hi Etienne,
>
> I'm not sure I entirely understand what you're proposing, so apologies if I
> have misunderstood ....
>
> On Tue, Mar 17, 2009 at 9:19 AM, Etienne Antoniutti Di Muro <
> etienne.antoniutti@adaptivebytes.com> wrote:
>
>> Hello,
>>
>> having a mixed java - C++ implementation leads to the following
>> (abridged version):
>
>
> So, you do really mean an implementation using both languages that could be
> used for clustering Java Brokers ?
>
>>
>> pros:
>> - ease of maintenance;
>> - compactness and organic architecture of the project,
>>
>> cons:
>> - less portability;
>> - building complexity and distribution
>
> This would be an important 'con' for our user community. Portability is
> pretty key, and some of the Java Broker deployments go out on a host of
> platforms at the moment (across 10s of machines). The need to produce a
> build for each would be a significant stumbling block for uptake imho.
>
>>
>>
>> However these choices can be postponed to the design stage as for now we
>> need to define basic clustering requirements.
>>
>> As food for thought, I'd suggest:
>>
>> - clustering for dependability: pretty obvious;
>> - clustering and performance: which trade-offs ?
>> - clustering adaptability: at which level ?
>> - adaptability policies: none / some / mid - smart / "zero policy
>> (a.k.a ad hoc control theory)" / autonomic ?
>>
> Most of the traffic I get about clustering is really for HA, avoiding the
> need to start up a secondary broker and point it at the original persistent
> store. Our users want to avoid downtime. The Java Broker is pretty amenable
> to having several instances running to help with scalability, and throughput
> for transient mesasging is pretty good.
>
>>
>> Can we start a whiteboard discussion on this ?
>
> Definitely a good idea.
>
>>
>> Cheers,
>> Etienne
>>
> Regards,
> Marnie
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Java broker clustering (was: RE: want to contribute ;) )
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Etienne,
I'm not sure I entirely understand what you're proposing, so apologies if I
have misunderstood ....
On Tue, Mar 17, 2009 at 9:19 AM, Etienne Antoniutti Di Muro <
etienne.antoniutti@adaptivebytes.com> wrote:
> Hello,
>
> having a mixed java - C++ implementation leads to the following
> (abridged version):
So, you do really mean an implementation using both languages that could be
used for clustering Java Brokers ?
>
> pros:
> - ease of maintenance;
> - compactness and organic architecture of the project,
>
> cons:
> - less portability;
> - building complexity and distribution
This would be an important 'con' for our user community. Portability is
pretty key, and some of the Java Broker deployments go out on a host of
platforms at the moment (across 10s of machines). The need to produce a
build for each would be a significant stumbling block for uptake imho.
>
>
> However these choices can be postponed to the design stage as for now we
> need to define basic clustering requirements.
>
> As food for thought, I'd suggest:
>
> - clustering for dependability: pretty obvious;
> - clustering and performance: which trade-offs ?
> - clustering adaptability: at which level ?
> - adaptability policies: none / some / mid - smart / "zero policy
> (a.k.a ad hoc control theory)" / autonomic ?
>
Most of the traffic I get about clustering is really for HA, avoiding the
need to start up a secondary broker and point it at the original persistent
store. Our users want to avoid downtime. The Java Broker is pretty amenable
to having several instances running to help with scalability, and throughput
for transient mesasging is pretty good.
>
> Can we start a whiteboard discussion on this ?
Definitely a good idea.
>
> Cheers,
> Etienne
>
Regards,
Marnie