[jira] [Commented] (ACCUMULO-3923) bootstrap_hdfs.sh does not copy correct jars to hdfs

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328621#comment-15328621
 ] 

Dave Marion commented on ACCUMULO-3923:
---

I will cherry-pick this back to 1.7.2 and test it with ACCUMULO-4341 tomorrow.

>  bootstrap_hdfs.sh does not copy correct jars to hdfs
> -
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Accumulo-Pull-Requests - Build # 338 - Still Failing

2016-06-13 Thread Apache Jenkins Server
The Apache Jenkins build system has built Accumulo-Pull-Requests (build #338)

Status: Still Failing

Check console output at 
https://builds.apache.org/job/Accumulo-Pull-Requests/338/ to view the results.

[jira] [Commented] (ACCUMULO-3923) bootstrap_hdfs.sh does not copy correct jars to hdfs

2016-06-13 Thread Josh Elser (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328359#comment-15328359
 ] 

Josh Elser commented on ACCUMULO-3923:
--

bq. When did we move to slf4j?

1.7.0 iirc.

>  bootstrap_hdfs.sh does not copy correct jars to hdfs
> -
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-3923) bootstrap_hdfs.sh does not copy correct jars to hdfs

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328348#comment-15328348
 ] 

Dave Marion commented on ACCUMULO-3923:
---

When did we move to slf4j?

>  bootstrap_hdfs.sh does not copy correct jars to hdfs
> -
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328335#comment-15328335
 ] 

Dave Marion commented on ACCUMULO-4341:
---

I think I have this resolved. It's all working now locally, to include running 
bootstrap_hdfs.sh and running Accumulo with the jars out of HDFS. I'm going to 
put up a small patch against 1.8.0. I didn't have time to test against 1.7. If 
someone gets to it before I do, feel free to apply the patch and close my PR.

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>Priority: Blocker
> Fix For: 1.7.2, 1.8.0
>
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 

[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327966#comment-15327966
 ] 

Dave Marion commented on ACCUMULO-4341:
---

I believe the VFS code, without the ServiceLoader, will work. It works in 1.6.

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>Priority: Blocker
> Fix For: 1.7.2, 1.8.0
>
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
>   at 

[jira] [Commented] (ACCUMULO-3923) bootstrap_hdfs.sh does not copy correct jars to hdfs

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327965#comment-15327965
 ] 

Dave Marion commented on ACCUMULO-3923:
---

bq. Any reason you didn't commit your change to 1.7 as well, Dave Marion? (1.6 
too even?)

 Oversight on my part. It can be cherry-picked back to any release that uses 
slf4j.

>  bootstrap_hdfs.sh does not copy correct jars to hdfs
> -
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-3923) bootstrap_hdfs.sh does not copy correct jars to hdfs

2016-06-13 Thread Mike Drob (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327949#comment-15327949
 ] 

Mike Drob commented on ACCUMULO-3923:
-

Renamed this issue to reflect the fix made. ACCUMULO-4341 can be used to track 
the rest of the work related to the VFS classloader + KeywordExecutable

>  bootstrap_hdfs.sh does not copy correct jars to hdfs
> -
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (ACCUMULO-3923) bootstrap_hdfs.sh does not copy correct jars to hdfs

