Troubleshooting

Using Console

Ignite produces console output (stdout): information, metrics, warnings, error details. If your app does not open console, you may redirect the console output to a string or a file:

var sw = new StringWriter();
Console.SetOut(sw);

// Examine output:
sw.ToString();

Getting More Insights On Exceptions

When getting an IgniteException, always make sure to examine the InnerException property: it often contains more details on the error. You can do that in Visual Studio debugger or by calling ToString() on the exception object:

try {
    IQueryCursor<List> cursor = cache.QueryFields(query);  
}
catch (IgniteException e) {
    // Printing out the whole exception meesage.
    Console.WriteLine(e.ToString());
}

Failed to load jvm.dll

Make sure that Java Development Kit is installed, and JAVA_HOME variable is set and points to JDK installation dir. The latest JDK can be found here: http://www.oracle.com/technetwork/java/javase/downloads/index.html

errorCode=193 is ERROR_BAD_EXE_FORMAT, which is often caused by x64/x86 mismatch. Make sure that installed JDK and your application have the same x64/x86 platform target. Ignite detects proper JDK automatically when JAVA_HOME is not set, so if you have x86 AND x64 JDK installed, it will work in any mode.

126 ERROR_MOD_NOT_FOUND can occur due to missing dependencies:

• JDK 8 requires Microsoft Visual C++ 2010 Redistributable Package
• Later JDK versions require Microsoft Visual C++ 2015 Redistributable Package or newer

Java class is not found

Check your IGNITE_HOME environment variable, IgniteConfiguration.IgniteHome and IgniteConfiguration.JvmClasspath properties. Refer to Deployment section for more details. ASP.NET/IIS scenarios require additional steps.

Freeze on Ignition.Start

Examine console output.

Most often this is caused by topology join failure:

• Discovery settings are incorrect (see Cluster Configuration)
• ClientMode is true, but there are no servers (see Clients and Servers)

Failed to start manager : GridManagerAdapter

Examine console output.

Most often this is caused by invalid or incompatible configuration:

• Some configuration property has an invalid value (out of range and the like).
• Some configuration property is incompatible with a value in other cluster nodes. In particular, BinaryConfiguration properties, such as CompactFooter, IdMapper, and NameMapper should be the same on all nodes.

The latter problem often arises when building a mixed cluster (Java + .NET nodes), because default configuration on these platforms is different. .NET only supports BinaryBasicIdMapper and BinaryBasicNameMapper. Java configuration has to be fixed the following way to enable .NET nodes connectivity:

<property name="binaryConfiguration">
    <bean class="org.apache.ignite.configuration.BinaryConfiguration">
        <property name="compactFooter" value="true"/>
        <property name="idMapper">
            <bean class="org.apache.ignite.binary.BinaryBasicIdMapper">
                <constructor-arg value="true"/>
            </bean>
        </property>
        <property name="nameMapper">
            <bean class="org.apache.ignite.binary.BinaryBasicNameMapper">
                <constructor-arg value="true"/>
            </bean>
        </property>
    </bean>
</property>

Could not load file or assembly 'MyAssembly' or one of its dependencies. The system cannot find the file specified.

This exception can occur due to missing assemblies on remote nodes. See Standalone Nodes: Loading User Assemblies

stack smashing detected : dotnet terminated

This happens on Linux with .NET Core when NullReferenceException occurs in user code. The reason is that both .NET and Java use SIGSEGV to handle certain exceptions, including NullPointerException and NullReferenceException, and when JVM runs in the same process as .NET, it overrides that handler, breaking .NET exception handling (see 1, 2).

The fix for that exists in .NET Core 3.0 (#25972: set COMPlus_EnableAlternateStackCheck environment variable to 1.