incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Avenoso <>
Subject Re: RPC question - Time for a change?
Date Sat, 15 Sep 2012 14:13:28 GMT
As a user of the current thrift api, I really like the idea of
simplification by having three separate apis. The majority of developers
will only ever need to use the client(controller) api.

In order to solve the one shard problem, I think having the shard able to
respond to the controller api is a great idea.
On Sep 14, 2012 9:56 AM, "Aaron McCurry" <> wrote:

> In recent weeks I have had several discussions with developers over the
> complexity of the RPC and how we need to make it easier to use.  I agree,
> but I have struggling to come up with a way to make things easier to use
> while still having all the components necessary to allow all the different
> functions to operate.
> To date the Blur shard server and the Blur controller server have shared
> the same Thrift service API, perhaps that should change.  A lot of the
> extra pieces to the API have come from this fact.  Basically the
> controllers needs to be able to pass different information to shard servers
> than the clients need to pass to the Blur controllers.
> The change that I am proposing, split the API into the 3 services.
> - User / Client API (for the controller)
> - Shard Server API
> - Admin API
> One pro to this design is that changes to the internal API (Shard Server)
> could be changed and have less of an impact to the clients if any.
> The only drawback to this approach is that the controller has to be
> deployed, even for testing.  Currently you can just deploy a single shard
> server and have the same features as a whole cluster.  We could get around
> this by allowing the controller API (and the admin API) to be run in the
> same process as the shard server so that the same small scale testing could
> occur.  This then begs the question, do we need separate controller
> processes?  Should we allow for all 3 API types to always be in every
> process?  or should we keep things the way they are?  or should we just
> allow users to configure things they way they want?
> Aaron

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