incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
Subject Re: controllers file vs. ControllerServerList call
Date Thu, 03 Oct 2013 15:12:36 GMT
I suppose this comes down to a question of leaving the console as an
external program (like in the past) or treating it like an internal
component of Blur.  I would vote for making it an internal component.  So
with that being said if we treat it like an internal component I think that
we can trust that the console can just make use of the code in the
blur-core module.  Then the console will be treated like any other
component in Blur (controller / shard servers).

Aaron


On Wed, Oct 2, 2013 at 10:04 PM, Garrett Barton <garrett.barton@gmail.com>wrote:

> One could potentially wrap the blur zookeeper stuff
> (o.a.b.m.ZooKeeperClusterStatus) with a client read only class where the
> client cannot cause any damage.  I do that with my zk stuff and it works
> awesome. Same logic is shared for accessing the data.  I have not looked at
> o.a.b.m.ZooKeeperClusterStatus to see how easy that would be mind you.
> On Oct 2, 2013 8:14 PM, "Aaron McCurry" <amccurry@gmail.com> wrote:
>
> > The controller file is there for script startup, nothing more.  Which
> > brings me to another thought.  So if you are going to run your own http
> > server process for the console your only choice for finding out the
> > controllers maybe to access ZooKeeper.  I know this goes against what we
> > have discussed before, but I would feel better about the console
> accessing
> > ZooKeeper if it used the same classes as Blur
> > (o.a.b.m.ZooKeeperClusterStatus).  That way as we change the logic in
> > ZooKeeper you will have the same logic.  You can retrieve the controllers
> > from that class and then use the thrift api from there.
> >
> > I'm sorry for going back and forth on this, but the more I think about
> it I
> > don't see any other way.  Other than to configure the controllers in
> > somehow.  Sort of a chicken and the egg problem.
> >
> > Although I do consider the access of ZooKeeper for Blur information to be
> > private and should be protected for the most part, but I think that if
> you
> > use the same class that the controllers and shard server use it should be
> > pretty safe.
> >
> > Thoughts?
> >
> > Aaron
> >
> >
> > On Wed, Oct 2, 2013 at 7:24 PM, Chris Rohr <rohr.chris@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I have found some interesting things with the quick start and wanted to
> > see
> > > if this is going to be an issue on real instances.
> > >
> > > 1. In the conf/controllers file it lists one node of localhost (no
> port).
> > >  I tried to read that file and build the BlurClient connection string
> > which
> > > failed because there was no port.  I ended up writing code to check for
> > the
> > > absence of a port and add 40010 but that feels wrong.
> > >
> > > 2. Like I said above the controllers file lists localhost but the
> > > ControllerServerList call returns the name of my machine and a port.
> >  This
> > > causes problems for me when I am trying to figure out which nodes are
> > > offline.
> > >
> > > Thanks in advance,
> > > Chris
> > >
> >
>

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