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 > > > > > > > > > >
