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 00:13:51 GMT
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