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. 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 > > > > > > > > > > > > > > >
