Re: Simulating Graph Dependencies With Ignite

Alexei, what do you think about the object size and the affinity code? Thanks, Amit. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Simulating-Graph-Dependencies-With-Ignite-tp5282p5416.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite - rest api port

Hi You should copy directory named *ignite-rest-http* from *libs/optional/* to *libs/* and restart node On Fri, Jun 3, 2016 at 9:08 PM, M Singh wrote: > Hi Folks: > > I have downloaded the apache-ignite-fabric-1.6.0-bin.zip file an have > started it with the ignite.sh script. > > However, I am

Ignite - rest api port

Hi Folks: I have downloaded the apache-ignite-fabric-1.6.0-bin.zip file an have started it with the ignite.sh script.   However, I am not able to connect to the rest service url (http://localhost:8080/ignite?cmd=version) - it returns an empty response.  I think that rest service is running on an

Re: Ignite Write Behind performance

Ignite _does_ use a separate thread pool to persist data in write-behind mode, this is the essential difference between write-through and write-behind. However, if your cache load rate is significantly higher than the database insert rate, the write queue will grow faster than background threads ca

Re: Ignite Write Behind performance

I understood this perfectly. What I mean is :- Shouldnt the write behind use a separete thread pool so that slow write behind process does not impact the whole grid ? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Write-Behind-performance-tp5385p5412.ht

Increase transaction throughput with nodes.

Hi I want some basic ideas. In ignite with mostly insert heavy work load, does adding nodes increase transaction throughput or decrease it? Assuming that the caches are PARTIONED with Primary Sync. I believe one of the important distinctions between ignite and RDBMS should be that Ignite should

Re: Ignite - Question about update counter field for continuous queries

Thanks Alexey for the answer. On Friday, June 3, 2016 9:36 AM, Alexey Goncharuk wrote: Hi, Ignite client automatically checks the partition counter and filters out duplicate events, you do not need to do it manually to get rid of duplicates. However, starting from Ignite 1.6 update co

Re: Ignite - Question about update counter field for continuous queries

Hi, Ignite client automatically checks the partition counter and filters out duplicate events, you do not need to do it manually to get rid of duplicates. However, starting from Ignite 1.6 update counter is available through CacheQueryEvent API. 2016-06-03 5:23 GMT-07:00 M Singh : > Hi Folks: >

Re: Persistent storage with Ignite C++

Hi Guys, As far as I understand, yes, this is going to work as long as all necessary user Java classes are available for the C++ node. Best Regards, Igor On Fri, Jun 3, 2016 at 3:53 PM, Denis Magda wrote: > Hi Graham, > > You can specify a Java-based implementation of a persistent storage in >

Re: One failing node stalling the whole cluster

Hi Daniel, Actually a failure of one machine shouldn’t lead to the whole cluster shutdown unless your application code was executed on those nodes as well and killed other nodes due to high GC pauses or some other reason. My first suggestion is to tune garbage collection appropriately: https://

Re: Persistent storage with Ignite C++

Hi Graham, You can specify a Java-based implementation of a persistent storage in Spring XML configuration of Ignite and start a C++ node with this configuration. After that the data that is stored on C++ node should be persisted as well. Igor Sapego, please correct me if I’m wrong. — Denis >

Re: Cache.put delays

Hi Binti, I would suggest you giving a try to Ignite 1.6.0 that has been released recently. The release incorporates tons of the fixes and the issue you’re talking might have been already fixed there. If the issue is still reproduced on 1.6.0 please open a JIRA ticket posting details and a cod

Re: Discovering Topics that are being listened to

Hi Nick, I would keep the names of all the topics in a replicated cache. Every server and client will have access to it and can retrieve all the topics' names stored there and subscribe for them after that. Does this work for you? — Denis > On Jun 3, 2016, at 3:49 AM, nickg wrote: > > Hi al

Re: put data and then get it , but it returns null in sometimes

Don’t think that it will be easy track back all the fixes that have been done since that time. Actually both versions are binary compatible, so everything should work fine for you after you switch to 1.6.0. Also you can write a test that proves that the issue exists in 1.4.0 and fixed in 1.6.0

Ignite - Question about update counter field for continuous queries

Hi Folks: I have a question about once only event delivery for continuous queries.   The document (https://apacheignite.readme.io/docs/continuous-queries) indicates that there is a per partition update counter which is sent to the client along with the change notification.  I checked the CacheEnt

Re: Ignite Write Behind performance

As I explained in the situation when the write-behind queue is full a Thread that updates a cache and propagates the changes into the write-behind store can be used to flush the write-behind queue since the queue is full. This situation can affect the performance especially if this happens too o

Re: Ignite Write Behind performance

Danis, Thanks. I am trying that. However shouldnt the write behinds not impact the GRID performance at all. Since we are writing in write behin dmode to avoid the cost of slow disk IO. I understand that theres a limit, but shouldnt this thread pool be different if technically possible, allowing