2016-06-13 Thread Mike Drob (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated ACCUMULO-3923:

Summary:  bootstrap_hdfs.sh does not copy correct jars to hdfs  (was: VFS 
ClassLoader doesnt' work with KeywordExecutable)

>  bootstrap_hdfs.sh does not copy correct jars to hdfs
> -
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Mike Drob (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327911#comment-15327911
 ] 

Mike Drob commented on ACCUMULO-4341:
-

Could we consider reverting some of the VFS changes? Do we believe that the VFS 
code in 1.7.1 would have worked?

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>Priority: Blocker
> Fix For: 1.7.2, 1.8.0
>
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
>   at 

[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327854#comment-15327854
 ] 

Dave Marion commented on ACCUMULO-4341:
---

I'm wondering if this is really due to a change in the ClassLoader object 
between Java 6 and 7. If you look at the javadoc for the two-arg form of 
CLassLoader.loadClass(), Java 7 introduced a lock and parallel capable class 
loaders.

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>Priority: Blocker
> Fix For: 1.7.2, 1.8.0
>
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at 

[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Josh Elser (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327776#comment-15327776
 ] 

Josh Elser commented on ACCUMULO-4341:
--

[~mdrob] made this a blocker against 1.7.2 until we figure out what we're going 
to do (doc it or fix it).

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>Priority: Blocker
> Fix For: 1.7.2, 1.8.0
>
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
>   at 

[jira] [Updated] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Josh Elser (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Elser updated ACCUMULO-4341:
-
Fix Version/s: 1.7.2

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
> Fix For: 1.7.2, 1.8.0
>
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
>   at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
>   at 

[jira] [Updated] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Josh Elser (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Elser updated ACCUMULO-4341:
-
Priority: Blocker  (was: Major)

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>Priority: Blocker
> Fix For: 1.7.2, 1.8.0
>
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
>   at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
>

[jira] [Updated] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Josh Elser (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Elser updated ACCUMULO-4341:
-
Fix Version/s: 1.8.0

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
> Fix For: 1.7.2, 1.8.0
>
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
>   at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
>   at 

[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Josh Elser (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327775#comment-15327775
 ] 

Josh Elser commented on ACCUMULO-4341:
--

bq. I didn't realize it until now, but I am loading jars out of HDFS with 1.7.0 
with the ServiceLoader. In this case, where it is working, I am only using 
putting my application jars into HDFS and setting the context name on tables. 
Pushing the accumulo jars into HDFS likely the case where it will not work.

Ok, that's a reasonable workaround (easily doc'ed anyways). Will defer to 
Christopher about fixing the ServiceLoader stuff.

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
> Fix For: 1.7.2, 1.8.0
>
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> 

[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327763#comment-15327763
 ] 

Dave Marion commented on ACCUMULO-4341:
---

Loading classes out of HDFS has been a feature supported from 1.5 with the new 
classloader. The integration of the ServiceLoader was introduced in 1.7.0. 

I didn't realize it until now, but I am loading jars out of HDFS with 1.7.0 
with the ServiceLoader. In this case, where it is working, I am *only* using 
putting my application jars into HDFS and setting the context name on tables. 
Pushing the accumulo jars into HDFS likely the case where it will not work.

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> 

[jira] [Commented] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Josh Elser (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327759#comment-15327759
 ] 

Josh Elser commented on ACCUMULO-3923:
--

bq. Dropping 1.7.2 fix version from this JIRA since the fix was only committed 
to 1.8

Didn't commons-vfs-2.1 land on 1.7 as well though (which is what would have 
'fixed' the issue)?

bq. the fix was only committed to 1.8

Any reason you didn't commit your change to 1.7 as well, [~dlmarion]? (1.6 too 
even?)

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Mike Drob (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated ACCUMULO-3923:

Fix Version/s: (was: 1.7.2)

Dropping 1.7.2 fix version from this JIRA since the fix was only committed to 
1.8

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Josh Elser (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327734#comment-15327734
 ] 

Josh Elser commented on ACCUMULO-4341:
--

[~ctubbsii], FYI.

If we don't figure out what is broken here before 1.8.0, I'm going to recommend 
that we need to very publicly state that HDFS classloading is not a supported 
feature for 1.8.0. I really don't want to send someone down a rabbit hole to 
find out that this doesn't work.

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   

[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Josh Elser (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327729#comment-15327729
 ] 

Josh Elser commented on ACCUMULO-4341:
--

bq. No, the service loader feature is busted.

The service loader feature is used to start all Accumulo processes...

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
>   at 

[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327728#comment-15327728
 ] 

Dave Marion commented on ACCUMULO-4341:
---

I can't even `accumulo init` with the jars in HDFS.

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
>   at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
>   at 

[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327720#comment-15327720
 ] 

Dave Marion commented on ACCUMULO-4341:
---

No, the service loader feature is busted.

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
>   at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
>   at 

[jira] [Resolved] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Josh Elser (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Elser resolved ACCUMULO-3923.
--
   Resolution: Fixed
Fix Version/s: (was: 1.7.3)
   1.7.2

Closing per Dave's assessment.

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.7.2, 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Josh Elser (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327704#comment-15327704
 ] 

Josh Elser commented on ACCUMULO-4341:
--

So, VFS classloading from HDFS is still busted? That's the takeaway I see 
here...

> ServiceLoader deadlock with classes loaded from HDFS
> 
>
> Key: ACCUMULO-4341
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.8.0
>Reporter: Dave Marion
>
> With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
> running `accumulo help` will hang. 
> A jstack of the process shows the IPC Client thread at:
> {noformat}
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
>   at 
> org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
>   at 
> org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
>   at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
> {noformat}
> and the main thread at:
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1454)
>   - locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1399)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
>   at 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
>   - locked <0xf57fd008> (a 
> org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
>   at 
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
>   - locked <0xf5ad9138> (a java.util.HashMap)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
>   at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   - locked <0xf5af3b88> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xf6f5c2f8> (a 
> org.apache.commons.vfs2.impl.VFSClassLoader)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
>   at 

[jira] [Commented] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327684#comment-15327684
 ] 

Dave Marion commented on ACCUMULO-3923:
---

Based on my testing, I would say that the issue with VFS-500 is resolved. There 
is a new issue with the ServiceLoader (ACCUMULO-4341), but I believe the 
problems with this JIRA are resolved. 

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.7.3, 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327650#comment-15327650
 ] 

Dave Marion commented on ACCUMULO-3923:
---

Yes, it should.

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.7.3, 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Josh Elser (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327638#comment-15327638
 ] 

Josh Elser commented on ACCUMULO-3923:
--

Gotcha. I was a little confused that you could change the accepted text for 
general.vfs.classpaths by the bootstrap_hdfs.sh script without also changing 
the VFS-based ClassLoader.

Does that mean that the CL could already handle directories and regexs?

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.7.3, 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327632#comment-15327632
 ] 

Dave Marion commented on ACCUMULO-3923:
---

I pushed my changes to the script.

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.7.3, 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327631#comment-15327631
 ] 

Dave Marion commented on ACCUMULO-3923:
---

bq. Oh, is this property not also used by the Java ClassLoader? Maybe that was 
part of my confusion.

The property is used by both the bootstrap_hdfs.sh script and the VFS 
classloader. My changes to bootstrap_hdfs.sh are in the parsing of the property 
from accumulo-site.xml.

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.7.3, 1.8.0
>
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Josh Elser (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327627#comment-15327627
 ] 

Josh Elser commented on ACCUMULO-3923:
--

bq. I have some changes locally to bootstrap_hdfs.sh so that it will support 
the following property values in general.vfs.classpaths:

Oh, is this property not also used by the Java ClassLoader? Maybe that was part 
of my confusion.

bq. Additionally, when trying to run `accumulo help` to test these changes, I 
found that the client is in a deadlock situation. Ticket to follow.

Thanks for helping out, Dave.

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.7.3, 1.8.0
>
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327618#comment-15327618
 ] 

Dave Marion commented on ACCUMULO-3923:
---

I have some changes locally to bootstrap_hdfs.sh so that it will support the 
following property values in general.vfs.classpaths:

hdfs://host:port/accumulo/classpath/
hdfs://host:port/accumulo/classpath/.*.jar
hdfs://host:port/accumulo/classpath/.*.jar,hdfs://host:port/accumulo/classpath2/.*.jar

In all cases, it will create the /accumulo/classpath if it does not exist and 
push the jars from the lib directory into the specified directory. I also found 
in my testing that the slf4j jars need to be kept on the local server. 
Additionally, when trying to run `accumulo help` to test these changes, I found 
that the client is in a deadlock situation. Ticket to follow.

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.7.3, 1.8.0
>
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ACCUMULO-4341) ServiceLoader deadlock with classes loaded from HDFS

