Re: Switching back to review-then-commit process

[Denis Magda]

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

[Denis Magda]

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

[Dmitriy Setrakyan]

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

[ptupitsyn]

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 (JIRA)]

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

[Branko Čibej]

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

[Alexey Kuznetsov]

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

[Denis Magda]

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

[Pavel Tupitsyn]

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

[Sergi Vladykin]

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 (JIRA)]

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 (JIRA)]

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 (JIRA)]

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

[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

[GitHub] ignite pull request: IGNITE-1957 .NET: Collections, dictionaries, ...

[asfgit]

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 (JIRA)]

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 (JIRA)]

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

[iveselovskiy]

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 (JIRA)]

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)