incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <>
Subject Re: Blur Console Runtime Question
Date Mon, 07 Apr 2014 11:46:20 GMT
On Sun, Apr 6, 2014 at 12:45 PM, Chris Rohr <> 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?


> Chris

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message