Hello Amit,
There are the plans to make the cluster to heal itself by kicking off unstable
nodes or unblocking pending transactions if an abnormal situation happens:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-5+Cluster+reaction+if+node+detects+an+extraordinary+situations
Created a
Hello!
My recommendation here is to always leave some extra RAM and heap so that a
hot spot won't cause OOM. Maybe use less RAM-intensive algorithms.
Without stack traces and logs it's hard to say more, but OOM may not be a
recoverable error with Ignite.
Regards,
--
Ilya Kasnacheev
Hi Ilya,
Thanks for the response.
I have been following the release notes for every release - 2.1/2.2/2.3. I
haven't seen any fixes around this (or similar sounding) issue. Since I am
using Ignite is a very critical application, I would like to use a stable
version which meets my requirements. I
Hello!
I would recommend using 2.2 or 2.3 and not 2.0.
Having said that, it makes sense to avoid OOM because in many places
behavior is undefined once you hit OOM. It should not be hard to avoid.
It should not cause cluster to hang, but without logs from server nodes it's
hard to understand
Hi,
I am using Ignite 2.0. I have observed that if there is an out of memory
error on any Ignite client node, the complete cluster becomes unresponsive.
A few details about my caches/operations -
1. Atomicity mode - Transactional
2. Locking - Pessimistic with repeatable read.
Is this expected
