Hi Jeremy,
Thanks for the insightful reply.
To cover your points (and fill in some info I should have provided):
- We use Ignite persistence
- We use the FSYNC Wal mode
- We do not use the FULL_SYNC cache write synchronization mode for our
REPLICATED caches (we use PRIMARY_SYNC). ... and
Do you do ConfigureAwait(False) in the code that does *ICache.PutAsync(), *or do you have some kind of handler to track whether
there were problems with any particular put operation?
https://ignite.apache.org/docs/latest/net-specific/net-async
Hi Jeremy,
My initial query was to see if this had been observed by others.
To answer some of your questions:
Do we specifically check that an element is added to all nodes
participating in a replicated cache: No, we do not (we take it on trust
Ignite sorts that out ;) )
Do we think it is a
I suspect a race condition with async mode caches. This is a naive guess
though, as we don't have enough details. I'll assume this is a plea for
help in troubleshooting methodology and the question is really "what should
we look at next?"
The real answer comes from tracing the insert of element E
>Hi,
Hi, this really looks like very strange
First of all you need to check consistency of your data : [1]
> Some time ago an element (E) was added to this cache (among many others)
And some time it will be all ok there ? Are you sure that this element was
properly touched ?
What king of
Hi,
We have been triaging an odd issue we encountered in a system using Ignite
v2.15 and the C# client.
We have a replicated cache across four nodes, lets call them P0, P1, P2 &
P3. Because the cache is replicated every item added to the cache is
present in each of P0, P1, P2 and P3.
Some time
