Hello,
We, like many others, use Knime to run scheduled workflows at the same time which has never been a problem in 5.4 - this new update has completely broken our production reporting system and is a huge step back. We will move back to an old version of Knime but if this capability is being turned off, we will need to move to an alternative data solution programme that can support what we need.
We are experiencing the same problem, we get the below error:
A fatal error has been detected by the Java Runtime Environment:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff8653dac8f, pid=5172, tid=13952
JRE version: OpenJDK Runtime Environment Temurin-17.0.5+8 (17.0.5+8) (build 17.0.5+8)
Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (17.0.5+8, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
Problematic frame:
C [libcef.dll+0x468ac8f]
If we can’t run multiple at the same time through task scheduler then this is a considerable downgrade from 5.4 and we’ll need to find something else to use!
We also have this use case - running Knime workflows using batch executor - and faced the same issue with 5.5 with failures to start one workflow when another is still running. Workflows are scheduled to start at different times but it is not always possible to predict how long processing would take and some of them could overlap. Inability to execute multiple workflows via batch presents significant issue for us, at the moment we had downgraded back to 5.4 but would need to re-evaluate Knime usage.
Maybe it would be possible to introduce parameter for batch executor to override default behavior of not starting another workflow when one is running. Something like -concurrent=Y or alike. It is not a problem to run only one studio instance at a time but batch executor usage pattern is different and often includes running multiple workflows.
Hi @Sarah_rushton, hi @jmartinsonhr23,
as @leo_woerteler already remarked, it’s most likely due to the ‘embedded browser’ (CEF). We initialize CEF on start-up which helps to prevent problems when CEF is initialized on demand later and memory is tight. But you can turn that off by setting the system property -Dorg.knime.js.cef.skip_windowless_chromium_initialization=true. Maybe that helps as workaround (provided you don’t use view-image-generation or report-generation - which needs CEF and will initialize it when used)?
@hornm If my workflow used report-generation, how to fix this issue?
I used knime 5.5.1, batch executor can’t run reports.
I doubt there is much interest for Knime as a company in fixing the behavior that re-enables users to schedule multiple, nested or parallel executions, which is the one of the primary selling points of their for profit product.
Hi, Luis Alberto from Chile. Thanks for the upgrade! I just downloaded and installed it, everything is ok, but the zoom in and out using mouse and command is considerably slower than the last version; in big workflows it could impact a lot the speed of work significantly. Thanks again, KNIME is an important part of my work today, best app for data prototyping. (I’m on a MacBook Pro, so I think the resources are not the problem)
Thanks for the upgrade. Especially the current AI extensions are really useful.
What I’ve noticed is that the table view and Text View widgets truncate the strings now (due to some HTML definition, I believe). This wasn’t a limitation in 5.4. It would be great if these truncations could be fixed.
Thanks again for all your work. ![]()
After a few weeks working with the new versio, I can confirm, for the same big workflows in zoom in and out, there are huge diference in performance comparing this version with the old one.
L