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 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 enab
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 enab
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 enab
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/653
---
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 enab
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
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.
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: A
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 all
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 caches,
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 allow register/deregister co
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 ignite-301
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
Project:
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: Bug
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 chang
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
wr
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:
$ gi
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
Ivan Veselovsky created IGNITE-3021:
---
Summary: Test
org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated
fails sometimes.
Key: IGNITE-3021
URL: https://issues.apache.org/jira/b
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 apply
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
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 Typ
22 matches
Mail list logo