If it's being run from within the normal Blur environment, BlurConfiguration. This will read from the blur-site.properties file and give you the ZK connection that is configured.
Property name: blur.zookeeper.connection Aaron On Fri, Oct 4, 2013 at 2:15 PM, Chris Rohr <[email protected]> wrote: > 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 <[email protected]> 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 < > [email protected] > > >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" <[email protected]> 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 <[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 > > > > > > > > > > > > > > >
