Re: Hazelcast vs Ignite vs Geode

is there any update on this? Personally I am very interested in an open source benchmark comparing Geode , Ignite and Hazelcast. Regards -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Hazelcast-vs-Ignite-vs-Geode-tp6345p8925.html Sent from the Apache Ignite

Re: Trouble with Using Ignite 1.8 ODBC Driver

Also is this a problem with Visual Studio 2015 and Ignite and it doesnt happen when we use other VS versions like 2010? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Trouble-with-Using-Ignite-1-8-ODBC-Driver-tp7656p7707.html Sent from the Apache Ignite Users

Re: Trouble with Using Ignite 1.8 ODBC Driver

Hey, Igor many thanks. Is it possible for you to let you know the branch? If it is available in github, I can manually merge in master and try ( We need it urgently). Regards -- View this message in context:

Trouble with Using Ignite 1.8 ODBC Driver

Hi All, We are trying to use Ignite ODBC Driver with DSN. We could build it fine and install it. We have built and compiled the Ignite 1.8 SNAPHOT from github as we saw that the fix is in 1.8. However when trying to create a DSN from the driver it throws an error:- "The setup routines for

Re: Spring application context resource is not injected exception while starting ignite in jdbc driver mode

@agura If you setup Java Spring Automatic persistence And try to connect a Java node with C# this occurs repeatedly. Is there any work around for this? Just as note The same config works with C++ and Java but not with Java and C#? -- View this message in context:

Re: Ignite C++ ScanQuery slower than Jav ScanQuery by 2x always

Thats awesome -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-C-ScanQuery-slower-than-Jav-ScanQuery-by-2x-always-tp6056p6102.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite C++ ScanQuery slower than Jav ScanQuery by 2x always

Thats great !!!. I am sure that this will improve performance as this is one of the hottest method, and as I mentioned earlier this happens in Java too. -- View this message in context:

Re: Ignite C++ ScanQuery slower than Jav ScanQuery by 2x always

Igor, Many thanks. For me that __scrt_common_main_seh looked starnge due to complete unfamiliarity with the code. That EnsureEnoughData is so hot bugs me too, I have seen it in Java also though. The BinaryWriter should help definitely, but i am struggling with it due to some weird problems.

Re: Ignite C++ ScanQuery slower than Jav ScanQuery by 2x always

I will like to add that the CPU sampling in Visual Studio shows that JVM.dll is the hottest path, which is expected i guess. Second is __scrt_common_main_seh 24.87 0.00 Which I am not sure, why is so hot. -- View this message in context:

Ignite C++ ScanQuery slower than Jav ScanQuery by 2x always

Hi I have a Java Node which loads data into a cache. My C++ Node starts another node and tries to fetch all data in the Cache via ScanQuery. The Java one does a ScanQuery in 2.5 seconds for 1 million records. The C++ one takes 9 seconds for the same. I have profiled the code.' The Cache is

Re: Ignite Java and C++ example

Fixed the problem there is a Clear cache code in C++ that was the problem. The cache was cleared before C++ tried to fetch the data and hence had errors... Thsi works fine -- View this message in context:

Ignite Java and C++ example

Hi, I am trying to load data from Java and use it in C++. I think if I load from C++ and see in Java it works fine. But from Java the C+= example seems yto give me no errors but deserializes a default type. Obviously I must be missing something. I am attaching the Java code. The C++ example

Re: Pre Hook before actual Ignite commit

Okay...I think in our case the CacheSToreFactory had an instance of DataSource so that might have been the problem, let me try that -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Pre-Hook-before-actual-Ignite-commit-tp5679p5845.html Sent from the Apache Ignite

Re: Pre Hook before actual Ignite commit

Hey, Sorry for being pedantic. But should I log this as an issue? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Pre-Hook-before-actual-Ignite-commit-tp5679p5784.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Pre Hook before actual Ignite commit

This does however occur. Hikari is not serializable and we are getting that error. Do you need the DataSource sto be serialized? Cant this be configured per node ? -- View this message in context:

Re: Ignite performance improvements

Sorry for the late reply. I understand OPTIMISTIC and PESSIMISTIC modes. I understand OPTIMISTIC Serializable is safer, and we do NEED to use it. Taking these two things out of the way, I think no mode should be faster than OPTIMISTIC READ COMMITTED. Thats what I tried to convey, sorry for

Re: Ignite performance improvements

yes, I understand that. In production we plan to use that, however one question:- In this case if I use the same key in different transactiosn would it impact performance or it will have no impact? -- View this message in context:

Re: Ignite performance improvements

