accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Miller <michaelpmil...@gmail.com>
Subject Re: ChangeSecret Utility
Date Fri, 15 Jul 2016 13:38:21 GMT
Now that we got to the bottom of this issue, I created a JIRA ticket so I
can fix it!
https://issues.apache.org/jira/browse/ACCUMULO-4374

On Thu, Jul 14, 2016 at 3:36 PM, Christopher <ctubbsii@apache.org> wrote:

> 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