This page descibes hits for developing and researching failures of Apache Ignite tests
Ignite test has build in Framework to test compatibility. This framework provides an opportunity to start working with Ignite instances of previously released versions.
The entire module is built on top of the Ignite Testing Framework, especially on the MiltiJVM-mode classes. There is a class IgniteCompatibilityAbstractTest that provides methods to start Ignite nodes with versions which have been previously released in the Maven repository in separate JVM and allows them to join topology.
The framework is looking for artifacts of a specific version in the Maven local repository, and if they don’t exist there, they will be downloaded and stored via Maven.
The main implemented API:
You can specify a version of Ignite, which you want to start, define the configuration in the configurationClosure and set the actions on the started node in the postStartupClosure.
It’s straightforward to use it for writing unit tests, here is a simple example which demonstrates main functions.
This test checks that everything that is on the public API in the configuration, is there in the .NET, unless specified otherwise. Exceptions are:
If there is a public API, but it is not in the .NET class, or in the list of unnecessary, or in the list of known unsupported, then the test fails. This fix explicitly marks the property as yet unimplemented in class
there is String array MissingProperties. This array stores properties that are missing on .NET side. Adding property to this list disable Parity test fails, but it is reasonable to add properties only with corresponding issue creation first. Issue number can be added as comment
Since OptimizedMarshaller was removed in Ignite 2.0 from the PublicAPI, several unnecessary test suites were removed from the build plan from Ignite 2.0.
Please use for Ignite 2.0+ tests appropriate run configs from Ignite 2.0 project, which is 14 test suites shorter than the previous plan.
Use -> Run All to run all suites for changes. Select your PR in branch selection.
Usually it is clear from test suite naming to which run config it belongs.
But it is not clear where test is executed on teamcity it is posible to do the following.
Way 1: Using code
Way 2: Use search in top right corner in teamcity
Make sure to select 'Ignite 2.0 Tests' group if 2+ tests are required
To enable debug messages for test it is possible to set in
This XML contains commented out examples of enable debug for particular packages
For example for debugging Exchange messages following XML may be inserted test config:
Be careful with committing log with debug enabled, it may generate huge amount of messages at continious integration.
If relatively fast run configuration timed out
Check required time test was timed out (or timeout set on run configuration). If it is relatively low (e.g. 10 minutes) and other successful runs required 3-9 minutes consider timeout increase.
Check agent type - some windows agents works slower than linux.
Check thread dump, if build is still running (tests even not started), consider timeout increase.
If timeout is already high, e.g. 2h or more, timeout probably indicates problem in code. To find out reason
1) download full build log from TC (it is faster to download compressed build log).
2) search 'timed out' or 'Test has been timed out' to find out which test was failed
This line is logged at the end of test execution.
3) Search backwards 'Starting test'
This line is logged at the beginning of test execution.
Most likey there is some exception, assetion error between these 2 logged messages.
Also it is possible now to run test locally if hang up or not.
4) Thread dump analysis
After timed out tests there is also thread dump is logged. To find out abnormal activiy in this dump it is usefull to take into account following information
- pool type (included into pool name)
- node name (for test may include test name)
System execution pool, responsible for processing internal system messages.
See also message flow section from Ignite Tests How To
Waiting for task to exexute
Entry cleanup worker. Provides functionality of expiration for cache entries
Periodic sleep and wakeup
One thread per node. Partition maps exchange. Usage of one thread for exchange provides strict actions order.See also "Partition Map Exchange" section from Ignite Tests How To
|If there is no exchange waits on the quue|
|sys-stripe||See also 'Striped pool' section from Part 2|
Waiting on queue
Waiting on queue
|test-runner||Runs test itself|
Test method e.g .CacheAsyncOperationsFailoverAbstractTest.testPutAllAsyncFailover()
Waiting on queue
|main||Start up test runner thread and waits to complete within|
|ThreadImpl.dumpThreads0 - this thread checks timeout occurred and initializes thread dump|