it is really hard to tell what the problem is, without having the workflow. Would it be possible to provide it to us?
It would be also helpful to have the KNIME logfile which is stored in your KNIME workspace under .metadata/knime/knime.log
I had a look at your workflow and unfortunately it is corrupted. The file that contains the basic metadata such as the nodes, which are used in the workflows, and their connections is broken (if you’d unpack your workflow you’d see that the file ‘workflow.knime’ cannot be read like an xml file as it should be).
Thanks for drawing the connection @iiiaaa. The workflow that @lucian.cristian posted further up is corrupted. One of the files (workflow.knime) is complete binary garbage but really should be well formed xml. We can’t currently explain why that is, nor can we reproduce it.
Do you guys claim that this only happens with the latest version of KNIME (3.5.3)? Have you seen a similar behavior with a previous version? Can you also confirm that you all run Windows? The only one change that could possibly explain the behavior is the change to the KNIME “Logger” (the code that fills the knime.log file):
AP-8981: Excessive runtime on Windows OS while executing KNIME workflows when “Windows Defender” is turned on (see changelog)
We still can’t explain why that is so if you have any recipe how to reproduce the problem that would be highly appreciated!!! We are going to try really massive workflows next (large in the sense of many many nodes).
I tried it with the latest build (which includes that change) and had a larger workflow (2000+ nodes) with all nodes doing concurrent execution and I/O but no problem encountered.
I noticed the log file attached in the other thread shows heavy I/O concurrency (many nodes and then KNIME runs low on main memory and starts swapping all in-memory data to disc) – hence the theory that this is related to Windows Defender and our changes around that.
I am giving up here. Please let us know if you can reproduce it or give more details.
I am not able to reproduce the problem. But I can tell you that
it never happened with previous versions of Knime
it happened with Knime 3.5.2 on a local computer with a very small workflow (few nodes) that read multiple files looping and concatenate them in one file. The node “List files” and the “Excel Reader” disappeared suddenly opening the workflow.
it happened with Knime 3.5.3 on a Virtual Machine on a large workflow (the one I attached in the other thread)
Thanks for the details. It’s good to know that this also occurred in 3.5.2 (at least once). Then we can say for certain that it isn’t a problem we invented with the Windows Defender fix I mentioned above. It doesn’t make it easier, though.
In any case it’d be very helpful if we can get a the log file of the writing process. Both your log file and the one that Lucian attached above only contain log information for the time that the workflow is loaded. And that’s too late – it just tells you that the workflow is corrupt.
I get these errors when loading a textmining (07_Sentiment) from the knime server: all the text mining nodes are not there. After the error, a dialog appears if I would like to download the textmining extension, but clicking on next doesn’t do anything.
I also had this error with two of my own workflows. Only an export, deleting workspace, reinstall knime and import was a solution that worked.
This is probably not related to the problem described above. In your case the installation is broken and extensions are not correctly discovered. It seems the workflow itself is intact (otherwise you would get other error messages during workflow load). Can you post this as a new topic?
It’s the same log file (knime.log) but the log file gets overwritten if its size exceeds ~10MB. It’s then moved to “knime.log.gz” (and any previous file gets overwritten). You can change the default size by adding this line to the end of your knime.ini (e.g. to 100MB):