Hi,
when there is a folder with lots of files, the File Reader starts to scan all but upon closing the node, the process still runs in the background.
After closing
About two minutes after closing
250112 Knime File Reader issue topic 85671 threaddump-1736685680986.tdump.txt (78.2 KB)
Several minutes in the process is still running in the background.
Best
Mike
Hi @mwiegand,
I cannot reproduce the behavior. I took a thread dump while the dialog is “Scanning…” and one right after clicking “Cancel” to close the dialog (“Ok” shows has the same behavior).
The actual scanning (so I/O and CPU work) happens from a “SwingWorker” background thread (so the UI is not “frozen”):
While “scanning” (you can see file system stuff in the trace):
"SwingWorker-pool-9-thread-6" #2317 daemon prio=5 os_prio=31 cpu=24791.53ms elapsed=358.11s tid=0x0000000134c31600 nid=0x2dc07 sleeping [0x00000003965ae000]
java.lang.Thread.State: RUNNABLE
at sun.nio.fs.UnixNativeDispatcher.stat0(java.base@17.0.5/Native Method)
at sun.nio.fs.UnixNativeDispatcher.stat(java.base@17.0.5/Unknown Source)
at sun.nio.fs.UnixFileAttributes.get(java.base@17.0.5/Unknown Source)
at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(java.base@17.0.5/Unknown Source)
at sun.nio.fs.UnixFileSystemProvider.readAttributes(java.base@17.0.5/Unknown Source)
at org.knime.filehandling.core.fs.local.fs.LocalFileSystemProvider.readAttributes(LocalFileSystemProvider.java:291)
at java.nio.file.Files.readAttributes(java.base@17.0.5/Unknown Source)
at java.nio.file.FileTreeWalker.getAttributes(java.base@17.0.5/Unknown Source)
at java.nio.file.FileTreeWalker.visit(java.base@17.0.5/Unknown Source)
at java.nio.file.FileTreeWalker.next(java.base@17.0.5/Unknown Source)
at java.nio.file.Files.walkFileTree(java.base@17.0.5/Unknown Source)
at org.knime.filehandling.core.defaultnodesettings.filechooser.AbstractFileChooserPathAccessor.walkFileTree(AbstractFileChooserPathAccessor.java:269)
at org.knime.filehandling.core.defaultnodesettings.filechooser.AbstractFileChooserPathAccessor.getFSPaths(AbstractFileChooserPathAccessor.java:231)
at org.knime.filehandling.core.node.table.reader.preview.dialog.AbstractPathTableReaderNodeDialog$ReadPathAccessorAdapter.getItems(AbstractPathTableReaderNodeDialog.java:142)
at org.knime.filehandling.core.node.table.reader.preview.dialog.SourceGroupSwingWorker.doInBackgroundWithContext(SourceGroupSwingWorker.java:101)
at org.knime.filehandling.core.node.table.reader.preview.dialog.SourceGroupSwingWorker.doInBackgroundWithContext(SourceGroupSwingWorker.java:1)
at org.knime.core.util.SwingWorkerWithContext.doInBackground(SwingWorkerWithContext.java:106)
at javax.swing.SwingWorker$1.call(java.desktop@17.0.5/Unknown Source)
at java.util.concurrent.FutureTask.run(java.base@17.0.5/Unknown Source)
at javax.swing.SwingWorker.run(java.desktop@17.0.5/Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.5/Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.5/Unknown Source)
at java.lang.Thread.run(java.base@17.0.5/Unknown Source)
Locked ownable synchronizers:
- <0x00000007857d0198> (a java.util.concurrent.ThreadPoolExecutor$Worker)
After "Cancel"ing the dialog the SwingWorker immediately waits for new work:
"SwingWorker-pool-9-thread-6" #2317 daemon prio=5 os_prio=31 cpu=34082.93ms elapsed=383.17s tid=0x0000000134c31600 nid=0x2dc07 waiting on condition [0x00000003965ae000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@17.0.5/Native Method)
- parking to wait for <0x00000007857cff90> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(java.base@17.0.5/Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base@17.0.5/Unknown Source)
at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base@17.0.5/Unknown Source)
at java.util.concurrent.ForkJoinPool.managedBlock(java.base@17.0.5/Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@17.0.5/Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.take(java.base@17.0.5/Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.getTask(java.base@17.0.5/Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.5/Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.5/Unknown Source)
at java.lang.Thread.run(java.base@17.0.5/Unknown Source)
Locked ownable synchronizers:
- None
Can you see in the Process view of Task Manager that the KNIME process is indeed still responsible for the CPU load after you close the dialog?