accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Newton <eric.new...@gmail.com>
Subject Re: Launching Accumulo Servers Programatically
Date Tue, 12 May 2015 00:19:53 GMT
An in-process accumulo would be a good replacement for Mock, which is dying
on the vine.

-Eric


On Mon, May 11, 2015 at 6:04 PM, dlmarion <dlmarion@comcast.net> wrote:

>
>
> Sorry for the short response, sitting at the ball field, but want to chime
> in. I have some interest in this area as well. I have some local code
> modifications that I intend to commit at some point to start / stop
> Accumulo. This involves making the admin methods programatically accessible.
>
>
>
>
> -------- Original message --------
> From: Jim Klucar <klucar@gmail.com>
> Date: 05/11/2015  5:09 PM  (GMT-05:00)
> To: dev@accumulo.apache.org
> Subject: Launching Accumulo Servers Programatically
>
> Devs,
>
> I've been working on the mesos-accumulo framework. For those not familiar
> with Mesos, it is a cluster resource manager that allows you to launch
> tasks across the cluster. To do that, you write a mesos framework.
>
> We have proven this is possible with accumulo by writing a quick Scala
> framework implementation that uses the accumulo script to launch servers
> from a command line. This worked fine but we would like more insight into
> the servers once they're launched, outside of does the pid still exist on
> the machine. What I would like to do is something like:
>
> org.apache.accumulo.server.Master master = new o.a.a.server.Master();
>
> from inside the mesos executor code. Then setup some config, or pass it in
> the constructor and call master.run() or whatever. The point is at the end
> of some procedure the server is running, and I can call methods like
> master.shutdown() or master.ping() or whatever else is exposed.  A nice
> standard server interface across server types would be great.
>
> I realize this may be quite a refactoring of all the server classes so I
> thought I'd gather some opinions on the idea here instead of just writing
> JIRA tickets.
>
> Jim
>

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