qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Etienne Antoniutti Di Muro <etienne.antoniu...@adaptivebytes.com>
Subject Re: Java broker clustering (was: RE: want to contribute ;) )
Date Tue, 17 Mar 2009 13:34:05 GMT
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 ?


On Tue, Mar 17, 2009 at 11:14 AM, Marnie McCormack
<marnie.mccormack@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

View raw message