incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Barton <garrett.bar...@gmail.com>
Subject Re: RPC question - Time for a change?
Date Sat, 15 Sep 2012 16:51:58 GMT
Aaron, can you go into what you see the QuerySession looking like?
At some point I remember you talking about getting off thrift, is this new
api implemented in thrift or a wrapper layer around it to allow shifting
front thrift?
On Sep 15, 2012 10:13 AM, "Andrew Avenoso" <aavenoso@nearinfinity.com>
wrote:

> 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" <amccurry@gmail.com> 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
> >
>

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