nifi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Zhurakousky (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NIFI-1051) lost+found causes org.apache.nifi.controller.repository.FileSystemRepository to fail
Date Thu, 29 Oct 2015 19:06:27 GMT

    [ https://issues.apache.org/jira/browse/NIFI-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14981068#comment-14981068
] 

Oleg Zhurakousky commented on NIFI-1051:
----------------------------------------

While this one would be very easy to fix by overriding "visitFileFailed" in SimpleFileVisitor,
I wonder if this is really a bug?

The above exception will happen on any file/dir that have inadequate permissions, so if anyone
tinkered with content repository and changed permissions on valid files and directories there
the same thing will happen anyway. 



> lost+found causes org.apache.nifi.controller.repository.FileSystemRepository  to fail
> -------------------------------------------------------------------------------------
>
>                 Key: NIFI-1051
>                 URL: https://issues.apache.org/jira/browse/NIFI-1051
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 0.3.0
>            Reporter: Andre
>            Assignee: Oleg Zhurakousky
>             Fix For: 0.4.0
>
>
> I've noticed while doing some test about disk utilisation that FileSystemRepository refuses
to start in case extraneous files are present in the folder set by *nifi.content.repository.directory.default*
> {noformat}
> 2015-10-22 02:52:43,261 ERROR [main] org.apache.nifi.NiFi Failure to launch NiFi due
to java.util.ServiceConfigurationError: org.apache.nifi
> .controller.repository.ContentRepository: Provider org.apache.nifi.controller.repository.FileSystemRepository
could not be instantiated
> java.util.ServiceConfigurationError: org.apache.nifi.controller.repository.ContentRepository:
Provider org.apache.nifi.controller.repository
> .FileSystemRepository could not be instantiated
>         at java.util.ServiceLoader.fail(ServiceLoader.java:224) ~[na:1.7.0_85]
>         at java.util.ServiceLoader.access$100(ServiceLoader.java:181) ~[na:1.7.0_85]
>         at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377) ~[na:1.7.0_85]
>         at java.util.ServiceLoader$1.next(ServiceLoader.java:445) ~[na:1.7.0_85]
>         at org.apache.nifi.nar.ExtensionManager.loadExtensions(ExtensionManager.java:109)
~[nifi-nar-utils-0.3.0.jar:0.3.0]
>         at org.apache.nifi.nar.ExtensionManager.discoverExtensions(ExtensionManager.java:90)
~[nifi-nar-utils-0.3.0.jar:0.3.0]
>         at org.apache.nifi.NiFi.<init>(NiFi.java:120) ~[nifi-runtime-0.3.0.jar:0.3.0]
>         at org.apache.nifi.NiFi.main(NiFi.java:227) ~[nifi-runtime-0.3.0.jar:0.3.0]
> Caused by: java.nio.file.AccessDeniedException: /home/trixpan/nifi/nifi-0.3.0/content_repository/lost+found
>         at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) ~[na:1.7.0_85]
>         at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[na:1.7.0_85]
>         at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[na:1.7.0_85]
>         at sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(UnixFileSystemProvider.java:426)
~[na:1.7.0_85]
>         at java.nio.file.Files.newDirectoryStream(Files.java:413) ~[na:1.7.0_85]
>         at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:179) ~[na:1.7.0_85]
>         at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:199) ~[na:1.7.0_85]
>         at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:69) ~[na:1.7.0_85]
>         at java.nio.file.Files.walkFileTree(Files.java:2602) ~[na:1.7.0_85]
>         at java.nio.file.Files.walkFileTree(Files.java:2635) ~[na:1.7.0_85]
>         at org.apache.nifi.controller.repository.FileSystemRepository$1.call(FileSystemRepository.java:309)
~[nifi-framework-core-0.3.0.jar:0.3.0]
>         at org.apache.nifi.controller.repository.FileSystemRepository$1.call(FileSystemRepository.java:302)
~[nifi-framework-core-0.3.0.jar:0.3.0]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_85]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_85]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
~[na:1.7.0_85]
>         at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_85]
> {noformat}
> This forces the provisioning of separate disks in a quite messy way. 
> According to the doco flowfiles and content repositories should have their own "disks",
yet, due to the behavior above, content folder setting needs to point to a subfolder inside
of a mount point that it dedicated to act as content_repository. 
> Sort of bizarre. Much better would be to ensure the system accepts something like
> # mount /dev/vg/content_repository /opt/nifi/content_repository
> # ls /opt/nifi/content_repository
> lost+found
> # nifi.sh start 



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

Mime
View raw message