incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
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 <rohr.chris@gmail.com> 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
>

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