incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Rohr <rohr.ch...@gmail.com>
Subject Re: controllers file vs. ControllerServerList call
Date Fri, 04 Oct 2013 18:15:41 GMT
Assuming this is in its own Jetty server and I use the
ZookeeperClusterStatus object, where should I get the connection info for
ZK?


On Thu, Oct 3, 2013 at 11:12 AM, Aaron McCurry <amccurry@gmail.com> wrote:

> 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