Can you put together some shareable configuration/code/data that reproduces
this issue in something like a GitHub gist and post that for the community
to work on? That would be a good candidate for an Ignite GitHub issue
ticket.

On Mon, Feb 3, 2025 at 4:25 AM Charlin S <charli...@hotelhub.com> wrote:

> Hi All,
> Thank you for your response.
> I am able to reproduce the same issue with *fullsync *mode. so I am
> suspecting this issue due to following steps under load.
> 1. Insert (success)
> 2. Read (success)
> 3. Update (success)
> 4. Read (Failed)
>
> Please suggest this to me.
>
> Tanks & Regards,
> Charlin
>
>
>
>
> On Wed, 29 Jan 2025 at 01:00, Jeremy McMillan <j...@gridgain.com> wrote:
>
>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>

Reply via email to