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 <[email protected]> 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 >
