Re: Apollo's scalability

[Hiram Chirino <ch...@gmail.com>]

Hi Connie,

On Mon, Feb 6, 2012 at 7:07 PM, Connie Yang <cy...@gmail.com> wrote:

> Hello Hiram,
>
> Scalability in a cluster is important to us and I'm trying to get a good
> understanding of it in Apollo...
>
> In this InfoQ article, http://www.infoq.com/news/2011/12/apollo-benchmarks,
> you mentioned the use of ZK to partition destinations across the cluster
> and hide the partitioning by rerouting messaging operations to the correct
> partitions in the upcoming version of Apollo.
>
>    - Is this work in flight?  If yes, when will this be available?
>
>
It complicated, but should work.  It still highly experimental but now that
the core broker has been released and is stable, I should be able to
dedicate more time to working on this problem.  Perhaps by the end of the
year we will have something folks can start trying out.


>
>    - With the ZK and re-routing approach, is forwarding necessary?
>
>
Well, if the clients are smart enough to talk to ZK to figure out which
broker they should be operating against, this would be the
most efficient option, but I'm going to assume that they are not that
smart.  Another way to look at it is, if you want your client machines to
directly talk to the right brokers, you should run a local broker on the
client box. Then that local broker would take care of figuring out which
brokers in the cluster the messages need to get routed to.  This keeps
clients nice and simple and consolidates all the message routing and ZK
integration complexity in the broker core.


> I plan to write a POC with Apollo and would like to plugin a different DB
> message store rather than using  LevelDB or BDB.  Do you have any
> documentation or sample for doing that?
>

Not yet.  It will be a still a couple of releases before the internal
broker APIs solidify to the point where we can start guaranteeing binary
compatibility for those between releases.  The best I can recommend is take
a look at the BDB store implementation.  It's the simpler one.



> Thanks,
> Connie
>
>
>

-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://fusesource.com/