Thanks for contributing IGNITE-2404 (TcpDiscoverySpi.setLocalPortRange set 0 doesn't work)

I want to thank Ryan Zhao from the community side for the sensible contribution he has done in critical components of Ignite. Ryan also thanks for keep patience during several review cycles and for providing final high quality code. Look forward for new contributions from your side, Denis

[GitHub] ignite pull request: IGNITE-2404

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/549 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[GitHub] ignite pull request: IGNITE-2941

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/631 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[GitHub] ignite pull request: Ignite 2594

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/654 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[jira] [Created] (IGNITE-3024) Possible deadlock in services when Spring is used

Valentin Kulichenko created IGNITE-3024: --- Summary: Possible deadlock in services when Spring is used Key: IGNITE-3024 URL: https://issues.apache.org/jira/browse/IGNITE-3024 Project: Ignite

Re: Data lost when using write-behind

Yes, this is correct, if there is no write-behind, then in TRANSACTIONAL cache the database write happens from the originating node, and in ATOMIC cache - from primary nodes.​

RE: Data lost when using write-behind

Alex, Thanks for the explanation! However in case of write-through mode there is a difference in transactional and atomic caches. In transactional mode data is committed from a transaction coordinator side while in atomic mode – from primary nodes. Is my understanding correct? Denis From:

Re: Data lost when using write-behind

Denis, Updates are always queued on primary nodes when write-behind is enabled, regardless of atomicity mode. This is required because otherwise updates can be written to the database in a wrong order. We did not queue database updates on backups because we did not have a mechanism that would

Fwd: Data lost when using write-behind

Igniters, Do we queue changes on backup nodes as well and flush them to the store if a primary node leaves? This is irrelevant for transactional caches since changes are queue and flushed on a side of a transaction initiator, right? And flushing from backups makes sense only for atomic

Re: API for asynchronous execution.

Agree. Let’s use the annotation approach. However, annotation can be easily missed, so we should make sure we document it with examples, and javadoc it with examples. D. On Mon, Apr 18, 2016 at 5:39 AM, Nikolay Tikhonov wrote: > Dima, > We have also JCache API which

[GitHub] ignite pull request: IGNITE-3014 : Optimize GridDhtPartitionTopolo...

GitHub user ilantukh opened a pull request: https://github.com/apache/ignite/pull/655 IGNITE-3014 : Optimize GridDhtPartitionTopologyImpl#localPartition() You can merge this pull request into a Git repository by running: $ git pull https://github.com/ilantukh/ignite

[jira] [Created] (IGNITE-3023) Rename keyBackups to Backups for performance advices printed out on a node

Sergey Kozlov created IGNITE-3023: - Summary: Rename keyBackups to Backups for performance advices printed out on a node Key: IGNITE-3023 URL: https://issues.apache.org/jira/browse/IGNITE-3023

[jira] [Created] (IGNITE-3022) Unable to start Ignite Node on AWS

Vijayendra Bhati created IGNITE-3022: - Summary: Unable to start Ignite Node on AWS Key: IGNITE-3022 URL: https://issues.apache.org/jira/browse/IGNITE-3022 Project: Ignite Issue Type:

[GitHub] ignite pull request: Ignite 2594

GitHub user vldpyatkov opened a pull request: https://github.com/apache/ignite/pull/654 Ignite 2594 You can merge this pull request into a Git repository by running: $ git pull https://github.com/vldpyatkov/ignite ignite-2594 Alternatively you can review and apply these

Re: API for asynchronous execution.

Dima, We have also JCache API which allow register/deregister continuous query javax.cache.Cache#registerCacheEntryListener(CacheEntryListenerConfiguration) and we can't change it. I think that annotation looks better for consistency both API. On Mon, Apr 18, 2016 at 7:26 AM, Dmitriy Setrakyan

[GitHub] ignite pull request: IGNITE-2952

GitHub user vldpyatkov opened a pull request: https://github.com/apache/ignite/pull/653 IGNITE-2952 Add yardstick benchmark for cache load testing Sql queries are generating randomly by QueryEntries now. You can merge this pull request into a Git repository by running: $

[GitHub] ignite pull request: IGNITE-2952

Github user vldpyatkov closed the pull request at: https://github.com/apache/ignite/pull/646 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[jira] [Created] (IGNITE-3021) Test org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated fails sometimes.

Ivan Veselovsky created IGNITE-3021: --- Summary: Test org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated fails sometimes. Key: IGNITE-3021 URL:

[GitHub] ignite pull request: Gridgain 7.5.14

GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/652 Gridgain 7.5.14 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite gridgain-7.5.14 Alternatively you can review and

[jira] [Created] (IGNITE-3020) .NET: Ensure that Windows service is stopped correctly in case of forceful node stop.

Vladimir Ozerov created IGNITE-3020: --- Summary: .NET: Ensure that Windows service is stopped correctly in case of forceful node stop. Key: IGNITE-3020 URL: https://issues.apache.org/jira/browse/IGNITE-3020

[jira] [Created] (IGNITE-3019) Implement config variations test for IgniteCompute

Semen Boikov created IGNITE-3019: Summary: Implement config variations test for IgniteCompute Key: IGNITE-3019 URL: https://issues.apache.org/jira/browse/IGNITE-3019 Project: Ignite Issue

[jira] [Created] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

Semen Boikov created IGNITE-3018: Summary: Cache affinity calculation is slow with large nodes number Key: IGNITE-3018 URL: https://issues.apache.org/jira/browse/IGNITE-3018 Project: Ignite