📣 Out now: KNIME Analytics Platform 5.5

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)?

5 Likes