accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: ChangeSecret Utility
Date Thu, 14 Jul 2016 19:36:38 GMT
Ah, I see. So the KeywordExecutable stuff is required to call the no-arg
constructor to load classes, yet the one in the Shell is actually doing
work. (ServiceLoader, which KeywordExecutable uses, is best used when
instantiating lightweight factories.)

So, there are two options:

  1. Make the no-arg constructor in the Shell do less work. (this should be
easy, because it's only called by Shell.main, and main can just pass the
parameters that the no-arg constructor was assuming)
  2. Move the KeywordExecutable stuffs for Shell into a minimal
launcher/factory class for Shell; see **/MasterExecutable.java for another
case where I had to do this.

On Thu, Jul 14, 2016 at 3:18 PM Mike Miller <michaelpmiller@gmail.com>
wrote:

> I think I have isolated the problem and think this may be a bug. The
> interference is happening when jline.console.ConsoleReader gets
> instantiated in the constructor of org.apache.accumulo.shell.Shell. Even
> though I am not starting the shell with bin/accumulo, it is still being
> instantiated by the ServiceLoader in o.a.a.start.Main.  See the evidence of
> my manually thrown exception and stacktrace below.
> Shell() called from...
> java.lang.Exception
>     at org.apache.accumulo.shell.Shell.<init>(Shell.java:247)
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>     at
>
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>     at
>
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>     at java.lang.Class.newInstance(Class.java:442)
>     at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
>     at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
>     at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
>     at org.apache.accumulo.start.Main.checkDuplicates(Main.java:223)
>     at org.apache.accumulo.start.Main.getExecutables(Main.java:215)
>     at org.apache.accumulo.start.Main.main(Main.java:78)
>
> I tested ChangeSecret again with an empty constructor in o.a.a.shell.Shell
> and it has no problem reading in the passwords. This seems like a bug
> between the two classes but I am just not sure which one is the guilty
> party.
>
>
> On Thu, Jul 14, 2016 at 7:36 AM, Mike Miller <michaelpmiller@gmail.com>
> wrote:
>
> > Sorry for the confusion, I was thinking that
> > org.apache.accumulo.shell.Shell gets instantiated when calling
> bin/accumulo
> > org.apache.accumulo.server.util.ChangeSecret. I think you are right about
> > the problem being with the classpath setup by the bin/accumulo script.
> >
> > On Wed, Jul 13, 2016 at 6:33 PM, Christopher <ctubbsii@apache.org>
> wrote:
> >
> >> Oh wait, strike that. We don't have a shell command for this. I think I
> >> misunderstood your use of the word "shell".
> >> If I understand correctly, doing this works:
> >> CLASSPATH=.... java org.apache.accumulo.server.util.ChangeSecret
> >> but this doesn't:
> >> bin/accumulo org.apache.accumulo.server.util.ChangeSecret
> >>
> >> This would imply that the thing which is interfering is something coming
> >> in
> >> from the classpath which is set up by bin/accumulo.
> >>
> >> On Wed, Jul 13, 2016 at 6:27 PM Christopher <ctubbsii@apache.org>
> wrote:
> >>
> >> > The shell does change the input charset (to latin1, I believe), so
> maybe
> >> > that has an effect?
> >> >
> >> >
> >> > On Wed, Jul 13, 2016 at 4:22 PM Josh Elser <josh.elser@gmail.com>
> >> wrote:
> >> >
> >> >> That's really weird. I have no suggestions without digging into the
> >> code
> >> >> myself. Sorry :\
> >> >>
> >> >> Mike Miller wrote:
> >> >> > After further debugging, I don't think the problem is with the
> >> >> JCommander
> >> >> > classes directly.  I have isolated the problem to be with something
> >> in
> >> >> the
> >> >> > accumulo shell. When I run the ChangeSecret utility as a standalone
> >> java
> >> >> > program on the command line, it has no problem accepting input.
Any
> >> idea
> >> >> > what in the shell might be causing this issue? Is there something
> >> else
> >> >> > accepting input that could be interfering?
> >> >> >
> >> >> > On Tue, Jul 12, 2016 at 12:02 PM, Mike Miller<
> >> michaelpmiller@gmail.com>
> >> >> > wrote:
> >> >> >
> >> >> >> It looks the problem is with the parsing of the arguments
in the
> >> >> >> JCommander classes. When I run ChangeSecret through the Eclipse
> >> >> debugger it
> >> >> >> uses the DefaultConsole.readPassword method to read in the
> password
> >> >> and it
> >> >> >> seems to take my input correctly. When I ran the utility through
> the
> >> >> >> accumulo script and attached jdb, it looks like its using
an
> >> internal
> >> >> class
> >> >> >> called JDK6Console to read the password. The simple fact that
it
> >> has a
> >> >> JDK
> >> >> >> version in the name (I am running Java 1.8) gives me the feeling
> >> this
> >> >> might
> >> >> >> be the problem.  I will keep investigating.
> >> >> >>
> >> >> >> On Tue, Jul 12, 2016 at 10:43 AM, Josh Elser<josh.elser@gmail.com
> >
> >> >> wrote:
> >> >> >>
> >> >> >>> Mike Miller wrote:
> >> >> >>>
> >> >> >>>> I was looking at the bug ACCUMULO-2971
> >> >> >>>> <https://issues.apache.org/jira/browse/ACCUMULO-2971>
  but I
> am
> >> >> unable
> >> >> >>>> to
> >> >> >>>> get the ChangeSecret utility to run. I also noticed
the bug 2972
> >> >> >>>> <https://issues.apache.org/jira/browse/ACCUMULO-2972>
  which
> >> >> states the
> >> >> >>>> documentation should instruct the user to run the
utility as so:
> >> >> >>>> accumulo org.apache.accumuloserver.util.ChangeSecret
> >> >> >>>>
> >> >> >>>> I have a standalone instance of 1.7.2 setup on my
machine. I am
> >> >> running
> >> >> >>>> the
> >> >> >>>> utility as myself, which is also the user that is
running Hadoop
> >> and
> >> >> who
> >> >> >>>> has control over the files in HDFS, but when the utility
prompts
> >> for
> >> >> the
> >> >> >>>> passwords, it is only letting me enter a single keystroke
for
> each
> >> >> >>>> password. Then I get an
> >> >> >>>> org.apache.zookeeper.KeeperException$NoAuthException
because I
> am
> >> >> unable
> >> >> >>>> to
> >> >> >>>> enter the passwords correctly.
> >> >> >>>>
> >> >> >>> That's weird.
> >> >> >>>
> >> >> >>> Christopher suggested that it might be an issue with the
latest
> >> JLine
> >> >> jar
> >> >> >>>> (2.11) so I pulled down the older jar (2.10) and replaced
the
> >> newer
> >> >> jar
> >> >> >>>> in
> >> >> >>>> my lib. This didn't seem to have any effect. Could
this be an
> >> issue
> >> >> with
> >> >> >>>> my
> >> >> >>>> local install?
> >> >> >>>>
> >> >> >>> It might just be broken. It's not something that is commonly
> used,
> >> and
> >> >> >>> has probably atrophied.
> >> >> >>>
> >> >> >>> Have you tried to attach a remote debugger to the process
(you
> can
> >> put
> >> >> >>> the JVM properties into ACCUMULO_GENERAL_OPTS via
> accumulo-env.sh)
> >> to
> >> >> trace
> >> >> >>> through what it's doing?
> >> >> >>>
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
> >
>

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