Ignite Affinity Latency

Hi, We are seeing higher latency form ignite affinity (single key)/compute (multiple keys) of 7ms compared to get/getall 700 microseconds. Is this as expected? Our implementation is based on the below examples:

Failed to parse query: exception with Scala

Ignite version: 2.1 - I get the below exception when trying to query the shared pair rdd using sql. Exception : class javax.cache.CacheException Message : class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse query: select _key, _val from String

Ignite Affinity Latency

Hi, We are seeing higher latency form ignite affinity (single key)/compute (multiple keys) of 7ms compared to get/getall 700 microseconds. Is this as expected? Our implementation is based on the below examples:

Question on On-Heap Caching

Hi All, We enabled on-heap caching for our application, as per documentation. The only change required is to set OnheapCacheEnabled property of CacheConfiguration. Once we made this change, and started up our application, ignite metrics still shows onheap and offheap memory. Note: we are using

Re: Deserialization error with Ignite 2.3.0

Thanks Val. BTW: It would be pretty easy to write a unit test for this. 1) Create an Instance (A) of a class that contains an ImmutableList foo; 2) Create a cache of these 3) Using the BinaryMarshaler -- put(A), then get(A) 4) Walk the items in foo. (I will not blow up unless you access elements

Re: split-brain problem and GridSegmentationProcessor

we are just in the works of using a separate zk cluster to provide an implementation for segmentation resolution. If anyone else is working on it we could collaborate. or create a separate jira for a design review? what do you guys think? i think we could also make zk itself pluggable -Ani On

Re: Deserialization error with Ignite 2.3.0

*cross-posting to dev* Hi Chris, This is a regression due to this fix: https://issues.apache.org/jira/browse/IGNITE-6485. For some reason, since 2.3 it is looking for readResolve/writeReplace methods only in exact class that is being serialized, but not in the whole hierarchy. *Andrey G*, since

Re: write behind performance impacting main thread. Write behind buffer is never full

Alexey, I dug into this a bit more and it is the perfect storm of the way the write behind works and the way we are using one of our Caches. We need to keep our kafka offsets persisted, so we have a cache with the Key being a topic and partition. When we get a record from that combination we

Re: split-brain problem and GridSegmentationProcessor

Hi Amit, Correct you have to provide implementation for both. Your custom segmentation will just be validating something and that method of your segmentation resolver will be called inside the implementation of GridSegmentationProcess which can be overriden through your plugin. By default

Re: split-brain problem and GridSegmentationProcessor

So do I need to implement SegmentationResolver as well as GridSegmentationProcessor. Is that correct? I am trying to understand how the GridSegmentationProcessor and SegmentationResolver work in tandem. Thanks -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Data region's data page size

Yes, you should if average object size exceeds 4KB because otherwise Ignite will spend more time spreading and maintaining a single object across several pages. — Denis > On Nov 7, 2017, at 11:14 AM, Andrey Kornev wrote: > > Thanks Ivan! A follow-up question, if

Re: Unable to connect ignite pods in Kubernetes using Ip-finder

Hi, By some reason the pods cannot resolve an IP address of Kubernetes master that responses on service call. That’s the default name ‘kubernetes.default.svc.cluster.local’ and your DNS knows nothing about it. If you cannot overcome the issue at the network configuration layer set an address

Re: getAverageGetTime/getAveragePutTime APIs of CacheMetrics always return 0

Hi, You need to enable metrics per data region (DataRegionConfiguration.setMetricsEnabled(true)). This is how it’s done in Ignite 2.3: https://apacheignite.readme.io/docs If you prefer to stay on 2.2 then change the documentation version to see how to

Re: Data region's data page size

Thanks Ivan! A follow-up question, if you don't mind. Should I consider changing the default 4K page size to 8K (or possibly to 16K) if the average size of my cache objects is, say, 12K, with max size up to 100K? Thanks Andrey From: Ivan Rakov

Re: split-brain problem and GridSegmentationProcessor

Hi Amit, Sorry I missed that part that you have to provide the GridSegmentationProcessor implementation for both cases. I did it through the plugin and it worked out of the box - I tested it internally with 3 machines and through docker components as well. See [1] for more information - it will

Re: Data region's data page size

Hello Andrey, Short answer: just keep default 4k page size, it will work fine unless you have very specific hardware. Too small page size causes write amplification on hardware level: https://www.cactus-tech.com/resources/blog/details/write-amplification-as-seen-in-solid-state-drives On

Re: split-brain problem and GridSegmentationProcessor

Thanks for the details Luqman. I checked another post (link below) and it seems custom SegmentResolver won't be processed. Were you able to make it work? I want to restart the server node if it has disconnected from the cluster so I don't need multiple resolvers. Link -

RE: Node failed to startup due to deadlock

Hi Naresh, I see deadlocks with 1. com.rover.core.dao.model.admin.AdminPreferenceTable (2 locks) 2. com.rover.core.dao.model.product.assembly.AssemblyUpi2BomTable (2 locks) 3. com.rover.core.dao.model.product.assembly.AssemblyBomUpi2PackageTable, 4.

Unable to connect ignite pods in Kubernetes using Ip-finder

Hi, I have initialized my pods as per steps in link https://apacheignite.readme.io/docs/kubernetes-deployment . I have also tried setting Kubernetes network to *1. flannel 2. weave net*. But I get same error in both cases.

Re: getAverageGetTime/getAveragePutTime APIs of CacheMetrics always return 0

Hi, Using 2.2.0 and looking at the JMX stats, AverageGetTime and AveragePutTime are always 0 (other stats, like CacheGets, are updated as expected) Using cache configuration as: