Re: [External]Re: Client taking long time to connect to cluster

2021-09-02 Thread Yohan Fernando
onnect. > > > > *Thanks and Regards,* > > *Kamlesh Joshi* > > > > *From:* Yohan Fernando > *Sent:* 02 September 2021 15:00 > *To:* user@ignite.apache.org > *Subject:* Re: [External]Re: Client taking long time to connect to cluster > > > > The e-mail below is

Re: [External]Re: Client taking long time to connect to cluster

2021-09-02 Thread Yohan Fernando
Kamlesh Joshi wrote: > Hi Yohan, > > > > We have already added this but not as a JVM param but via a code, like > setting in system properties. Still the issue persists. > > > > Any other work around? > > > > *Thanks and Regards,* > > *Kamlesh Jos

Re: Client taking long time to connect to cluster

2021-09-02 Thread Yohan Fernando
We had a similar problem. Try adding -Djava.net.preferIPv4Stack=true to the VM parameters. On Wed, Sep 1, 2021 at 3:22 PM Kamlesh Joshi wrote: > Hi Igniters, > > > > We have upgraded OS version from Red Hat 6.10(Santiago) to 7.8(Maipo) in > Client server. Ignite cluster nodes’ OS are already on

RE: Change in CacheStore Serialization from 2.7.6 to 2.8.x breaks Spring Injected dataSource

2020-07-23 Thread Yohan Fernando
I managed to resolve this by using the @SpringResource annotation like below (this was not required in Ignite 2.7.6), @SpringResource(resourceName = "dataSource") transient DataSource dataSource; Thanks Yohan From: Yohan Fernando Sent: 22 July 2020 17:14 To: 'user@ignite.apache.org

RE: Change in CacheStore Serialization from 2.7.6 to 2.8.x breaks Spring Injected dataSource

2020-07-22 Thread Yohan Fernando
.loadCache(GridCacheStoreManagerAdapter.java:519) ... 27 more Please let me know if you have any questions. Thanks Yohan From: Yohan Fernando Sent: 21 July 2020 16:13 To: 'user@ignite.apache.org' Subject: Change in CacheStore Serialization from 2.7.6 to 2.8.x breaks Spring Injected dataSource Hell

Change in CacheStore Serialization from 2.7.6 to 2.8.x breaks Spring Injected dataSource

2020-07-21 Thread Yohan Fernando
Hello All, We are migrating from Ignite 2.7.6 to 2.8.1 and have hit an issue where CacheStore implementations that include Spring injected DataSource objects, these datasources turn out to be null. After investigation, it appears that there is a change in behaviour under Ignite 2.8.x where it

RE: Does IgniteCache.containsKey lock the key in a Transaction?

2019-08-19 Thread Yohan Fernando
e lock lock.unlock(); } Regards, Nattapon On Fri, Aug 16, 2019 at 5:23 PM Yohan Fernando mailto:yohan.ferna...@tudor.com>> wrote: Hi All, Does IgniteCache.containsKey() lock the key in a Transaction similar to IgniteCache.get() ? Basically I want a lightweight call to lock the key witho

Does IgniteCache.containsKey lock the key in a Transaction?

2019-08-16 Thread Yohan Fernando
Hi All, Does IgniteCache.containsKey() lock the key in a Transaction similar to IgniteCache.get() ? Basically I want a lightweight call to lock the key without having to Serialize objects from each node within a Transaction. _ This

RE: IgniteCache.lock behaviour on a key that doesn't exist in the cache (yet)

2019-08-07 Thread Yohan Fernando
during current prepare the default then you will get that value, otherwise default value will be returned. BR, Andrei 8/7/2019 12:08 PM, Yohan Fernando пишет: I'm trying to write a transaction-safe way of performing a lazy load of an object from the database if it doesnt exist. However as Ignit

IgniteCache.lock behaviour on a key that doesn't exist in the cache (yet)

2019-08-07 Thread Yohan Fernando
I'm trying to write a transaction-safe way of performing a lazy load of an object from the database if it doesnt exist. However as IgniteCache doesn't have the equivalent of HashMap.computeIfAbsent, I'm trying to use the IgniteCache.lock method to achieve this. The question is whether

Affinity on non-key field

2019-07-30 Thread Yohan Fernando
If you have a cache where you have the key as ObjectKey and value as ObjectValue, and the classes are like the following, is it possible in Ignite to have data co-location based on a non-key attribute? In this case on the private int c field in ObjectValue? I believe @AffinityKeyMapped