Bob In the latests thread dumps things look good now with the archive thread. So it seems like it should be running now (please send latest app log if not) and it seems like what mark suggested is the issue (slowwww archive review on startup).
Thanks On Thu, Jan 4, 2018 at 9:38 AM, Mark Payne <[email protected]> wrote: > 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]> 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]> > 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. > >
