This code seems odd to me. It shouldn't matter if you're truly using
FULL_SYNC, but this might invoke some corner case code path(s).
First we set the cache mode to partitioned, then we make the number of
backup partitions equal to running the cache in replicated mode. This makes
me very suspicious of finding other very idiosyncratic implementation
details that can make a system brittle. Why isn't this a replicated cache?
Why so many backups? Is the topology unstable?
cg.CacheMode = CacheMode.Partitioned;
if (nodeCount > 1)
{
cg.Backups = nodeCount - 1;
}
On Fri, Jan 24, 2025 at 3:36 AM Charlin S <charli...@hotelhub.com> wrote:
> Hi All,
> TTL is defined at cache level and cache definition and configuration are
> CacheConfiguration cg = null;
> int nodeCount = IgniteInstanceDetail.IIgniteInstance.GetCluster().
> ForServers().GetNodes().Count();
> if (nodeCount == 0)
> {
> // If the node count is 0 then it will return from here itself.
> Exception custom = new Exception("Nodes are not available,Please
> check Ignite cluster." );
> return;
> }
>
> cg = new CacheConfiguration(cacheName, new QueryEntity(typeof(string),
> typeofclass));
> cg.CopyOnRead = false;
> cg.EagerTtl = true;
> cg.CacheMode = CacheMode.Partitioned;
> if (nodeCount > 1)
> {
> cg.Backups = nodeCount - 1;
> }
>
> var cache = Ignite.GetOrCreateCache<string, object>(cg)
> .WithExpiryPolicy(new ExpiryPolicy(
> TimeSpan.FromMinutes(60),
> TimeSpan.FromMinutes(60),
> TimeSpan.FromMinutes(60)
> ));
>
> Cache configuration
> QueryParallelism 1
> ReadFromBackup True
> ReadThrough False
> RebalanceBatchesPrefetchCount 3
> RebalanceBatchSize 524288
> RebalanceDelay 00:00:00
> RebalanceMode Async
> RebalanceOrder 0
> RebalanceThrottle 00:00:00
> RebalanceTimeout 00:00:10
> SqlEscapeAll False
> SqlIndexMaxInlineSize -1
> SqlSchema null
> StoreConcurrentLoadAllThreshold 5
> WriteBehindBatchSize 512
> WriteBehindCoalescing True
> WriteBehindEnabled False
> WriteBehindFlushFrequency 00:00:05
> WriteBehindFlushSize 10240
> WriteBehindFlushThreadCount 1
> WriteSynchronizationMode PrimarySync
> WriteThrough False Thanks,
> Charlin
>
>
> On Fri, 24 Jan 2025 at 14:50, Stephen Darlington <sdarling...@apache.org>
> wrote:
>
>> Please also share your cache configuration. TTL is defined at the cache
>> level.
>>
>> On Fri, 24 Jan 2025 at 06:55, Charlin S <charli...@hotelhub.com> wrote:
>>
>>> Hi All,
>>> I am trying for full_sync mode meanwhile I am having doubts on TTL.
>>> TTL expires time is still longer. for me data not found happening in a
>>> minute also. still I am not sure whether expiring data immediately or
>>> reading is happening from another node.
>>> My data region size 18GB and Java process for the grid used 14.0GB. is
>>> causing TTL expiry policy earlier.
>>> My data region configuration :-
>>> <property name="dataStorageConfiguration">
>>> <bean
>>> class="org.apache.ignite.configuration.DataStorageConfiguration">
>>> <property name="defaultDataRegionConfiguration">
>>> <bean
>>> class="org.apache.ignite.configuration.DataRegionConfiguration">
>>> <property name="name"
>>> value="Common_Dynamic_Data_Region"/>
>>> <property name="initialSize" value="#{1L * 1024
>>> * 1024 * 1024}"/>
>>> <property name="maxSize" value="#{18L * 1024 *
>>> 1024 * 1024}"/>
>>> <property name="pageEvictionMode"
>>> value="RANDOM_2_LRU"/>
>>> <property name="evictionThreshold" value="0.7"/>
>>> <property name="emptyPagesPoolSize"
>>> value="65536"/>
>>> </bean>
>>> </property>
>>> </bean>
>>> </property>
>>>
>>> Thanks
>>> Charlin
>>>
>>>
>>> On Thu, 23 Jan 2025 at 21:10, Jeremy McMillan <j...@gridgain.com> wrote:
>>>
>>>> Does your app logic have a race condition between read activity and TTL
>>>> expiry policy?
>>>>
>>>> 1. start an operation reading an object from the cache just prior
>>>> to TTL expiration, successfully read
>>>> 2. TTL expires, next read operation will not find that key
>>>> 3. subsequent update of the object from the cache just after TTL
>>>> expiration fails because the key is not found
>>>>
>>>>
>>>> On Wed, Jan 22, 2025 at 6:09 AM Charlin S <charli...@hotelhub.com>
>>>> wrote:
>>>>
>>>>> Hi Pavel,
>>>>> We are not changing mode explicitly so its Default value is
>>>>> PRIMARY_SYNC
>>>>> <https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheWriteSynchronizationMode.html#PRIMARY_SYNC>
>>>>> only.
>>>>>
>>>>> Thanks
>>>>> Charlin
>>>>>
>>>>>
>>>>> On Wed, 22 Jan 2025 at 17:29, Pavel Tupitsyn <ptupit...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Which CacheWriteSynchronizationMode [1] do you use?
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheWriteSynchronizationMode.html
>>>>>>
>>>>>> On Wed, Jan 22, 2025 at 1:55 PM Charlin S <charli...@hotelhub.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Pavel,
>>>>>>>
>>>>>>> Data read and write happening from different client nodes.
>>>>>>> Scenario:-
>>>>>>> 1. Insert into cache
>>>>>>> 2. Landing on the second page ( reading cache data - some time
>>>>>>> failing)
>>>>>>> 3. Landing on the third page (reading cache again - some time
>>>>>>> failing)
>>>>>>>
>>>>>>> Web tier(2 web server) calls app tier(3 servers) for cache operation
>>>>>>> and app tier connected to Ignite using tick client
>>>>>>> Data insertion happening from one client node and reading happening
>>>>>>> from another client node.I am not sure if this intermittent failure
>>>>>>> happening when its reading from another client node.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Charlin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 22 Jan 2025 at 17:11, Pavel Tupitsyn <ptupit...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Do you have an exact measurement? Could it be some race condition?
>>>>>>>> Do you read from the same node/client as write?
>>>>>>>>
>>>>>>>> On Wed, Jan 22, 2025 at 12:31 PM Charlin S <charli...@hotelhub.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Pavel,
>>>>>>>>> I am expecting data since read is happening soon after insert.
>>>>>>>>> Data expiry will happen after 1 hour. So my expectation data should be
>>>>>>>>> present.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Charlin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, 22 Jan 2025 at 13:48, Pavel Tupitsyn <ptupit...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> What is the difference between expected and actual expiry time?
>>>>>>>>>>
>>>>>>>>>> On Wed, Jan 22, 2025 at 8:54 AM Charlin S <charli...@hotelhub.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Pavel,
>>>>>>>>>>> This is happening only at production environment and data
>>>>>>>>>>> keynotfound exception before triggering expiry policy (expiry
>>>>>>>>>>> policy time
>>>>>>>>>>> still longer)
>>>>>>>>>>>
>>>>>>>>>>> Following configuration part of xml bean file for communication.
>>>>>>>>>>> Is there any issue in that please let me know.
>>>>>>>>>>> <property name="communicationSpi">
>>>>>>>>>>> <bean
>>>>>>>>>>> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>>>>>>>>>>> <property name="sharedMemoryPort" value="-1"/>
>>>>>>>>>>> <property name="localPort" value="57605"/>
>>>>>>>>>>> </bean>
>>>>>>>>>>> </property>
>>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>> Charlin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, 21 Jan 2025 at 12:49, Pavel Tupitsyn <
>>>>>>>>>>> ptupit...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi, please provide more details.
>>>>>>>>>>>>
>>>>>>>>>>>> - Do you have a reproducer?
>>>>>>>>>>>> - Do you mean that expiry policy triggers sooner than expected?
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jan 21, 2025 at 9:14 AM Charlin S <
>>>>>>>>>>>> charli...@hotelhub.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>> I am getting below error while reading data by key but data
>>>>>>>>>>>>> presents cache as expiry policy time not reached.
>>>>>>>>>>>>> Cache mode: Partition
>>>>>>>>>>>>> Number Server Node: 2
>>>>>>>>>>>>> Number client Node : 8
>>>>>>>>>>>>> The given key was not present in the cache:
>>>>>>>>>>>>> Test|2711e8b9-7411-41bc-938c-d3d4ae9722ce@$@System.Collections.Generic.KeyNotFoundException:
>>>>>>>>>>>>> The given key was not present in the cache:
>>>>>>>>>>>>> Test|2711e8b9-7411-41bc-938c-d3d4ae9722ce
>>>>>>>>>>>>> at
>>>>>>>>>>>>> Apache.Ignite.Core.Impl.Cache.CacheImpl`2.<>c__DisplayClass49_0.<Get>b__1(IBinaryStream
>>>>>>>>>>>>> stream, Int64 res)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutLong[TR](Int32
>>>>>>>>>>>>> type,
>>>>>>>>>>>>> Func`2 outAction, Func`3 inAction, Func`2 readErrorAction)
>>>>>>>>>>>>> at Apache.Ignite.Core.Impl.Cache.CacheImpl`2.Get(TK key)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>> Charlin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
