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