Bob, I believe what you're running into is NIFI-4737 [1]. When NiFi starts up, it is scanning the content repository to see which files should be aged off from the archive first. Unfortunately it does not log the fact that it is doing this, so everything seems okay... I think the first step is to add in some logging to at least make it obvious what is happening. Then we can look at ways to make it faster on startup.
Thanks -Mark [1] https://issues.apache.org/jira/browse/NIFI-4737 On Jan 3, 2018, at 9:39 PM, Joe Witt <[email protected]<mailto:[email protected]>> wrote: Bob, There should be more in the app log after that controller initialization line and of course there should be things in the user log for when you're attempting access. Looking at the stack dump I'm thinking there is an issue with archive cleanup/management. It is either stuck on a native call or it is just taking a long time. Can you please grab a couple more stack dumps at about 60 second intervals. Then send the bootstrap log (and any rollovered bootstrap logs) again. What i'm keying in on is this "Cleanup Archive for default" Id=47 RUNNABLE at sun.nio.fs.WindowsNativeDispatcher.CreateFile0(Native Method) at sun.nio.fs.WindowsNativeDispatcher.CreateFile(WindowsNativeDispatcher.java:71) at sun.nio.fs.WindowsChannelFactory.open(WindowsChannelFactory.java:302) at sun.nio.fs.WindowsChannelFactory.newFileChannel(WindowsChannelFactory.java:162) at sun.nio.fs.WindowsFileSystemProvider.checkReadAccess(WindowsFileSystemProvider.java:325) at sun.nio.fs.WindowsFileSystemProvider.checkAccess(WindowsFileSystemProvider.java:362) at java.nio.file.Files.exists(Files.java:2385) at org.apache.nifi.controller.repository.FileSystemRepository.destroyExpiredArchives(FileSystemRepository.java:1335) at org.apache.nifi.controller.repository.FileSystemRepository.access$1700(FileSystemRepository.java:84) at org.apache.nifi.controller.repository.FileSystemRepository$DestroyExpiredArchiveClaims.run(FileSystemRepository.java:1572) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Number of Locked Synchronizers: 1 - java.util.concurrent.ThreadPoolExecutor$Worker@43a72f0f Thanks Joe On Wed, Jan 3, 2018 at 7:10 PM, Bob Mroczka <[email protected]<mailto:[email protected]>> wrote: Looks like the thread dump went to the bootstrap log. See attached. HCSC Company Disclaimer The information contained in this communication is confidential, private, proprietary, or otherwise privileged and is intended only for the use of the addressee. Unauthorized use, disclosure, distribution or copying is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately at (312) 653-6000 in Illinois; (800) 447-7828 in Montana; (800)835-8699 in New Mexico; (918)560-3500 in Oklahoma; or (972)766-6900 in Texas.
