I disagree.  It's hardly ever something reasonable users will need.   The
shell should only be using the public API and provide normal user access.
The utility requires HDFS access.


On Tue, Nov 13, 2012 at 9:21 AM, William Slacum <
wilhelm.von.cl...@accumulo.net> wrote:

> Clarification: I'm all for making a shell friendly interface for invoking
> SplitLarge. I don't really see a point in moving the code.
>
> On Tue, Nov 13, 2012 at 6:19 AM, William Slacum <
> wilhelm.von.cl...@accumulo.net> wrote:
>
> > If it's used by RFile during a system invoked task, then I'd say leave
> it.
> > If you want to make a shell friendly interface for invoking it, I'm all
> for
> > it.
> >
> >
> > On Tue, Nov 13, 2012 at 5:59 AM, David Medinets <
> david.medin...@gmail.com>wrote:
> >
> >> It is out of place, to me, because the Accumulo Shell should be the
> >> primary mechanism for Accumulo system administration. Why have a
> >> utility that can't be invoked from the Shell? Any objections to moving
> >> it?
> >>
> >> On Tue, Nov 13, 2012 at 5:59 AM, Eric Newton <eric.new...@gmail.com>
> >> wrote:
> >> > Yes, I've had users accidentally ingest key/values that were so large
> >> that
> >> > they could not be compacted (the tablet server would run out of memory
> >> and
> >> > crash).  This utility allowed me to remove the large key/values and
> >> > preserve them for analysis.  Why is it that you want to move it?
>  Could
> >> you
> >> > be a little more specific about why it seems out of place?
> >> >
> >> >
> >> > On Mon, Nov 12, 2012 at 10:19 PM, David Medinets
> >> > <david.medin...@gmail.com>wrote:
> >> >
> >> >> Is this utility something useful in a production shop? If so, should
> >> >> it be integrated into the shell? Maybe it should be moved to the
> >> >> contribs directory? I seems out of place in the current
> >> >> org.apache.accumulo.core.file.rfile package.
> >> >>
> >>
> >
> >
>

Reply via email to