yes, I understand that. In production we plan to use that, however one question:- In this case if I use the same key in different transactiosn would it impact performance or it will have no impact? -- View this message in context:

Re: Pre Hook before actual Ignite commit

There is ... One thing this says that I can put the TransactionManager. However when I try to set the Transactionmanager it throws a not serializable exception, which is odd. Also we use HikariDataSource which itself is not serializable and hence we get an exception :- :

Re: Pre Hook before actual Ignite commit

Yes you understood it fine. First of all our read-write through is setup correctly. So looking into the example you provided, I think only this line to my existing configs should do the trick:- cacheCfg.setCacheStoreSessionListenerFactories(new Factory() { @Override public

Re: Pre Hook before actual Ignite commit

Something like a Spring TransactionSynchornizationmanager. But using that will not work, because it workds for the current node, and Ignite can choose to do the final commit in other JVMs. My problem is that I have 4 caches with Write Through. They use Spring Transactions to do JDBC

Re: Ignite performance improvements

Does OPTIMISTIC Serializable give better performance? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-performance-improvements-tp5623p5684.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Pre Hook before actual Ignite commit

Hi, I want to initiate certain things, before the Ignite Transactions commits. Is there any hook which I could use to do that, which will be called in the node which has bene chosen as the Ignite Primary? -- View this message in context:

Re: Ignite performance improvements

We are getting 4000 TPS with 10 caches on C4 $x large AWS instance. With two nodes on the same machine. Each transaction updates around 8 partioned cache . We have given large heap but still we see the cache updates get slower with static data. is there any work around for this? -- View this

Ignite performance improvements

Hi, We are doing concurrent updates to Ignite. We have 2 nodes on the same machine. Our usecase is that we want to Order entry. It shoul dbe as fast as possible. We saw the following hotspots when we analyzed with FlightRecorder:- Recheked the hot spots seem to be GridCacheMapEntry.obsolete

Re: Slow Transaction Performance

Setting PRIMARY_SYNC helps for partitioned caches. It should be faster. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Slow-Transaction-Performance-tp5548p5563.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite Write Behind performance

We use it to conservative 2 now in our current setting -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Write-Behind-performance-tp5385p5549.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Increase transaction throughput with nodes.

Should we change it to a value higher than 500 , if cpu limit is not present? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Increase-transaction-throughput-with-nodes-tp5411p5513.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Increase transaction throughput with nodes.

Danis, CacheConfiguration.setMaxConcurrentAsyncOperations :- Is it set per cache or in Ignite-Config on Node startup? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Increase-transaction-throughput-with-nodes-tp5411p5510.html Sent from the Apache Ignite Users

Re: Ignite Write Behind performance

I did test this...For us I think Write behind gets called fine. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Write-Behind-performance-tp5385p5475.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Ignite faster with startup order

Hi, I have an application which embeds a Apache Ignite instance in a TCP server. I have another process which starts another ignite instance. All clients request to the TCP server, which starts an Ignite Transactions does some inserts. I have observed a peculiar thing, when I start the TCP

Re: Ignite Transaction performance

Hello, can some one please submit an alternative? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5419.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite Write Behind performance

Thanks we are considering implementing JDBC batch inserts -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Write-Behind-performance-tp5385p5418.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

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:

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 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

Ignite Write Behind performance

Hello, I am struggling with improving ignite transaction performance. However this is another problem However if I am doing write behind and the writes are slow, I am seeing that the over all performance of teh grid drops. Is there any configuration that I can do to make ignite performance

Re: Affinity Key Mapping

Thanks everyone. I got around this with Ignite Atomic cache. However with replication my transactions still seem to be too slow. Is there anything I can do to make it faster? -- View this message in context:

Re: Ignite Transaction performance

I have made all caches Atomic which need to be in transaction. Still the performance is no where near a singke node. I get 2 inserts / sec on a single node now, and around 2000-2500 on a 2 node setup. Is there any thing I can do to increase performance ? I am open to adding to one more node

Re: Ignite Transaction performance

Val, Thanks for the tips.But I saw very little gains 4-10%. For a large set of nodes this does provid ebenefit. However we plan to deploy two nodes and then take it from there as demand grows. is there any other way I can imporve what is known in RDBMS terms insert throughput? -- View this

Re: Affinity Key Mapping

Alexei, yes I understand with Ignite Optmistic means lock acquisition on write for READCOMMITED. With PESSIMISTIC it would be on read. However consider a cache like Country (contrived example )...many people may live in USA. But if someone tries to do a transaction for a entry on write all will

Re: Affinity Key Mapping

Ignore my latest question . This seems to work fine. I have one kind of feature request though. It seems with transaction, Ignite always tries to get the lock for the keys accessed. However some caches can be read only. Multiple transactions can access the same key, but they will never modify

Re: Affinity Key Mapping

Val, Excellent feedback. I will update and let you guys know. However is there any way to use transactions within https://apacheignite.readme.io/docs/affinity-collocation#collocating-compute-with-data ... -- View this message in context:

Re: Ignite Transaction performance

Val, Some of our caches have to REPLICATED , as they are mostly read only caches. I will try Primary_SYNC and try. Regards -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5317.html Sent from the Apache Ignite Users mailing

Re: Affinity Key Mapping

disruptor.zip Uploading the code. I have tried to mimic my code as much as possible. However I have used no DTO's (only one). In my actual business code there are lots of caches with Key Long and Value DTO. I understand

Re: MArshaller question

Thanks. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/MArshaller-question-tp5273p5277.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite Transaction performance

I am creating the test cases. I saw that doing inserts increase the latency severely. I have a question does Ignite treat inserts the same as updates ? My isolation level is OPTIMISTIC with serializable -- View this message in context:

MArshaller question

Sorry for polluting the mailing list with sometimes useless questions. Which is the recommended marshaller for ignite now:- Binary Marshaller, JDkMarshaller or OptimizedMarshaller purely from performance standpoints -- View this message in context:

Re: Affinity Key Mapping

Hey , many thanks for the quick and awesome response. I have an idea now about how to use Affinity mapping. The doc is clear now. I will ask some questions later on about Affinity mapping. But does increasing partitions for a cache help with Transaction performance? I am struggling to increase

Re: Affinity Key Mapping

Hey Thanks for the reply. I am copying the example here :- / Instantiate person keys with the same company ID which is used as affinity key. Object personKey1 = new PersonKey("myPersonId1", "myCompanyId"); Object personKey2 = new PersonKey("myPersonId2", "myCompanyId"); Person p1 = new

Re: Ignite Transaction performance

Val, Will do that, but meanwhile can I increase performance incresing System Thread pool etc? My machine has CPU and bandwidth limit is still not reached -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5226.html Sent

Re: Ignite Transaction performance

Lastly is there any thread count number to be increased to help in high throughput commit messages...liek does increasing the system threads increase performance? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5222.html

Affinity Key Mapping

If I have two domain objects lets say A, B, do I need to put them in the same cache to use Affinity key mapping? Or can it work with different caches? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Affinity-Key-Mapping-tp5212.html Sent from the Apache Ignite

Re: Ignite Transaction performance

Server Node. Disabled Backups. But all changes are SYNCED synchronously. Caches are all partitioned and there are 4 caches. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5199.html Sent from the Apache Ignite Users mailing

Re: Ignite Transaction performance

Val, Its correct that its so. Hwoever If I add one more node, this adds serious overhead. if I add more threads and start giving more concurrent inputs some transactions start slowing down with some going more than 3 seconds !!!. However I read about affinity key, does it help while inserting

Re: Ignite Transaction performance

I will try to. But the code is difficult to replicate for obvious reasons. The cache keys are Long and the values are Java POJO's. There are two nodes running on different systems. There is however a massive amount of concurrent transactions. I saw there is an optimization in Ignite 1.6 RC1 for

Re: Error on Transactions with Write Behind

Hey, It does work with READ_COMMITTED However, can you please let me know what is the expected release in which this fix will be included? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Error-on-Transactions-with-Write-Behind-tp4736p4817.html Sent from the

Re: Ignite WRite Behind

does write behind work without this setting :- cacheCfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_ASYNC); Here is my cache setting :- cacheCfg.setReadThrough(true); cacheCfg.setWriteThrough(true); cacheCfg.setWriteBehindEnabled(true);

Re: Ignite WRite Behind

I undrestand that WriteAll will be called per cache. But my undrestanding is this :- 1) There are two configs for write behind 1) No of Entries and Time 2) SO if I make three cache entries in three transaction before the time (which is configured to lets say 4000 ms ) then the writeAll should

Re: Error on Transactions with Write Behind

One of my cache has actually read write through disabled. Another has write behind enabled. I am still getting the conflict. The first cache is used to read some values, where as the other one is used for writing. Should there be a conflict in this case? (The first cache only has some reference

Re: Ignite WRite Behind

Hi, I have 2 nodes setup and there are around 5 different caches involved, with 1 entry per cache per transaction. I have writeThrough set to true and writeBehindEnabled set to true. -- View this message in context: