Hi Surinder,
We have native persistence enabled, so I guess eviction policies should not
come into the picture.
Cache configuration is as follows:
Atomicity: Transactional
CacheMode: Replicated
Rebalance mode: sync
The cache entries are removed using cache APIs : remove and/or removeAll.
This re
Do you manually remove that entry from cache or using eviction/expiration
policy.
Can you share cache configuration please.
This thread might help you(comments)
https://stackoverflow.com/questions/48951091/ignite-how-eviction-expiry-and-rebalancing-work-with-external-cachestore
On Tue, Feb 22,
Hi,
We are using ignite 2.12 with persistence enabled along with full sync -
replicated mode.
There is a cache whose data ranges from few Kilobytes to few Megabytes.
Once a particular cache entry is worked upon, we remove that entry from
cache. The cache goes through a large number of reads/writes
Hi Rafael,
I investigated your issue. I'm sorry, It's actually a bug, it's impossible
to use client nodes for running geospatial indexes in 2.12. It should be
fixed, and it will be a part of future release 2.13. Thank you for finding
that!
But, it is still possible to use server nodes or thin cli
Hi,
Yes, it looks strange. Could you please share your DDLs and queries that
led to the exception? We can add a compatibility test and it will help us
to investigate the issue.
Maksim
On Tue, Feb 15, 2022 at 3:28 PM John Smith wrote:
> It's weird. I dropped the table and recreated it without r
Hi Marcus,
> The package com.h2database:h2 from 1.4.198 and before 2.0.202 are
vulnerable to XML
Ignite uses version 1.4.197, so Ignite isn't impacted by this CVE.
Maksim
On Mon, Feb 21, 2022 at 10:16 AM Lo, Marcus wrote:
> Hi,
>
>
>
> Is Ignite impacted by h2 vulnerability CVE-2021-23463? T
