Re: Issues running Minicluster in o.a.a.start.Main

2013-10-09 Thread Keith Turner 
I am working on a fix for this.


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.


 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
  groupIdorg.apache.accumulo/groupId
  artifactIdaccumulo-project/artifactId
  version1.6.0-SNAPSHOT/version
  packagingpom/packaging
  nameApache 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
  groupIdorg.apache.accumulo/groupId
  artifactIdaccumulo/artifactId
  packagingpom/packaging
  version1.4.3/version
  nameaccumulo/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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-09 Thread Keith Turner 
On Tue, Oct 8, 2013 at 9:45 PM, Corey Nolet cjno...@gmail.com wrote:

 Keith,

 It appears that the proxy's useMini and the minicluster command broke
 somewhere between

 1edccf6b30541841bb08329317c6289aca8c8d73
 ACCUMULO-1707 applying Steve's patch

 and

 98d7a9efc6d07e71d3803b3830bf9dc9ce8dec9d
 ACCUMULO-1558 made import table fail when files do not exist

 There was some weird merging happening during that sequence of commits. At
 some point it looks like the master pom was set to version 1.5.1. If a bug
 was fixed in this sequence of commits and the fix inherently broke the
 commands because they didn't belong in start.Main to begin with, I'm
 thinking it would probably be best to take the useMini property out of the
 proxy and the minicluster command out of start.Main.

 If a bug was introduced, I'd like to get a ticket up for it.


Yeah, go ahead and open a ticket.







 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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-09 Thread Corey Nolet 
Looking at the commit history in master using gitk/gitx shows duplicated
history. It looks like January through July 2013 occur at least twice in
the commit history (with 2012 in between them). I'm suspecting this may
have been why bisect wasn't working for me



On Wed, Oct 9, 2013 at 1:25 PM, Keith Turner ke...@deenlo.com wrote:

 On Tue, Oct 8, 2013 at 9:45 PM, Corey Nolet cjno...@gmail.com wrote:

  Keith,
 
  It appears that the proxy's useMini and the minicluster command broke
  somewhere between
 
  1edccf6b30541841bb08329317c6289aca8c8d73
  ACCUMULO-1707 applying Steve's patch
 
  and
 
  98d7a9efc6d07e71d3803b3830bf9dc9ce8dec9d
  ACCUMULO-1558 made import table fail when files do not exist
 
  There was some weird merging happening during that sequence of commits.
 At
  some point it looks like the master pom was set to version 1.5.1. If a
 bug
  was fixed in this sequence of commits and the fix inherently broke the
  commands because they didn't belong in start.Main to begin with, I'm
  thinking it would probably be best to take the useMini property out of
 the
  proxy and the minicluster command out of start.Main.
 
  If a bug was introduced, I'd like to get a ticket up for it.
 

 Yeah, go ahead and open a ticket.


 
 
 
 
 
  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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-09 Thread Keith Turner 
I have accumulo minicluster working now.   I changed the way MAC
determines what classpath to use.  I pushed a commit [1] to a branch on
github[2] if you want to take a look.  I am still experimenting with the
change.   I ran into some other bugs in master while working on this and
fixed those.  I also reopened ACCUMULO-1368 rather than opening a new
ticket.


[1]
https://github.com/keith-turner/accumulo/commit/1b9fbbc82a49e4939179f2f7b0b013517836b7f0
[2] https://github.com/keith-turner/accumulo/tree/ACCUMULO-1368


On Wed, Oct 9, 2013 at 8:52 PM, Corey Nolet cjno...@gmail.com wrote:

 Looking at the commit history in master using gitk/gitx shows duplicated
 history. It looks like January through July 2013 occur at least twice in
 the commit history (with 2012 in between them). I'm suspecting this may
 have been why bisect wasn't working for me



 On Wed, Oct 9, 2013 at 1:25 PM, Keith Turner ke...@deenlo.com wrote:

  On Tue, Oct 8, 2013 at 9:45 PM, Corey Nolet cjno...@gmail.com wrote:
 
   Keith,
  
   It appears that the proxy's useMini and the minicluster command broke
   somewhere between
  
   1edccf6b30541841bb08329317c6289aca8c8d73
   ACCUMULO-1707 applying Steve's patch
  
   and
  
   98d7a9efc6d07e71d3803b3830bf9dc9ce8dec9d
   ACCUMULO-1558 made import table fail when files do not exist
  
   There was some weird merging happening during that sequence of commits.
  At
   some point it looks like the master pom was set to version 1.5.1. If a
  bug
   was fixed in this sequence of commits and the fix inherently broke the
   commands because they didn't belong in start.Main to begin with, I'm
   thinking it would probably be best to take the useMini property out of
  the
   proxy and the minicluster command out of start.Main.
  
   If a bug was introduced, I'd like to get a ticket up for it.
  
 
  Yeah, go ahead and open a ticket.
 
 
  
  
  
  
  
   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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-08 Thread Keith Turner 
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
  groupIdorg.apache.accumulo/groupId
  artifactIdaccumulo-project/artifactId
  version1.6.0-SNAPSHOT/version
  packagingpom/packaging
  nameApache 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
  groupIdorg.apache.accumulo/groupId
  artifactIdaccumulo/artifactId
  packagingpom/packaging
  version1.4.3/version
  nameaccumulo/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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-08 Thread Corey Nolet 
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
   groupIdorg.apache.accumulo/groupId
   artifactIdaccumulo-project/artifactId
   version1.6.0-SNAPSHOT/version
   packagingpom/packaging
   nameApache 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
   groupIdorg.apache.accumulo/groupId
   artifactIdaccumulo/artifactId
   packagingpom/packaging
   version1.4.3/version
   nameaccumulo/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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-08 Thread Keith Turner 
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
groupIdorg.apache.accumulo/groupId
artifactIdaccumulo-project/artifactId
version1.6.0-SNAPSHOT/version
packagingpom/packaging
nameApache 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
groupIdorg.apache.accumulo/groupId
artifactIdaccumulo/artifactId
packagingpom/packaging
version1.4.3/version
nameaccumulo/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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-08 Thread Corey Nolet 
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
 groupIdorg.apache.accumulo/groupId
 artifactIdaccumulo-project/artifactId
 version1.6.0-SNAPSHOT/version
 packagingpom/packaging
 nameApache 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
 groupIdorg.apache.accumulo/groupId
 artifactIdaccumulo/artifactId
 packagingpom/packaging
 version1.4.3/version
 nameaccumulo/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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-07 Thread Corey Nolet 
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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-07 Thread Keith Turner 
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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-07 Thread Corey Nolet 
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

Re: Issues running Minicluster in o.a.a.start.Main

2013-10-06 Thread John Vines 
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