2016-06-13 Thread Dave Marion (JIRA)
Dave Marion created ACCUMULO-4341:
-

 Summary: ServiceLoader deadlock with classes loaded from HDFS
 Key: ACCUMULO-4341
 URL: https://issues.apache.org/jira/browse/ACCUMULO-4341
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.8.0
Reporter: Dave Marion


With Accumulo set up to use general.vfs.classpaths to load classes from HDFS, 
running `accumulo help` will hang. 

A jstack of the process shows the IPC Client thread at:
{noformat}
   java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
org.apache.hadoop.conf.Configuration.getClassByNameOrNull(Configuration.java:2051)
at 
org.apache.hadoop.util.ReflectionUtils.setJobConf(ReflectionUtils.java:91)
at 
org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:75)
at 
org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:133)
at 
org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1086)
at org.apache.hadoop.ipc.Client$Connection.run(Client.java:966)
{noformat}

and the main thread at:

{noformat}
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.apache.hadoop.ipc.Client.call(Client.java:1454)
- locked <0xf09a2898> (a org.apache.hadoop.ipc.Client$Call)
at org.apache.hadoop.ipc.Client.call(Client.java:1399)
at 
org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
at 
org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:752)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
at 
org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1982)
at 
org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1128)
at 
org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1124)
at 
org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at 
org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1124)
at 
org.apache.commons.vfs2.provider.hdfs.HdfsFileObject.doAttach(HdfsFileObject.java:85)
at 
org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:173)
- locked <0xf57fd008> (a 
org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
at 
org.apache.commons.vfs2.provider.AbstractFileObject.getContent(AbstractFileObject.java:1236)
- locked <0xf57fd008> (a 
org.apache.commons.vfs2.provider.hdfs.HdfsFileSystem)
at 
org.apache.commons.vfs2.impl.VFSClassLoader.getPermissions(VFSClassLoader.java:300)
at 
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
- locked <0xf5ad9138> (a java.util.HashMap)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at 
org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:226)
at 
org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:180)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
- locked <0xf5af3b88> (a 
org.apache.commons.vfs2.impl.VFSClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0xf6f5c2f8> (a 
org.apache.commons.vfs2.impl.VFSClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
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:196)
at org.apache.accumulo.start.Main.getExecutables(Main.java:188)
at org.apache.accumulo.start.Main.main(Main.java:52)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Dave Marion (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327618#comment-15327618
 ] 

Dave Marion edited comment on ACCUMULO-3923 at 6/13/16 3:32 PM:


I have some changes locally to bootstrap_hdfs.sh so that it will support the 
following property values in general.vfs.classpaths:

hdfs://host:port/accumulo/classpath/
hdfs://host:port/accumulo/classpath/.*.jar
hdfs://host:port/accumulo/classpath/.\*.jar,hdfs://host:port/accumulo/classpath2/.*.jar

In all cases, it will create the /accumulo/classpath if it does not exist and 
push the jars from the lib directory into the specified directory. I also found 
in my testing that the slf4j jars need to be kept on the local server. 
Additionally, when trying to run `accumulo help` to test these changes, I found 
that the client is in a deadlock situation. Ticket to follow.


was (Author: dlmarion):
I have some changes locally to bootstrap_hdfs.sh so that it will support the 
following property values in general.vfs.classpaths:

hdfs://host:port/accumulo/classpath/
hdfs://host:port/accumulo/classpath/.*.jar
hdfs://host:port/accumulo/classpath/.*.jar,hdfs://host:port/accumulo/classpath2/.*.jar

In all cases, it will create the /accumulo/classpath if it does not exist and 
push the jars from the lib directory into the specified directory. I also found 
in my testing that the slf4j jars need to be kept on the local server. 
Additionally, when trying to run `accumulo help` to test these changes, I found 
that the client is in a deadlock situation. Ticket to follow.

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.7.3, 1.8.0
>
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Accumulo-Pull-Requests - Build # 337 - Failure

2016-06-13 Thread Apache Jenkins Server
The Apache Jenkins build system has built Accumulo-Pull-Requests (build #337)

Status: Failure

Check console output at 
https://builds.apache.org/job/Accumulo-Pull-Requests/337/ to view the results.

[jira] [Commented] (ACCUMULO-3923) VFS ClassLoader doesnt' work with KeywordExecutable

2016-06-13 Thread Josh Elser (JIRA)

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327431#comment-15327431
 ] 

Josh Elser commented on ACCUMULO-3923:
--

bq. From the "Running Accumulo From HDFS" section in the blog

I'll also vouch for Mike's confusion -- I remember wondering the same exact 
thing when I filed this issue. Does that mean you provide a directory? A CSV of 
directories? If you can clarify here, we can update the docs which would be 
great.

> VFS ClassLoader doesnt' work with KeywordExecutable
> ---
>
> Key: ACCUMULO-3923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3923
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Dave Marion
>Priority: Critical
> Fix For: 1.7.3, 1.8.0
>
>
> Trying to make the VFS classloading stuff work and it doesn't seem like 
> ServiceLoader is finding any of the KeywordExecutable implementations.
> Best I can tell after looking into this, VFSClassLoader (created by 
> AccumuloVFSClassLoader) has all of the jars listed as resources, but when 
> ServiceLoader tries to find the META-INF/services definitions, it returns 
> nothing, and thus we think the keyword must be a class name. Seems like a 
> commons-vfs bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)