Does ignite provide any method to check if one specified key is locked globaly (in another VM)?
Currently, there is no out-of-the-box way to do such a check, but you can send a closure to the primary node for the given key and check if it's locked there.
Locally this check can be done via IgniteCache#isLocalLocked() method.
On how to send a closure to primary node see this: https://apacheignite.readme.io/docs/affinity-collocation#collocating-compute-with-data
Related
I have apache geode as inline cache where it is connected to postgres as datasource. Since for getting all keys at once when getall method id invoked from region It calls CacheLoader Sequentially. Is there a way so that i can get all keys and call my datasource at once such as calling in query from Cacheloader.
I don't there's a way of accomplishing this out of the box using a CacheLoader since, as you already verified, the callback is invoked sequentially on every key not found within the Region. You might be able to pre-populate the Region with all those keys you know must be there, though, but keys not found while executing Region.getAll() will still be retrieved sequentially by invoking the configured CacheLoader.
Using Ignite 2.6.0
What I would like to do: Use a class method to compute affinity key value for a cache. In other words for IgniteCache<Key, Value> I want to use Key::someMethod to compute the affinity key.
The default GridCacheDefaultAffinityKeyMapper class does not seem to support using class methods.
So I thought of using CacheConfiguration::setAffinityMapper(AffinityKeyMapper) with a custom class implementing AffinityKeyMapper. But AffinityKeyMapper is marked as deprecated.
If I am understanding things correctly, my two choices are
1. Compute the required affinity at object construction time and use AffinityKeyMapped
2. Ignore the deprecation warning and use CacheConfiguration::setAffinityMapper(AffinityKeyMapper)
Which of these is the right way, or is there a third way?
Ignite stores data in binary format and do not deserialize objects on server side unless you ask explicitly about this in the code (for example, if you run a compute job and get something from a cache). As a matter of fact, in general case there are no key/value classes at all on server nodes, therefore there is no way to invoke a method or use AffinityKeyMapper. That's why it's deprecated.
I would recommend to predefine the affinity key value when you create the key object (i.e. go with option #1).
Using Geode 1.2 and 9.1 Pivotal native client the following code:
IRegion<string, IPdxInstance> r = cache.GetRegion<string, IPdxInstance>("myRegion");
return r[key];
then triggers an AfterCreate event for myRegion. Why does that happen when no data is created, only read?
Same here, never used Native Client. I agreed with what #Urizen suspected - you are calling r[key] from an instance of Geode that doesn't have the entry, so it pulls the data from other instance, which "create" the entry locally.
You have a few options here:
Performing an interest registration for the instance you are initiating the call using registerAllKeys() (doc here). There is a catch here: (might not be applicable for native client), in Java API, you have an option to register interest with an InterestResultPolicy. If you use KEYS_VALUES, you will load all data to local from remote on startup WITHOUT triggering afterCreate callback. If you choose KEYS only or NONE, you will likely have similar problem.
You can check for boolean flag remoteOrigin in EntryEvent. If it is false, it is purely local. In a non-WAN setup, this should be enough to distinguish your local operation from remotely initiated operation (be it a cache syncing or a genuine creation initiated by other cache). Vaguely remembering WAN works a bit different here.
I've never used the Native Client but, at a first glance, it should be expected for the afterCreate event to be invoked on the client side as the entry is actually being created on the local cache. What I mean is that the entry might exists on the server but, internally, the client needs to retrieve it from the server, and then create it locally (thus invoking the afterCreate for the locally installed CacheListener). Makes sense?.
1.Which category of CAP theoram does ignite fall under ?
2.While doing a loadCache using a client on multiple Servers , after the loadCache being called if the client goes down, will the operation complete on the Servers ?(Unable to try it due to some permission restriction)
Ignite guarantees data consistency. In case of cluster is segmented into two parts, they can't be merged back. One of the parts has to be considered invalid and restarted.
Most likely data will not be fully loaded in this case. The loading process should be restarted.
For the first question: the enum of CacheAtomicityMode has two values
TRANSACTIONAL: if you configure this in you CacheConfigure, then your application is CP
ATOMIC: if you configure this in you CacheConfigure, then your application is AP, and ATOMIC is the default value.
For the second question: if your client is embeddedwith your application，locaCache failed for some reason, then CacheLoaderException will be throw. If you want to custome CacheStore，you can extend CacheStoreAdapter and override method.
What is the proper way of connecting to mulitple servers/acceptors using quickfix?
Create a thread for each session under the fix application
Create a seperate application for each session, create multiple initiators, start each initiator in a seperate thread
And another related issue -
How does MultiThreadedInitiator class fits in...?
Quickfix already allows multiple sessions. They just have to be defined in your configuration file. From then on you can track messages using SessionID.
I think MultiThreadedInitiator ensures each session is created in a different thread.