Glad you got to the bottom of it!
On Sat, 24 Feb 2024 at 00:19, Aleksej Avrutin wrote:
> Stephen,
>
> Thank you for the message. At last, I've found the root cause of the
> issue. It was an application bug (expected) but it wasn't the most apparent
> one. Out of despair I decided to check all th
Stephen,
Thank you for the message. At last, I've found the root cause of the issue.
It was an application bug (expected) but it wasn't the most apparent one.
Out of despair I decided to check all the components of the application
including Ignite. The good thing is that now I have better knowledg
Is there a pattern to the lost records? Is it old records? Records for a
particular customer? Records stored on a specific node or partition?
On Thu, 22 Feb 2024 at 21:14, Aleksej Avrutin wrote:
> Jeremy,
>
> Thank you for the response. I reviewed cache properties using GG Control
> Center and t
Jeremy,
Thank you for the response. I reviewed cache properties using GG Control
Center and there was nothing in the cache props that would lead me to the
conclusion that any expiry policy/TTL is set up for the cache. It wasn't
set on the operation level, either.
I decided to delete the cache ent
First, logging should be configured to at least WARN level if not INFO.
Ignite manages data internally at the page level. If you see errors about
pages, it is low, low level ignite problems. The next level up is
partitions. Errors involving partitions are mid low level ignite problems.
The next le
Hello,
A couple of days ago I encountered a strange phenomenon in our application
based on Apache Ignite .Net 2.14 with persistence (3 nodes, 1 backup per
cache).
Data in a cache started disappearing for seemingly no reason and the amount
of records could be halved (220K to 108K) overnight. I spen