Re: Transaction Speed

I want to make 2 clients concurrently calculate some values from a cache that read from a database, and store the result in the database. I can't use atomic cacheAtomicityMode as there is no lock so that the calculation might get an old value. I also need a backup to avoid lost cache when a node

RE: Accessing array elements within items cached in Ignite without deserialising the entire item

I agree on correctness being the first priority always J Is there documentation on when that copy is made? For instance, is a copy made for every invocation of a BinarySerializer, or are there some additional caching semantics that mean the copy is made once and stays around for a while so

Re: updating key object field using ignite sql query

Hi, Ignite prevents you to update the key or its field. Look for "Inability to modify a key or its fields with an UPDATE query” callout at the bottom of this section to find a reasoning behind this: https://apacheignite.readme.io/docs/dml#section-update

Re: Ignite sql queries working transactionally

Hi, The docs are still valid - SQL operations are not fully transactional yet and, according, to JIRA the works is in progress to make this happen: https://ggsystems.atlassian.net/browse/IGN-4666 — Denis > On Aug 30, 2017, at 12:21 AM,

Re: Task management - MapReduce & ForkJoin performance penalty

ezhuravlev wrote > Also, maybe it's better to compare your current solution with Ignite on > some real tasks? Or at least more approximate to the real use case > > Evgenii Hi @ezhuravlev Thank you for your replay! I'm preparing more "fair" comparison with our custom made solution but it can't be

Cassandra failing to ReadThrough using Cache.get(key) without preloading

According to everything that I've read, hooking up Cassandra with Ignite should allow for doing a lazy load of the Cache using the Cache.get(key) without using "loadCache" beforehand. However, using Ignite v2.1, I'm not seeing that occur. If I use "loadCache", then my "get" returns values

Re: Possible starvation in striped pool. message

peerClassLoading used only for compute, for example for sharing job classes between nodes, it's not working for objects that put into cache. If you want to work without this classes on nodes, take a look to BinaryObjects: https://apacheignite.readme.io/v2.0/docs/binary-marshaller Evgenii --

Re: Ignite Locking Mechanisms

Hi John, Dmitry from Ignite Community recently created a Wiki that might answer your question - pay attention to section "Checkpoint Pool". Also, you might check Durable Memory implementation details

Ignite Locking Mechanisms

Hi all, When a key is inserted/updated, is the data page the key-value goes into gets locked? If yes, how is this efficient? (since insertions/updates of other key-values that map to the same data page have to wait) I appreciate a detailed explanation. Thanks,

Re: GC stalling all the activity

Hi, 1) Caches are created by clients and cache configuration mode is not transactional. It is atomic. 2) Yes you are right, it is a putAll(). And in worst case, there could be 10 clients writing at max .1G of data, so total data written concurrently can be around 1G or slightly more. But in

Re: Task management - MapReduce & ForkJoin performance penalty

Also, maybe it's better to compare your current solution with Ignite on some real tasks? Or at least more approximate to the real use case Evgenii

Re: Task management - MapReduce & ForkJoin performance penalty

Hi, I don't really understand, what you've tried to measure here? If you run two nodes on the same machine you will have more context switching of the CPU. In this case, your CPU run internal Ignite Threads not from only one node, but from 2 nodes. Additionally, when you use more that one node -

Re: GC stalling all the activity

Hi, Looks like you have open transactions with a big number of entries (or large entries). Do you use TRASACTIONAL cache? How do you save values, using putAll()? If yes, you have following options: - Reduce batch size (number of entries that participate in one transaction). - Check keys, maybe

Re: Task management - MapReduce & ForkJoin performance penalty

It was tested on: - Windows 7 SP1 - Intel I7-4700MQ 2.40GHz - 16GB RAM - SSD - java 1.8.0_112 - Apache Ignite 2.1.0 -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: affinityRun then invoke

Hi, It's not necessary to use affinityRun when you invoke EntryProcessor - EntryProcessor allows for processing data directly on primary nodes. I would recommend you to check this example: https://github.com/apache/ ignite/blob/master/examples/src/main/java/org/apache/

Re: affinityRun then invoke

Hi Matt, In your case ignite.compute().affinityRun(...) is redundant - if you simply call cache.invoke(...), it will send your EntryProcessor to the primary node for the specified key, where it will be executed. Hope this helps. On Wed, Aug 30, 2017 at 4:39 PM, matt wrote:

affinityRun then invoke

I'm using @AffinityKeyMapped to ensure that all items of a particular field (the "parent" in my case) are processed on the same node. When I want to process an entree, I'm essentially doingignite.compute().affinityRun("my-cache", key, () -> this::processEntry);where processEntry

Task management - MapReduce & ForkJoin performance penalty

Hi all [brief overview] I'm evaluating Apache Ignite framework as a replacement for Hazelcast. One of usages where it's planned to be compared is task/job processing. We have implemented tasks management by ourselves based on Hazelcast but not using their MarReduce framework (such as it was very

Re: GC stalling all the activity

Hi Dmitry, Here is the list of Dominator objects and screen shot of the leak suspect. Leak_Suspects.docx List_of_Dominator_Objects.csv

Re: Ignite sql queries working transactionally

In the nearest release should be fixed https://issues.apache.org/ jira/browse/IGNITE-6044 and in the subsequent release will be added support for transactional SQl. 2017-08-30 12:36 GMT+03:00 kotamrajuyashasvi : > Hi > > Thanks for the response > > I still do not

RE: Anaemic Domain Model

Oh ok. So Scan query’s only limitations are JOIN with another cache entity, and aggregation? I believe we have not tried scan query because of this, and have used SQL queries exclusively. Thanks, Narayana. From: Pavel Tupitsyn [mailto:ptupit...@apache.org] Sent: Wednesday, August 30, 2017 2:07

Re: Transaction Speed

Hi Ricky, If there was an option out of box that just can increase transaction speed, I bet it would be on by default. Unfrotunately, there is no magic and, possibily, you can get a speed up with lower failover consistency guarantees. For example, you may want to set writeSyncronizationOrder to

Re: Anaemic Domain Model

With Scan Query there are no restrictions, you can filter on any level of nesting, with computed properties, etc etc. It is just a piece of your code operating on your object, so you can do anything. SQL is more limited, but it also allows nested fields in some cases. Let me know if you need

updating key object field using ignite sql query

Hi In my ignite application I am using a cache with an object/POJO as a cache key. Now how to update the key fields of cache key using ignite sql queries. When I try to update I am getting 'Failed to parse query' error. For example my cache stores value in person [fields: id,name,phno] and key

Ignite sql queries working transactionally

Hi In my ignite client application I need to perform a set of update/delete sql query operations transactionally. I observed that by using ignite transactions I was able to achieve this. When ever an update or delete query is executed with in a transaction, it is locking all resulting rows and

Ignite sql queries working transactionally

Hi In my ignite client application I need to perform a set of update/delete sql query operations transactionally. I observed that by using ignite transactions I was able to achieve this. When ever an update or delete query is executed with in a transaction, it is locking all resulting rows and