On Tue, Oct 8, 2013 at 10:18 PM, Corey Nolet <cjno...@gmail.com> wrote:

> I had started my bisect at the first commit at which it was introduced,
> though it looks like it still took me on a similar path as where it took
> you- needless to say, after the 9 or so steps that it allowed me to take,
> the minicuster command was still broken.
>

I think this comes back to my original point about the classpath.  The
Accumulo scripts are not setting up the Java classpath in a way thats
useful for MAC.  I was wondering if there was ever something special being
done to handle this case, it appears not.


>
>
> On Tue, Oct 8, 2013 at 10:12 PM, Keith Turner <ke...@deenlo.com> wrote:
>
> > On Tue, Oct 8, 2013 at 10:06 PM, Corey Nolet <cjno...@gmail.com> wrote:
> >
> > > With risk of making this more complicated- I just noticed that the
> first
> > > commit posted was still broken- though it didn't lock up like the
> version
> > > currently in master, it appeared to run but threw the ClassNotFound
> > > exception in the Main.err log.
> > >
> > > I'm still poking at this as well.
> > >
> >
> > I am going to take a look at the first place it was introduced in master
> > and see if it works there.
> >
> >
> > >
> > >
> > > On Tue, Oct 8, 2013 at 10:03 PM, Keith Turner <ke...@deenlo.com>
> wrote:
> > >
> > > > I tried using git bisect (for the second time) to tackle this issue
> and
> > > ran
> > > > into an interesting issue.   git bisect took me from master to 1.4.
> >  This
> > > > was unexpected at first, but I understand why git is doing this.  I
> > would
> > > > like to avoid this and only consider commits in master.
> > > >
> > > > $ grep -A 5 org.apache.accumulo pom.xml | head -5
> > > >   <groupId>org.apache.accumulo</groupId>
> > > >   <artifactId>accumulo-project</artifactId>
> > > >   <version>1.6.0-SNAPSHOT</version>
> > > >   <packaging>pom</packaging>
> > > >   <name>Apache Accumulo Project</name>
> > > > $ git bisect start
> > > > $ git bisect bad
> > > > $ git bisect good 6965a8aaa2f53ec796a3487c1639affe0dfc6bfa
> > > > Bisecting: 540 revisions left to test after this (roughly 9 steps)
> > > > [c9469405c3d1aab3784ed5f290df4acaf8568489] ACCUMULO-1168
> > > > $ grep -A 5 org.apache.accumulo pom.xml | head -5
> > > >   <groupId>org.apache.accumulo</groupId>
> > > >   <artifactId>accumulo</artifactId>
> > > >   <packaging>pom</packaging>
> > > >   <version>1.4.3</version>
> > > >   <name>accumulo</name>
> > > >
> > > >
> > > > I found the a post[1] on stack overflow that mentioned using "git
> > > rev-list
> > > > --bisect --first-parent" so I tried the following command and saw git
> > > > segfault.  I blame this on our switch from svn.
> > > >
> > > > $ git rev-list --bisect --first-parent
> > > > 6965a8aaa2f53ec796a3487c1639affe0dfc6bfa..HEAD
> > > > Segmentation fault (core dumped)
> > > >
> > > > If I drop the --first-parent option then it shows me the same commit
> > that
> > > > git bisect does.
> > > >
> > > > $git rev-list --bisect 6965a8aaa2f53ec796a3487c1639affe0dfc6bfa..HEAD
> > > > c9469405c3d1aab3784ed5f290df4acaf8568489
> > > >
> > > > I am still poking at this.  If anyone has advice I would like to hear
> > it.
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> >
> http://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignore-merged-branches
> > > >
> > > >
> > > >
> > > > On Tue, Oct 8, 2013 at 12:02 AM, Corey Nolet <cjno...@gmail.com>
> > wrote:
> > > >
> > > > > Keith,
> > > > >
> > > > > You are right- I mistyped. I meant Main.err not Master.err. I just
> > > > verified
> > > > > this feature worked during the time of this
> > > > > commit: 6965a8aaa2f53ec796a3487c1639affe0dfc6bfa.
> > > > >
> > > > >
> > > > > On Mon, Oct 7, 2013 at 11:39 PM, Keith Turner <ke...@deenlo.com>
> > > wrote:
> > > > >
> > > > > > I just tried running "accumulo miniscluster" and saw the same
> > thing.
> > > >  But
> > > > > > in Main.err, not Master.err are you sure you saw this in
> > Master.err?
> > > > > >
> > > > > > Has this ever worked?   By default the accumulo scripts
> construct a
> > > > very
> > > > > > minimal classpath w/ accumulo-start.jar,  log4j-1.2.15.jar, and
> the
> > > > conf
> > > > > > dir.   If you modify the MAC exec method to print the classpath
> it
> > > uses
> > > > > to
> > > > > > start a java process, then you can see this.   MAC makes the
> > > assumption
> > > > > > that everything it needs is on the Java classpath, which is true
> > when
> > > > its
> > > > > > run from Maven or Eclipse.  However when its run from the
> accumulo
> > > > > scripts,
> > > > > > this is not true.
> > > > > >
> > > > > > Also, for some reason MAC starts zookeeper using Accumulo start
> > main.
> > > >  I
> > > > > > have no idea why its doing this.  Even if it was not doing this,
> I
> > > > think
> > > > > > would fail in different way (i.e. instead of not finding VFS it
> > would
> > > > not
> > > > > > find zookeeper class).
> > > > > >
> > > > > > Are you familiar with accumulo start module?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Oct 7, 2013 at 7:36 AM, Corey Nolet <cjno...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > The MiniAccumuloRunner class that's wired up to
> o.o.a.start.Main.
> > > > > > >
> > > > > > > I was specifically wondering if anyone else is experiencing
> > issues
> > > > > > running
> > > > > > > 'accumulo minicluster' as both the proxy with useMini=true and
> > the
> > > > > > > minicluster command seem broken for me. I'm building from
> remote
> > > HEAD
> > > > > in
> > > > > > > master.
> > > > > > > On Oct 6, 2013 11:32 AM, "John Vines" <jvi...@gmail.com>
> wrote:
> > > > > > >
> > > > > > > > How are you running minicluster?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sun, Oct 6, 2013 at 8:36 AM, Corey Nolet <
> cjno...@gmail.com
> > >
> > > > > wrote:
> > > > > > > >
> > > > > > > > > I'm having issues running the minicluster both in the
> > 'accumulo
> > > > > proxy
> > > > > > > -p
> > > > > > > > > proxy.properties' and via 'accumulo minicluster'. It looks
> > like
> > > > the
> > > > > > > > > Zookeeper process is not starting and the MAC is going into
> > an
> > > > > > infinite
> > > > > > > > > loop waiting for it to start.
> > > > > > > > >
> > > > > > > > > I checked the Master.err logs for the minicluster command
> > and I
> > > > see
> > > > > > the
> > > > > > > > > following:
> > > > > > > > >
> > > > > > > > > Uncaught exception: java.lang.NoClassDefFoundError:
> > > > > > > > > org/apache/commons/vfs2/impl/VFSClassLoader
> > > > > > > > > java.lang.NoClassDefFoundError:
> > > > > > > > org/apache/commons/vfs2/impl/VFSClassLoader
> > > > > > > > > at java.lang.Class.getDeclaredMethods0(Native Method)
> > > > > > > > > at
> java.lang.Class.privateGetDeclaredMethods(Class.java:2521)
> > > > > > > > > at java.lang.Class.getMethod0(Class.java:2764)
> > > > > > > > > at java.lang.Class.getMethod(Class.java:1653)
> > > > > > > > > at org.apache.accumulo.start.Main.main(Main.java:42)
> > > > > > > > > Caused by: java.lang.ClassNotFoundException:
> > > > > > > > > org.apache.commons.vfs2.impl.VFSClassLoader
> > > > > > > > > at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> > > > > > > > > at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> > > > > > > > > at java.security.AccessController.doPrivileged(Native
> Method)
> > > > > > > > > at
> java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> > > > > > > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> > > > > > > > > at
> > > sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> > > > > > > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> > > > > > > > > ... 5 more
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > the commons-vfs2.jar is in Accumulo's lib directory. I'm
> > using
> > > > > Hadoop
> > > > > > > > > 1.2.1.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Cheers
> > > > > > > > ~John
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to