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.
On Sun, Apr 6, 2014 at 12:45 PM, Chris Rohr <[EMAIL PROTECTED]> wrote: 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?
Cool. Sounds good. On Mon, Apr 7, 2014 at 11:33 AM, Chris Rohr <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext