[GitHub] ignite pull request: IGNITE-2415: CacheLoadOnlyStoreAdapter use ex...
GitHub user shroman opened a pull request: https://github.com/apache/ignite/pull/569 IGNITE-2415: CacheLoadOnlyStoreAdapter use example. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shroman/ignite ignite-2415 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/569.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #569 commit ad704391e8d6f4019d4401a43b3cede197b860a0 Author: shtykh_roman Date: 2016-03-22T05:27:34Z IGNITE-2415: CacheLoadOnlyStoreAdapter use example. --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Switching back to review-then-commit process
Branko, Personally, it's not clear to me why the decision on having RTC process for committers for most critical modules shows our immaturity in a sense of open source collaboration. As Raul properly noted below, the committers were always using RTC informally for most of the modules trying to reach each other asking to check changes before they get merged. In my understanding it shows that Ignite committers takes care more on the quality of the contributions rather than on a number of patches that get merged in a day or in a week. The only thing we did for now is that we put this type of collaboration on a paper. It's not feasible to create a super comprehensive test that will check all the cases, it's not realistic to document every line of the internal code. But it's always possible to check your contribution with a committer who is more experienced in a specific functionality, get his feedback and as a result grow your own expertise. In my initial example I referred to Spark community that has a list of maintainers as well. I think that this rule didn't lead to the project stagnation but rather allowed to adopt Spark in tons of projects worldwide by delivering releases with high quality. At this moment Ignite community decided to go this way as well. We're free to change our decision later if something doesn't work. -- Denis On 3/21/2016 6:45 PM, Branko Čibej wrote: On 05.03.2016 04:43, Konstantin Boudnik wrote: It saddens me to see this coming to it ;( Yeah. You guys are introducing red tape that's a barrier for new committers and a bureaucratic trap for everyone else. For example: what happens when a module owner takes off for a couple months? Which is likely, since this is, after all, a volunteer effort. Are you going to block any changes to that module until/unless she becomes active again, or just break your own rules for convenience? Maybe you're counting on many module owners being employed to do this stuff ... in which case you should all go back to the incubator because you've learned NOTHING about open source collaboration in all this time. Pah, what nonsense. -- Brane P.S.: Also please stop using "Ignite is complex" as an argument for locking down on progress. Give the other guy the courtesy of assuming he's not a total idiot. How about spending time on a comprehensive test suite and developer documentation instead? On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: Igniters, I would propose to switch back to review-then-commit process. This process has to be followed by both contributors and committers. There is a reason for this I have in mind. Ignite is a complex platform with several big modules. Some of the people may be experts in module A while others in module B etc. If a committer, who is good in module A, makes changes in module B merging the changes without a review this can break module's B internal functionality that the committer didn't take into account. My proposal is to introduce a list of maintainers for every Ignite module like it's done in Spark [1] and a rule that will require a committer to get an approval from a module maintainer before merging changes. Thoughts? -- Denis [1] https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
Tuning number of partitions per cache
Igniters, Let's say I know the following parameters of my system and cluster: - number of nodes and their CPUs; - per node size and total size; - number of caches; - number of entries in the caches; - network bandwidth. And I want to tune a number of partitions per cache to gain much possible performance of my cluster. The first obvious thing we know is that the number of partitions mustn't be less than the number of nodes. Next possible suggestion is that if average partition size is measured in tens/hundreds(?) of gigabytes and more then we should set more partitions to reduce this size. I have the following case in mind for this suggestion. Let's say we have partition "10" which size is around 20 GB. If to increase the number of partitions in a such a way that this 20 GB will be split among two or three partitions located on different nodes then the rebalancing should happen faster because the same amount of data will be preloaded from different nodes rather than from a single one. Is my understanding correct? Am I missing something? Is anyone else have other suggestions in mind taking into account the parameters from the list above? -- Denis
Re: Switching back to review-then-commit process
On Mon, Mar 21, 2016 at 8:45 AM, Branko Čibej wrote: > On 05.03.2016 04:43, Konstantin Boudnik wrote: > > It saddens me to see this coming to it ;( > > Yeah. You guys are introducing red tape that's a barrier for new > committers and a bureaucratic trap for everyone else. > > For example: what happens when a module owner takes off for a couple > months? Which is likely, since this is, after all, a volunteer effort. > Are you going to block any changes to that module until/unless she > becomes active again, or just break your own rules for convenience? > Most modules have 2 or 3 owners, responsible for reviewing changes. If delayed reviews become an issue, which I doubt, we can always reassign or add ownership. > Maybe you're counting on many module owners being employed to do this > stuff ... in which case you should all go back to the incubator because > you've learned NOTHING about open source collaboration in all this time. > Pah, what nonsense. > I think everyone is entitled to their own opinion. I personally had no preference here and did not get involved in this community discussion. However, it is clear that the community prefers this process, after giving CTR an honest try, so let’s be respectful of the outcome. > > -- Brane > > P.S.: Also please stop using "Ignite is complex" as an argument for > locking down on progress. Give the other guy the courtesy of assuming > he's not a total idiot. How about spending time on a comprehensive test > suite and developer documentation instead? > > > > On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: > >> Igniters, > >> > >> I would propose to switch back to review-then-commit process. This > >> process has to be followed by both contributors and committers. > >> > >> There is a reason for this I have in mind. Ignite is a complex > >> platform with several big modules. Some of the people may be experts > >> in module A while others in module B etc. > >> If a committer, who is good in module A, makes changes in module B > >> merging the changes without a review this can break module's B > >> internal functionality that the committer didn't take into account. > >> > >> My proposal is to introduce a list of maintainers for every Ignite > >> module like it's done in Spark [1] and a rule that will require a > >> committer to get an approval from a module maintainer before merging > >> changes. > >> > >> Thoughts? > >> > >> -- > >> Denis > >> > >> [1] > https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers > >> > >> > >> > >
[GitHub] ignite pull request: IGNITE-2870 .NET: Fix index names for nested ...
GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/568 IGNITE-2870 .NET: Fix index names for nested fields in attribute-based SQL configuration You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-2870 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/568.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #568 commit 5a54b3c272d9aa0f5500ab649a54599c9aa3b0a8 Author: Pavel Tupitsyn Date: 2016-03-21T17:02:13Z IGNITE-2870 .NET: Attribute-based SQL configuration handles nested indexed field incorrectly commit e02c00ac1002e49309776c5926f1ab62fe041d06 Author: Pavel Tupitsyn Date: 2016-03-21T17:18:39Z Fix index names --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-2870) .NET: Attribute-based SQL configuration handles nested indexed field incorrectly
Pavel Tupitsyn created IGNITE-2870: -- Summary: .NET: Attribute-based SQL configuration handles nested indexed field incorrectly Key: IGNITE-2870 URL: https://issues.apache.org/jira/browse/IGNITE-2870 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 1.6 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Priority: Blocker Fix For: 1.6 For nested fields (Employee.Address.Zip, for example) * QueryEntity.fields expects dot notation: address.zip * QueryEntity.indexes expects only field name: zip [QuerySqlField(IsIndexed=true)] results in dot notation in both cases, which causes hand on cache creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Switching back to review-then-commit process
On 05.03.2016 04:43, Konstantin Boudnik wrote: > It saddens me to see this coming to it ;( Yeah. You guys are introducing red tape that's a barrier for new committers and a bureaucratic trap for everyone else. For example: what happens when a module owner takes off for a couple months? Which is likely, since this is, after all, a volunteer effort. Are you going to block any changes to that module until/unless she becomes active again, or just break your own rules for convenience? Maybe you're counting on many module owners being employed to do this stuff ... in which case you should all go back to the incubator because you've learned NOTHING about open source collaboration in all this time. Pah, what nonsense. -- Brane P.S.: Also please stop using "Ignite is complex" as an argument for locking down on progress. Give the other guy the courtesy of assuming he's not a total idiot. How about spending time on a comprehensive test suite and developer documentation instead? > On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: >> Igniters, >> >> I would propose to switch back to review-then-commit process. This >> process has to be followed by both contributors and committers. >> >> There is a reason for this I have in mind. Ignite is a complex >> platform with several big modules. Some of the people may be experts >> in module A while others in module B etc. >> If a committer, who is good in module A, makes changes in module B >> merging the changes without a review this can break module's B >> internal functionality that the committer didn't take into account. >> >> My proposal is to introduce a list of maintainers for every Ignite >> module like it's done in Spark [1] and a rule that will require a >> committer to get an approval from a module maintainer before merging >> changes. >> >> Thoughts? >> >> -- >> Denis >> >> [1] >> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers >> >> >>
Re: Switching back to review-then-commit process
I recommend to add Andrey Novikov as Visor maintainer. On Mon, Mar 21, 2016 at 10:16 PM, Denis Magda wrote: > Oops, a misprint. Fixed, thanks Pavel. > > -- > Denis > > > On 3/21/2016 6:14 PM, Pavel Tupitsyn wrote: > >> Suspicious entries: >> * C++ API Ivan Veselovsky >> * Docker, Mesos, YARN integration Igor Sapego >> >> On Mon, Mar 21, 2016 at 6:08 PM, Sergi Vladykin > > >> wrote: >> >> Looks good. >>> >>> Sergi >>> >>> 2016-03-21 16:37 GMT+03:00 Denis Magda : >>> >>> Igniters, I've prepared a draft of the maintainers list. >>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers >>> Please review it and/or adjust it whenever is needed. If you have any thoughts, concerns let's discuss them there. -- Denis On 3/10/2016 1:37 PM, Sergi Vladykin wrote: If everyone is ok with the proposals, then we need to set this new > approach > and properly document it. > > Also we need to select list of RTC modules and elect their maintainers. > > Sergi > > 2016-03-05 19:31 GMT+03:00 Sergi Vladykin : > > +1 to the original proposal of Denis to introduce module maintainers > and > >> RTC process >> +1 to the proposal of Raul to restrict number of core modules, which >> require maintainers review >> >> Sergi >> >> >> 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik : >> >> It saddens me to see this coming to it ;( >> >>> On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: >>> >>> Igniters, I would propose to switch back to review-then-commit process. This process has to be followed by both contributors and committers. There is a reason for this I have in mind. Ignite is a complex platform with several big modules. Some of the people may be experts in module A while others in module B etc. If a committer, who is good in module A, makes changes in module B merging the changes without a review this can break module's B internal functionality that the committer didn't take into account. My proposal is to introduce a list of maintainers for every Ignite module like it's done in Spark [1] and a rule that will require a committer to get an approval from a module maintainer before merging changes. Thoughts? -- Denis [1] >>> >>> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers >>> > -- Alexey Kuznetsov GridGain Systems www.gridgain.com
Re: Switching back to review-then-commit process
Oops, a misprint. Fixed, thanks Pavel. -- Denis On 3/21/2016 6:14 PM, Pavel Tupitsyn wrote: Suspicious entries: * C++ API Ivan Veselovsky * Docker, Mesos, YARN integration Igor Sapego On Mon, Mar 21, 2016 at 6:08 PM, Sergi Vladykin wrote: Looks good. Sergi 2016-03-21 16:37 GMT+03:00 Denis Magda : Igniters, I've prepared a draft of the maintainers list. https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers Please review it and/or adjust it whenever is needed. If you have any thoughts, concerns let's discuss them there. -- Denis On 3/10/2016 1:37 PM, Sergi Vladykin wrote: If everyone is ok with the proposals, then we need to set this new approach and properly document it. Also we need to select list of RTC modules and elect their maintainers. Sergi 2016-03-05 19:31 GMT+03:00 Sergi Vladykin : +1 to the original proposal of Denis to introduce module maintainers and RTC process +1 to the proposal of Raul to restrict number of core modules, which require maintainers review Sergi 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik : It saddens me to see this coming to it ;( On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: Igniters, I would propose to switch back to review-then-commit process. This process has to be followed by both contributors and committers. There is a reason for this I have in mind. Ignite is a complex platform with several big modules. Some of the people may be experts in module A while others in module B etc. If a committer, who is good in module A, makes changes in module B merging the changes without a review this can break module's B internal functionality that the committer didn't take into account. My proposal is to introduce a list of maintainers for every Ignite module like it's done in Spark [1] and a rule that will require a committer to get an approval from a module maintainer before merging changes. Thoughts? -- Denis [1] https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
Re: Switching back to review-then-commit process
Suspicious entries: * C++ API Ivan Veselovsky * Docker, Mesos, YARN integration Igor Sapego On Mon, Mar 21, 2016 at 6:08 PM, Sergi Vladykin wrote: > Looks good. > > Sergi > > 2016-03-21 16:37 GMT+03:00 Denis Magda : > > > Igniters, > > > > I've prepared a draft of the maintainers list. > > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers > > > > Please review it and/or adjust it whenever is needed. > > > > If you have any thoughts, concerns let's discuss them there. > > > > -- > > Denis > > > > On 3/10/2016 1:37 PM, Sergi Vladykin wrote: > > > >> If everyone is ok with the proposals, then we need to set this new > >> approach > >> and properly document it. > >> > >> Also we need to select list of RTC modules and elect their maintainers. > >> > >> Sergi > >> > >> 2016-03-05 19:31 GMT+03:00 Sergi Vladykin : > >> > >> +1 to the original proposal of Denis to introduce module maintainers and > >>> RTC process > >>> +1 to the proposal of Raul to restrict number of core modules, which > >>> require maintainers review > >>> > >>> Sergi > >>> > >>> > >>> 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik : > >>> > >>> It saddens me to see this coming to it ;( > > On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: > > > Igniters, > > > > I would propose to switch back to review-then-commit process. This > > process has to be followed by both contributors and committers. > > > > There is a reason for this I have in mind. Ignite is a complex > > platform with several big modules. Some of the people may be experts > > in module A while others in module B etc. > > If a committer, who is good in module A, makes changes in module B > > merging the changes without a review this can break module's B > > internal functionality that the committer didn't take into account. > > > > My proposal is to introduce a list of maintainers for every Ignite > > module like it's done in Spark [1] and a rule that will require a > > committer to get an approval from a module maintainer before merging > > changes. > > > > Thoughts? > > > > -- > > Denis > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers > > > > > > > > >>> > > >
Re: Switching back to review-then-commit process
Looks good. Sergi 2016-03-21 16:37 GMT+03:00 Denis Magda : > Igniters, > > I've prepared a draft of the maintainers list. > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers > > Please review it and/or adjust it whenever is needed. > > If you have any thoughts, concerns let's discuss them there. > > -- > Denis > > On 3/10/2016 1:37 PM, Sergi Vladykin wrote: > >> If everyone is ok with the proposals, then we need to set this new >> approach >> and properly document it. >> >> Also we need to select list of RTC modules and elect their maintainers. >> >> Sergi >> >> 2016-03-05 19:31 GMT+03:00 Sergi Vladykin : >> >> +1 to the original proposal of Denis to introduce module maintainers and >>> RTC process >>> +1 to the proposal of Raul to restrict number of core modules, which >>> require maintainers review >>> >>> Sergi >>> >>> >>> 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik : >>> >>> It saddens me to see this coming to it ;( On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: > Igniters, > > I would propose to switch back to review-then-commit process. This > process has to be followed by both contributors and committers. > > There is a reason for this I have in mind. Ignite is a complex > platform with several big modules. Some of the people may be experts > in module A while others in module B etc. > If a committer, who is good in module A, makes changes in module B > merging the changes without a review this can break module's B > internal functionality that the committer didn't take into account. > > My proposal is to introduce a list of maintainers for every Ignite > module like it's done in Spark [1] and a rule that will require a > committer to get an approval from a module maintainer before merging > changes. > > Thoughts? > > -- > Denis > > [1] > https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers > > > >>> >
[jira] [Created] (IGNITE-2869) IGFS: Optimize IgfsListingEntry write.
Vladimir Ozerov created IGNITE-2869: --- Summary: IGFS: Optimize IgfsListingEntry write. Key: IGNITE-2869 URL: https://issues.apache.org/jira/browse/IGNITE-2869 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 1.6 Do not write it as object, but rather inline. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2868) IGFS: Investigate whether trash require further striping.
Vladimir Ozerov created IGNITE-2868:
---
Summary: IGFS: Investigate whether trash require further striping.
Key: IGNITE-2868
URL: https://issues.apache.org/jira/browse/IGNITE-2868
Project: Ignite
Issue Type: Task
Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Ivan Veselovsky
Fix For: 1.6
Currently trash is striped into 16 items. It seems that this is not enough for
distributed environment where dozens and even hundreds threads might perform
concurrent removes.
Let's try increasing amount of stripes and see it it helps anyhow.
The only line needs to be changes is {{IgfsUtils.TRASH_CONCURRENCY}}. Let's try
setting it to 128 or 256.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2867) IgniteConsistencyException during running load test (cache-atomic-invoke-retry-validator)
Ilya Suntsov created IGNITE-2867:
Summary: IgniteConsistencyException during running load test
(cache-atomic-invoke-retry-validator)
Key: IGNITE-2867
URL: https://issues.apache.org/jira/browse/IGNITE-2867
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 1.6
Environment: Yardstick driver's host: Ubuntu 14.04.3 LTS
Yardstick server's hosts: Ubuntu 14.04.3 LTS and CentOS release 6.7 (Final)
Yardstick configuration: 2 clients, 3 servers, PRIMARY_SYNC, 1 and 2 backups
Reporter: Ilya Suntsov
Assignee: Artem Shutak
Priority: Critical
Fix For: 1.6
Attachments: logs_configs_2103.zip
I've add one more client and run load test with 2 clients and 3 servers (all on
different hosts).
Test runs for ~ 3 min and stops with exception:
{noformat}
Got exception:
org.apache.ignite.yardstick.cache.failover.IgniteConsistencyException: Cache
and local map are in inconsistent state.
{noformat}
Logs and configs you can find in attachment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Switching back to review-then-commit process
Igniters, I've prepared a draft of the maintainers list. https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers Please review it and/or adjust it whenever is needed. If you have any thoughts, concerns let's discuss them there. -- Denis On 3/10/2016 1:37 PM, Sergi Vladykin wrote: If everyone is ok with the proposals, then we need to set this new approach and properly document it. Also we need to select list of RTC modules and elect their maintainers. Sergi 2016-03-05 19:31 GMT+03:00 Sergi Vladykin : +1 to the original proposal of Denis to introduce module maintainers and RTC process +1 to the proposal of Raul to restrict number of core modules, which require maintainers review Sergi 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik : It saddens me to see this coming to it ;( On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: Igniters, I would propose to switch back to review-then-commit process. This process has to be followed by both contributors and committers. There is a reason for this I have in mind. Ignite is a complex platform with several big modules. Some of the people may be experts in module A while others in module B etc. If a committer, who is good in module A, makes changes in module B merging the changes without a review this can break module's B internal functionality that the committer didn't take into account. My proposal is to introduce a list of maintainers for every Ignite module like it's done in Spark [1] and a rule that will require a committer to get an approval from a module maintainer before merging changes. Thoughts? -- Denis [1] https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
[GitHub] ignite pull request: IGNITE-1957 .NET: Collections, dictionaries, ...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/302 --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-2866) .NET: Automatic JAVA_HOME detection
Pavel Tupitsyn created IGNITE-2866:
--
Summary: .NET: Automatic JAVA_HOME detection
Key: IGNITE-2866
URL: https://issues.apache.org/jira/browse/IGNITE-2866
Project: Ignite
Issue Type: Improvement
Components: platforms
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Fix For: 1.6
If JAVA_HOME env var and IgniteConfiguration.JavaHome property are not set, we
can attempt automatic detection.
For Oracle JVM there is information in the registry at
{code}HKEY_LOCAL_MACHINE\Software\JavaSoft{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2865) Continuous query event passed to filter should be immutable for users.
Vladimir Ozerov created IGNITE-2865:
---
Summary: Continuous query event passed to filter should be
immutable for users.
Key: IGNITE-2865
URL: https://issues.apache.org/jira/browse/IGNITE-2865
Project: Ignite
Issue Type: Task
Components: cache
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Priority: Critical
Fix For: 1.6
*Problem*
When event is passed to continuous query filter, it can be used only in scope
of this method. The reason is that if filter returns {{false}}, the method
{{CacheContinuousQueryEntry.markFiltered()}} is called. This method *clears*
key and values.
*Solution*
We should not clear key and values. Instead, we should properly check for
{{FILTERED_ENTRY}} flag in all methods where {{key/newVal/oldVal/depInfo}} are
used. This includes generated {{readFrom()/writeTo()}} methods as well - their
manual change will be required.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] ignite pull request: Ignite 2806
Github user iveselovskiy closed the pull request at: https://github.com/apache/ignite/pull/547 --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-2864) Need update local store from primary and backups
Semen Boikov created IGNITE-2864: Summary: Need update local store from primary and backups Key: IGNITE-2864 URL: https://issues.apache.org/jira/browse/IGNITE-2864 Project: Ignite Issue Type: Bug Components: cache Reporter: Semen Boikov Assignee: Anton Vinogradov Fix For: 1.6 Now cache local store is updated only from primary nodes, this means that data can be lost if primary node is not re-started after crash. Need fix it and update store from primaries and backups if store is local (for both tx and atomic caches). This test should work: - cache with 1 backup, two server nodes - execute cache put for key K - stop both nodes - restart only node which was backup for K - load data from local sore, update for K should be restored -- This message was sent by Atlassian JIRA (v6.3.4#6332)
