On Sun, Apr 6, 2014 at 12:45 PM, Chris Rohr <[email protected]> wrote:
> Currently I have been setting up the Blur console to run along side > controllers, where it would run in its own process but would utilize the > blur config file to get the connection to zookeeper and then determine > controllers to connect to from there. > > After some more thinking and from experience of use with the previous > version, I'm rethinking this approach slightly and wanted some opinions. > With the way I had started to implement, this would mean the console would > access blur through all of the controllers (utilizing the round-robin > nature of the blur client). This has some implications on performance, > where the console itself could bring down all of the controllers. > > On a system I am currently using, we ended up using a portion of the > controllers for things like the console and shell type tools and used the > other controllers for the running application to use. This way if the > console does something bad, it won't bring down everything. > > My proposed change is to still have the console run on a controller server, > but only use the local instances to connect to blur instead of all of them. > This still could all anyone to run the console on any of the controllers > if they want, but would still only reduce the load to that server's > controllers. > > Thoughts? > I think by default using the RR approach is fine. You could as you are suggesting have a configuration item that would allow for the console to be limited to a subset of the controllers. I also had another thought. What if we let the console startup a controller embedded? That way it would have a view into the shards even if someone shutdown all the regular controllers. What do you think? Aaron > > Chris >
