qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marnie McCormack <marnie.mccorm...@googlemail.com>
Subject Re: Java broker clustering (was: RE: want to contribute ;) )
Date Tue, 17 Mar 2009 10:14:40 GMT
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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message