I am attempting to start ignite3 in embedded mode based off the instructions:
https://ignite.apache.org/docs/ignite3/latest/quick-start/embedded-mode
At runtime we are facing issue, where DotNetComputeExecutor.java is not able to resolve DotNetBinaryDir below is the stacktrace of the error
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NullPointerException [in thread "main"] at org.apache.ignite.internal.compute.executor.platform.dotnet.DotNetComputeExecutor.resolveDotNetBinaryDir(DotNetComputeExecutor.java:350) at org.apache.ignite.internal.compute.executor.platform.dotnet.DotNetComputeExecutor.resolveDotNetBinaryPath(DotNetComputeExecutor.java:340) at org.apache.ignite.internal.compute.executor.platform.dotnet.DotNetComputeExecutor.<clinit>(DotNetComputeExecutor.java:59) at org.apache.ignite.internal.compute.executor.ComputeExecutorImpl.setPlatformComputeTransport(ComputeExecutorImpl.java:111) at org.apache.ignite.internal.app.IgniteImpl.<init>(IgniteImpl.java:1312) at org.apache.ignite.internal.app.IgniteServerImpl.doStartAsync(IgniteServerImpl.java:392) at org.apache.ignite.internal.util.StripedVersatileReadWriteLock.lambda$inWriteLockAsync$2(StripedVersatileReadWriteLock.java:207)
Specifications:
- Java 21 compile and runtime
- Ignite v3.1.0
- Linux 4.18.0-305.3.1.el8_4.x86_64
Gridgain confirm that there is an issue with identifying the dotnet path. Unfortunately, there is no way to configure said path.
As a workaround, following the instructions were shared:
If embedding inside a Spring Boot app is required, change the packaging so Ignite jars are not in BOOT-INF/lib:
-
Build as a plain jar with a Class-Path manifest entry pointing at an external lib/ directory containing the Ignite jars and a sibling dotnet/ directory; or
-
Use spring-boot-maven-plugin with ZIP + PropertiesLauncher and loader.path pointing at extracted external libraries.
Gridgain filed a ticket with their engineering team, But also mentioned that the fix will be delivered in Gridgain9, not in Apache Ignite 3 since they don’t control AI release process.
Can we have a timeline for the fix in Apache Ignite 3 ?
Additional interesting fact, that startup succeed just by the presence of directory, it doesnt care if dotnet binary exist or not.
We are still in process of running tests to verify further impact on the functionality.
I am attempting to start ignite3 in embedded mode based off the instructions:
https://ignite.apache.org/docs/ignite3/latest/quick-start/embedded-mode
At runtime we are facing issue, where DotNetComputeExecutor.java is not able to resolve DotNetBinaryDir below is the stacktrace of the error
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NullPointerException [in thread "main"] at org.apache.ignite.internal.compute.executor.platform.dotnet.DotNetComputeExecutor.resolveDotNetBinaryDir(DotNetComputeExecutor.java:350) at org.apache.ignite.internal.compute.executor.platform.dotnet.DotNetComputeExecutor.resolveDotNetBinaryPath(DotNetComputeExecutor.java:340) at org.apache.ignite.internal.compute.executor.platform.dotnet.DotNetComputeExecutor.<clinit>(DotNetComputeExecutor.java:59) at org.apache.ignite.internal.compute.executor.ComputeExecutorImpl.setPlatformComputeTransport(ComputeExecutorImpl.java:111) at org.apache.ignite.internal.app.IgniteImpl.<init>(IgniteImpl.java:1312) at org.apache.ignite.internal.app.IgniteServerImpl.doStartAsync(IgniteServerImpl.java:392) at org.apache.ignite.internal.util.StripedVersatileReadWriteLock.lambda$inWriteLockAsync$2(StripedVersatileReadWriteLock.java:207)Specifications:
Gridgain confirm that there is an issue with identifying the dotnet path. Unfortunately, there is no way to configure said path.
As a workaround, following the instructions were shared:
If embedding inside a Spring Boot app is required, change the packaging so Ignite jars are not in BOOT-INF/lib:
Build as a plain jar with a Class-Path manifest entry pointing at an external lib/ directory containing the Ignite jars and a sibling dotnet/ directory; or
Use spring-boot-maven-plugin with ZIP + PropertiesLauncher and loader.path pointing at extracted external libraries.
Gridgain filed a ticket with their engineering team, But also mentioned that the fix will be delivered in Gridgain9, not in Apache Ignite 3 since they don’t control AI release process.
Can we have a timeline for the fix in Apache Ignite 3 ?
Additional interesting fact, that startup succeed just by the presence of directory, it doesnt care if dotnet binary exist or not.
We are still in process of running tests to verify further impact on the functionality.