[jira] [Assigned] (IGNITE-6013) Web agent: refactor processing response from cluster

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-6013:


Assignee: Andrey Novikov  (was: Alexey Kuznetsov)

Please review.

> Web agent: refactor processing response from cluster
> 
>
> Key: IGNITE-6013
> URL: https://issues.apache.org/jira/browse/IGNITE-6013
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> RestExecutor.sendRequest() contain following code:
> {code}
> 
> try (Response resp = 
> httpClient.newCall(reqBuilder.build()).execute()) {
> String content = resp.body().string();
> if (resp.isSuccessful()) {
> JsonNode node = mapper.readTree(content);
>  
> {code}
> Problems: 
> # String content = resp.body().string(); >> Generate not needed String.
> # JsonNode node = mapper.readTree(content);  >> Generates a big tree of 
> JsonNodes
>  
> Could be fixed like:
> RestResponseHolder res = MAPPER.readValue(resp.body().byteStream(), 
> RestResponseHolder.class); 
> Where for RestResponseHolder should also created optimized 
> RestResponseHolderDeserializer that will extract response as String without 
> building tree of JsonNodes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-5912) [Redis] EXPIRE/PEXPIRE on keys

[Roman Shtykh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Shtykh closed IGNITE-5912.


> [Redis] EXPIRE/PEXPIRE on keys
> --
>
> Key: IGNITE-5912
> URL: https://issues.apache.org/jira/browse/IGNITE-5912
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>  Labels: redis
> Fix For: 2.2
>
>
> https://redis.io/commands/expire
> https://redis.io/commands/pexpire



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5912) [Redis] EXPIRE/PEXPIRE on keys

[Roman Shtykh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Shtykh updated IGNITE-5912:
-
Labels: redis  (was: )

> [Redis] EXPIRE/PEXPIRE on keys
> --
>
> Key: IGNITE-5912
> URL: https://issues.apache.org/jira/browse/IGNITE-5912
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>  Labels: redis
> Fix For: 2.2
>
>
> https://redis.io/commands/expire
> https://redis.io/commands/pexpire



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5912) [Redis] EXPIRE/PEXPIRE on keys

[Roman Shtykh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Shtykh updated IGNITE-5912:
-
Fix Version/s: 2.2

> [Redis] EXPIRE/PEXPIRE on keys
> --
>
> Key: IGNITE-5912
> URL: https://issues.apache.org/jira/browse/IGNITE-5912
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>  Labels: redis
> Fix For: 2.2
>
>
> https://redis.io/commands/expire
> https://redis.io/commands/pexpire



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5912) [Redis] EXPIRE/PEXPIRE on keys

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120898#comment-16120898
 ] 

ASF GitHub Bot commented on IGNITE-5912:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2383


> [Redis] EXPIRE/PEXPIRE on keys
> --
>
> Key: IGNITE-5912
> URL: https://issues.apache.org/jira/browse/IGNITE-5912
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> https://redis.io/commands/expire
> https://redis.io/commands/pexpire



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5983) REST: Memory policy metrics should be available via REST.

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-5983:

Issue Type: Improvement  (was: New Feature)

> REST: Memory policy metrics should be available via REST.
> -
>
> Key: IGNITE-5983
> URL: https://issues.apache.org/jira/browse/IGNITE-5983
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrew Mashenkov
>
> For now it is possible to get some of cache metrics via REST, but not memory 
> metrics.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120600#comment-16120600
 ] 

ASF GitHub Bot commented on IGNITE-5097:


Github user daradurvs closed the pull request at:

https://github.com/apache/ignite/pull/1902


> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.2
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120594#comment-16120594
 ] 

ASF GitHub Bot commented on IGNITE-3682:


Github user daradurvs closed the pull request at:

https://github.com/apache/ignite/pull/1652


> GridFunc: move all inner anonymous classes to separate top-level classes.
> -
>
> Key: IGNITE-3682
> URL: https://issues.apache.org/jira/browse/IGNITE-3682
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important
> Fix For: 2.0
>
>
> Otherwise almost any change to class {{GridFunc}} will lead to serialization 
> issues because we have no control over inner class names.
> E.g. if removed single anonymous class, another anonymous class might change 
> it's name from {{GridFunc$4}} to {{GridFunc$3}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3422) No way to control object initialization during deserialization/unmarshalling

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120591#comment-16120591
 ] 

ASF GitHub Bot commented on IGNITE-3422:


Github user daradurvs closed the pull request at:

https://github.com/apache/ignite/pull/1533


> No way to control object initialization during deserialization/unmarshalling 
> -
>
> Key: IGNITE-3422
> URL: https://issues.apache.org/jira/browse/IGNITE-3422
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, general
>Affects Versions: 1.6
>Reporter: Denis Magda
> Fix For: 2.2
>
>
> Presently there is no way to control instantiation of a {{BinaryObject}} that 
> is being deserialized. The object is created using 
> {{BinaryClassDescriptor#newInstance}} all the time.
> It makes sense to add {{BinaryConfiguration.setInitializationFactory()}} 
> method that will provide with such support.
> Use case and details are provided in this discussion
> http://apache-ignite-users.70518.x6.nabble.com/Properly-Immutable-Keys-values-with-Binary-objects-tp6082.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5882) Duplicated dependency in pom.xml of core module

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120583#comment-16120583
 ] 

ASF GitHub Bot commented on IGNITE-5882:


Github user daradurvs closed the pull request at:

https://github.com/apache/ignite/pull/2366


> Duplicated dependency in pom.xml of core module
> ---
>
> Key: IGNITE-5882
> URL: https://issues.apache.org/jira/browse/IGNITE-5882
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> {code}
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.ignite:ignite-core:jar:2.2.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must 
> be unique: com.google.guava:guava:jar -> version 14.0.1 vs ${guava.version} @ 
> line 215, column 21
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5995) ODBC: SQLGetData gets data for the next row instead of current

[Sergey Kalashnikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120532#comment-16120532
 ] 

Sergey Kalashnikov commented on IGNITE-5995:


[~isapego],
Looks good to me.

> ODBC: SQLGetData gets data for the next row instead of current
> --
>
> Key: IGNITE-5995
> URL: https://issues.apache.org/jira/browse/IGNITE-5995
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> {{SQLGetData}} when called after {{SQLFetch}} should retrieve data from the 
> same row as {{SQLFetch}}. But currently, {{SQLGetData}} retrieves data from 
> the next row.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5736) Add test of backward-compatibility

[Vyacheslav Daradur (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120293#comment-16120293
 ] 

Vyacheslav Daradur edited comment on IGNITE-5736 at 8/9/17 5:19 PM:


[Link to VarintArraysSizeCompatibilityTest 
only.|https://github.com/daradurvs/ignite/blob/44e50af75b438b3524babe93b0fa64067bb26105/modules/compatibility/src/test/java/org/apache/ignite/compatibility/binary/VarintArraysSizeCompatibilityTest.java]


was (Author: daradurvs):
[Link to VarintArraysSizeCompatibilityTest 
only.|https://github.com/dradurvs/ignite/blob/44e50af75b438b3524babe93b0fa64067bb26105/modules/compatibility/src/test/java/org/apache/ignite/compatibility/binary/VarintArraysSizeCompatibilityTest.java]

> Add test of backward-compatibility
> --
>
> Key: IGNITE-5736
> URL: https://issues.apache.org/jira/browse/IGNITE-5736
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> Need to add unit-test to test compatibility with AI 2.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (IGNITE-5736) Add test of backward-compatibility

[Vyacheslav Daradur (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Daradur updated IGNITE-5736:
---
Comment: was deleted

(was: [Link to VarintArraysSizeCompatibilityTest 
only.|https://github.com/daradurvs/ignite/blob/c1cddffc986a0f4e3a41a3074f72bb5bf115ef37/modules/core/src/test/java/org/apache/ignite/internal/binary/VarintArraysSizeCompatibilityTest.java])

> Add test of backward-compatibility
> --
>
> Key: IGNITE-5736
> URL: https://issues.apache.org/jira/browse/IGNITE-5736
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> Need to add unit-test to test compatibility with AI 2.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5736) Add test of backward-compatibility

[Vyacheslav Daradur (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120293#comment-16120293
 ] 

Vyacheslav Daradur commented on IGNITE-5736:


[Link to VarintArraysSizeCompatibilityTest 
only.|https://github.com/dradurvs/ignite/blob/44e50af75b438b3524babe93b0fa64067bb26105/modules/compatibility/src/test/java/org/apache/ignite/compatibility/binary/VarintArraysSizeCompatibilityTest.java]

> Add test of backward-compatibility
> --
>
> Key: IGNITE-5736
> URL: https://issues.apache.org/jira/browse/IGNITE-5736
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> Need to add unit-test to test compatibility with AI 2.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120271#comment-16120271
 ] 

ASF GitHub Bot commented on IGNITE-5097:


GitHub user daradurvs opened a pull request:

https://github.com/apache/ignite/pull/2425

IGNITE-5097 BinaryMarshaller should write ints in "varint" encoding where 
it makes sense



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/daradurvs/ignite ignite-5736-module

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2425.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 #2425


commit efbac32e650d603e18ea405bee626589ac237f61
Author: Vyacheslav Daradur 
Date:   2017-08-09T14:05:29Z

IGNITE-5732 Provide API to test compatibility with old releases (#20)

commit 0a7ffcce6527111a68568da0a6d22d4a1eb306a4
Author: Vyacheslav Daradur 
Date:   2017-08-09T14:09:08Z

IGNITE-5097 BinaryMarshaller should write ints in "varint" encoding where 
it makes sense (#21)

commit 6b34d93609bc2087b77d7b44a0665ea160965e4e
Author: Vyacheslav Daradur 
Date:   2017-08-09T17:08:50Z

ignite-5736: added VarintArraysSizeCompatibilityTest




> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.2
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5655) Introduce pluggable string encoder/decoder

[Andrey Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120193#comment-16120193
 ] 

Andrey Kuznetsov commented on IGNITE-5655:
--

[~devozerov], please review my changes.

> Introduce pluggable string encoder/decoder
> --
>
> Key: IGNITE-5655
> URL: https://issues.apache.org/jira/browse/IGNITE-5655
> Project: Ignite
>  Issue Type: New Feature
>  Components: binary
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Andrey Kuznetsov
> Fix For: 2.2
>
>
> Currently binary marshaller encodes strings in UTF-8. However, sometimes it 
> makes sense to serialize strings with different encodings to save space. 
> Let's add global property to control String encoding and customize our binary 
> protocol to support it. For instance, we can add another flag 
> {{ENCODED_STRING}}, which will write strings as follows:
> [flag][encoding_flag][str_len][str_bytes]
> First implementation should set preferred encoding for strings in 
> BinaryConfiguration. This setting is optional, default encoding is UTF-8. 
> Currently, the same BinaryConfiguration is used for all cluster nodes, thus 
> no encoding clashes are possible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5655) Introduce pluggable string encoder/decoder

[Andrey Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120193#comment-16120193
 ] 

Andrey Kuznetsov edited comment on IGNITE-5655 at 8/9/17 4:29 PM:
--

[~vozerov], please review my changes.


was (Author: andrey-kuznetsov):
[~devozerov], please review my changes.

> Introduce pluggable string encoder/decoder
> --
>
> Key: IGNITE-5655
> URL: https://issues.apache.org/jira/browse/IGNITE-5655
> Project: Ignite
>  Issue Type: New Feature
>  Components: binary
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Andrey Kuznetsov
> Fix For: 2.2
>
>
> Currently binary marshaller encodes strings in UTF-8. However, sometimes it 
> makes sense to serialize strings with different encodings to save space. 
> Let's add global property to control String encoding and customize our binary 
> protocol to support it. For instance, we can add another flag 
> {{ENCODED_STRING}}, which will write strings as follows:
> [flag][encoding_flag][str_len][str_bytes]
> First implementation should set preferred encoding for strings in 
> BinaryConfiguration. This setting is optional, default encoding is UTF-8. 
> Currently, the same BinaryConfiguration is used for all cluster nodes, thus 
> no encoding clashes are possible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5986) Fix failed test in .NET suite.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-5986:
-
Attachment: (was: Fix_Lucene_index_closing_bug_.patch)

> Fix failed test in .NET suite.
> --
>
> Key: IGNITE-5986
> URL: https://issues.apache.org/jira/browse/IGNITE-5986
> Project: Ignite
>  Issue Type: Test
>  Components: cache, platforms
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: ignite.log
>
>
> Preface:
> I've found we use closeQuiet() method in LuceneIndex.close() that suppress 
> exceptions. 
> So, this is why we have no issues here before.
> I'd think when index is closing, it is expected that all queries being 
> cancelled and at the moment all QueryCursors (which use IndexReaders) has 
> been closed already.
> But I' observe it is not true in some cases.
> Looking at GridCacheProcessor.stopCache() method we call onCacheStop()-> 
> unregisterCache -> table.onDrop() -> luceneIdx.close().
> Looks like someone forget to close Cursor or\and Cursor wasn't closed during 
> query cancelation.
> We have to investigate this and 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (IGNITE-5986) Fix failed test in .NET suite.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-5986:
-
Comment: was deleted

(was: Patch prevent node failure on stop attached.
But we still have an issue with query stopping and index closing order.)

> Fix failed test in .NET suite.
> --
>
> Key: IGNITE-5986
> URL: https://issues.apache.org/jira/browse/IGNITE-5986
> Project: Ignite
>  Issue Type: Test
>  Components: cache, platforms
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: ignite.log
>
>
> Preface:
> I've found we use closeQuiet() method in LuceneIndex.close() that suppress 
> exceptions. 
> So, this is why we have no issues here before.
> I'd think when index is closing, it is expected that all queries being 
> cancelled and at the moment all QueryCursors (which use IndexReaders) has 
> been closed already.
> But I' observe it is not true in some cases.
> Looking at GridCacheProcessor.stopCache() method we call onCacheStop()-> 
> unregisterCache -> table.onDrop() -> luceneIdx.close().
> Looks like someone forget to close Cursor or\and Cursor wasn't closed during 
> query cancelation.
> We have to investigate this and 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-4707) Add documentation for HA IGFS client

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114207#comment-16114207
 ] 

Taras Ledkov edited comment on IGNITE-4707 at 8/9/17 4:27 PM:
--

Suggests edit for https://apacheignite-fs.readme.io/docs/file-system is done.
The [High Availability IGFS 
Client|https://apacheignite-fs.readme.io/docs/file-system#section-high-availability-igfs-client]
 section is added.


was (Author: tledkov-gridgain):
Suggests edit for https://apacheignite-fs.readme.io/docs/file-system is done.

> Add documentation for HA IGFS client
> 
>
> Key: IGNITE-4707
> URL: https://issues.apache.org/jira/browse/IGNITE-4707
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, igfs
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Minor
> Fix For: 2.2
>
>
> We need to document HA feature added in IGNITE-2356.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-4707) Add documentation for HA IGFS client

[Taras Ledkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Taras Ledkov resolved IGNITE-4707.
--
Resolution: Fixed

> Add documentation for HA IGFS client
> 
>
> Key: IGNITE-4707
> URL: https://issues.apache.org/jira/browse/IGNITE-4707
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, igfs
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Minor
> Fix For: 2.2
>
>
> We need to document HA feature added in IGNITE-2356.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5986) Fix failed test in .NET suite.

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120175#comment-16120175
 ] 

Andrew Mashenkov commented on IGNITE-5986:
--

Queries with leading wildcard was disabled by default in one of 4.x Lucene 
version.

Fix bug when indexReader wasn't closed properly if query parsing throws 
exception.

> Fix failed test in .NET suite.
> --
>
> Key: IGNITE-5986
> URL: https://issues.apache.org/jira/browse/IGNITE-5986
> Project: Ignite
>  Issue Type: Test
>  Components: cache, platforms
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: Fix_Lucene_index_closing_bug_.patch, ignite.log
>
>
> Preface:
> I've found we use closeQuiet() method in LuceneIndex.close() that suppress 
> exceptions. 
> So, this is why we have no issues here before.
> I'd think when index is closing, it is expected that all queries being 
> cancelled and at the moment all QueryCursors (which use IndexReaders) has 
> been closed already.
> But I' observe it is not true in some cases.
> Looking at GridCacheProcessor.stopCache() method we call onCacheStop()-> 
> unregisterCache -> table.onDrop() -> luceneIdx.close().
> Looks like someone forget to close Cursor or\and Cursor wasn't closed during 
> query cancelation.
> We have to investigate this and 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6018) Introduce WAL backward compatibility for new DataPage insert/update records

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-6018:
---

 Summary: Introduce WAL backward compatibility for new DataPage 
insert/update records
 Key: IGNITE-6018
 URL: https://issues.apache.org/jira/browse/IGNITE-6018
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
Priority: Blocker
 Fix For: 2.2


Once we store reference to DataRecord for DataPage insert/update records we 
should be able to read/write both versions of that records (with reference or 
with payload) for backward compatibility purposes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6016) Get rid of checking topology hash in ackTopology

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-6016:
---
Labels: MakeTeamcityGreenAgain  (was: )

> Get rid of checking topology hash in ackTopology
> 
>
> Key: IGNITE-6016
> URL: https://issues.apache.org/jira/browse/IGNITE-6016
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Alexey Goncharuk
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> We check topologyHash in ackTopology in order to avoid printing "Topology 
> snapshot" message twice. It's redundant - we can just atomically increase 
> topology version with GridAtomicLong#setIfGreater.
> It's the only usage of topology hash in Ignite, so we should remove it with 
> all related tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6016) Get rid of checking topology hash in ackTopology

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120159#comment-16120159
 ] 

ASF GitHub Bot commented on IGNITE-6016:


GitHub user glukos opened a pull request:

https://github.com/apache/ignite/pull/2424

IGNITE-6016 Get rid of checking topology hash in ackTopology



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6016

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2424.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 #2424


commit 2d409a7f9a52c6769e2f0b7858e49691d04313d6
Author: Ivan Rakov 
Date:   2017-08-09T16:09:06Z

IGNITE-6016 Get rid of checking topology hash in ackTopology




> Get rid of checking topology hash in ackTopology
> 
>
> Key: IGNITE-6016
> URL: https://issues.apache.org/jira/browse/IGNITE-6016
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.2
>
>
> We check topologyHash in ackTopology in order to avoid printing "Topology 
> snapshot" message twice. It's redundant - we can just atomically increase 
> topology version with GridAtomicLong#setIfGreater.
> It's the only usage of topology hash in Ignite, so we should remove it with 
> all related tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6016) Get rid of checking topology hash in ackTopology

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov reassigned IGNITE-6016:
--

Assignee: Alexey Goncharuk  (was: Ivan Rakov)

> Get rid of checking topology hash in ackTopology
> 
>
> Key: IGNITE-6016
> URL: https://issues.apache.org/jira/browse/IGNITE-6016
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Alexey Goncharuk
> Fix For: 2.2
>
>
> We check topologyHash in ackTopology in order to avoid printing "Topology 
> snapshot" message twice. It's redundant - we can just atomically increase 
> topology version with GridAtomicLong#setIfGreater.
> It's the only usage of topology hash in Ignite, so we should remove it with 
> all related tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6017) Ignite IGFS: IgfsStreamsSelfTest#testCreateFileFragmented fails

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-6017:
---

 Summary: Ignite IGFS: IgfsStreamsSelfTest#testCreateFileFragmented 
fails
 Key: IGNITE-6017
 URL: https://issues.apache.org/jira/browse/IGNITE-6017
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Pavel Kovalenko
Priority: Minor
 Fix For: 2.2


Failure is almost can't be reproduced locally.

Suppose it is the same problem as in IGNITE-5957 .

{noformat}
junit.framework.AssertionFailedError: expected:<2> but was:<1>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at junit.framework.TestCase.assertEquals(TestCase.java:409)
at 
org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest.testCreateFileFragmented(IgfsStreamsSelfTest.java:264)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
Aug 09, 2017 1:15:56 AM org.apache.ignite.logger.java.JavaLogger error
SEVERE: DataStreamer operation failed.
class org.apache.ignite.IgniteCheckedException: Data streamer has been 
cancelled: DataStreamerImpl 
[rcvr=org.apache.ignite.internal.processors.datastreamer.DataStreamerCacheUpdaters$BatchedSorted@13c54950,
 ioPlcRslvr=null, cacheName=igfs-internal-igfs-data, bufSize=512, 
parallelOps=16, timeout=-1, autoFlushFreq=0, 
bufMappings={908d1a4c-b352-4af5-b039-ded60c20=Buffer [node=TcpDiscoveryNode 
[id=908d1a4c-b352-4af5-b039-ded60c20, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1502241356486, loc=true, ver=2.2.0#19700101-sha1:, 
isClient=false], isLocNode=true, idGen=0, 
sem=java.util.concurrent.Semaphore@2bdbd7f0[Permits = 16], 
batchTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=0], entriesCnt=1, 
locFutsSize=0, reqsSize=0]}, cacheObjProc=GridProcessorAdapter [], 
cacheObjCtx=org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryContext@6e3de40e,
 cancelled=true, failCntr=0, activeFuts=GridConcurrentHashSet 
[elements=[GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null, 
hash=431192362], GridFutureAdapter [ignoreInterrupts=false, state=INIT, 
res=null, hash=625896337], GridFutureAdapter [ignoreInterrupts=false, 
state=INIT, res=null, hash=1440203156]]], jobPda=null, depCls=null, 
fut=DataStreamerFuture [super=GridFutureAdapter [ignoreInterrupts=false, 
state=DONE, res=null, hash=1612913644]], publicFut=IgniteFuture 
[orig=DataStreamerFuture [super=GridFutureAdapter [ignoreInterrupts=false, 
state=DONE, res=null, hash=1612913644]]], disconnectErr=null, closed=true, 
lastFlushTime=1502241356435, skipStore=false, keepBinary=false, maxRemapCnt=32, 
remapSem=java.util.concurrent.Semaphore@194e0ba1[Permits = 2147483647], 
remapOwning=false]
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$5.apply(DataStreamerImpl.java:865)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$5.apply(DataStreamerImpl.java:834)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:461)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onNodeLeft(DataStreamerImpl.java:1757)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$6.run(DataStreamerImpl.java:952)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6687)
at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:817)
at 

[jira] [Commented] (IGNITE-5943) Communication. Server node may reject client connection during massive clients join

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120139#comment-16120139
 ] 

ASF GitHub Bot commented on IGNITE-5943:


GitHub user EdShangGG opened a pull request:

https://github.com/apache/ignite/pull/2423

IGNITE-5943



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite IGNITE-5943

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2423.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 #2423


commit 2d93a7c11871a2b23cfb2e6f9854dccb48eac4f1
Author: Andrey Novikov 
Date:   2017-08-03T03:42:08Z

IGNITE-5888 Web Console: Fixed maven project generation.

commit 36787e149693103fa22ba4093259d2fd8425689a
Author: Andrey Novikov 
Date:   2017-08-03T03:45:59Z

IGNITE-5906 Fixed race on activities merge.

commit 9e9f1d1e4cdcb3ade018f3eabcf2b2d10a7c003b
Author: tledkov-gridgain 
Date:   2017-08-04T08:16:52Z

IGNITE-5920: Fixed CacheClientBinaryQueryExample": set 
CacheKeyConfiguration explicitly to enable affinity co-location. This closes 
#2389.

commit 944056e5431b6018bb653c563db1356f0148fb9a
Author: anovikov 
Date:   2017-08-04T11:10:36Z

IGNITE-5908 Restore splash.

commit a1652b8f7748d3bf1e42437f9ad36f6f44e19bf5
Author: Sergey Chugunov 
Date:   2017-08-07T08:34:01Z

IGNITE-5950 incorrect assertion fixed

commit cfa5ac269c37718191be42d5554637b78c2a7466
Author: Eduard Shangareev 
Date:   2017-08-09T15:57:24Z

IGNITE-5943 Communication. Server node may reject client connection during 
massive clients join




> Communication. Server node may reject client connection during massive 
> clients join
> ---
>
> Key: IGNITE-5943
> URL: https://issues.apache.org/jira/browse/IGNITE-5943
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.2
>
>
> There is a race between a client join discovery event on server nodes and the 
> moment when a client starts to establish outgoing communication connections. 
> It would cause to rejecting communication connections on server nodes (for 
> example. on requesting data from caches).
> The issue happens on really big topologies (> 300 nodes) or when many clients 
> join simultaneously.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6016) Get rid of checking topology hash in ackTopology

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-6016:
---
Description: 
We check topologyHash in ackTopology in order to avoid printing "Topology 
snapshot" message twice. It's redundant - we can just atomically increase 
topology version with GridAtomicLong#setIfGreater.
It's the only usage of topology hash in Ignite, so we should remove it with all 
related tests.

  was:We check topologyHash in ackTopology in order to avoid printing "Topology 
snapshot" message twice. It's redundant - we can just atomically increase 
topology version with GridAtomicLong#setIfGreater.


> Get rid of checking topology hash in ackTopology
> 
>
> Key: IGNITE-6016
> URL: https://issues.apache.org/jira/browse/IGNITE-6016
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.2
>
>
> We check topologyHash in ackTopology in order to avoid printing "Topology 
> snapshot" message twice. It's redundant - we can just atomically increase 
> topology version with GridAtomicLong#setIfGreater.
> It's the only usage of topology hash in Ignite, so we should remove it with 
> all related tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5865) TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120103#comment-16120103
 ] 

Dmitriy Pavlov commented on IGNITE-5865:


Hi [~VitaliyB], 

thank you for your reply. It is OK if test results were checked manually
I can see in PR test is passing 
https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=testDetails=-6871793332841198308_Ignite20Tests=pull%2F2415%2Fhead

> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing
> -
>
> Key: IGNITE-5865
> URL: https://issues.apache.org/jira/browse/IGNITE-5865
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Vitaliy Biryukov 
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-failure
> Fix For: 2.2
>
>
> Test is flaky.
> Also there is always failing test in suite: 
> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitionedNear
> TC build result: 
> http://ci.ignite.apache.org/viewLog.html?buildId=744109=buildResultsDiv=Ignite20Tests_IgniteCacheDeadlockDetection
> Stacktrace: 
> {noformat}
> [2017-07-28 
> 03:31:52,827][ERROR][grid-timeout-worker-#31%transactions.TxOptimisticDeadlockDetectionTest0%][IgniteTxHandler]
>  Failed to prepare DHT transaction: GridDhtTxLocal 
> [nearNodeId=d005de76-4378-4cd5-ad7e-f00593a2, 
> nearFutId=aab9f378d51-37ca90c9-03f5-417c-9731-2c29810e3cc0, nearMiniId=1, 
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], 
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], 
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxStateImpl [activeCacheIds=GridIntList [idx=1, 
> arr=[94416770]], recovery=false, txMap=[IgniteTxEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770, txKey=IgniteTxKey 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=694, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], val=null, 
> startVer=1501212673290, ver=GridCacheVersion [topVer=112692678, 
> order=1501212673290, nodeOrder=1], hash=-1228408719, 
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc 
> [locs=[GridCacheMvccCandidate [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, 
> ver=GridCacheVersion [topVer=112692678, order=1501212673287, nodeOrder=1], 
> threadId=846, id=520, topVer=AffinityTopologyVersion [topVer=8, 
> minorTopVer=8], reentry=null, 
> otherNodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673287, nodeOrder=1], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null], GridCacheMvccCandidate 
> [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, ver=GridCacheVersion 
> [topVer=112692678, order=1501212673314, nodeOrder=1], threadId=847, id=521, 
> topVer=AffinityTopologyVersion [topVer=8, minorTopVer=8], reentry=null, 
> otherNodeId=d005de76-4378-4cd5-ad7e-f00593a2, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=GridCacheVersion [topVer=112692678, 
> order=1501212673287, nodeOrder=1], serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=0|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null]], rmts=null]], flags=2]]], prepared=1, 
> locked=false, nodeId=null, locMapped=false, expiryPlc=null, 
> transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null, 
> 

[jira] [Commented] (IGNITE-5963) Ignite Cache 6: Flaky failure IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120098#comment-16120098
 ] 

ASF GitHub Bot commented on IGNITE-5963:


GitHub user nizhikov opened a pull request:

https://github.com/apache/ignite/pull/2422

IGNITE-5963: Add additional check to Thread.sleep to make test correc…

…t in all cases.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nizhikov/ignite IGNITE-5963

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2422.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 #2422


commit e12de1f4471de5ae46eb35f9dbb275403a8bf4ca
Author: Nikolay Izhikov 
Date:   2017-08-09T15:37:09Z

IGNITE-5963: Add additional check to Thread.sleep to make test correct in 
all cases.




>  Ignite Cache 6: Flaky failure 
> IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC
> --
>
> Key: IGNITE-5963
> URL: https://issues.apache.org/jira/browse/IGNITE-5963
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Test sometimes fails on teamcity, please see
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-6026696383836355176=testDetails
> {noformat}
> java.lang.AssertionError: Exception has not been thrown.
> at 
> org.apache.ignite.testframework.GridTestUtils.assertThrowsWithCause(GridTestUtils.java:425)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:464)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:455)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:697)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:669)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnSuspend(IgniteOptimisticTxSuspendResumeTest.java:455)
> {noformat}
> Test was created under issue IGNITE-5712
> Does not reprocuced locally (30 runs on Win10).
> But on CI server success rate is 94%



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6016) Get rid of checking topology hash in ackTopology

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-6016:
--

 Summary: Get rid of checking topology hash in ackTopology
 Key: IGNITE-6016
 URL: https://issues.apache.org/jira/browse/IGNITE-6016
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.1
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.2


We check topologyHash in ackTopology in order to avoid printing "Topology 
snapshot" message twice. It's redundant - we can just atomically increase 
topology version with GridAtomicLong#setIfGreater.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6015) Test fail in Ignite Cache 2: GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-6015:
---
Affects Version/s: 2.1

> Test fail in Ignite Cache 2: 
> GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform 
> --
>
> Key: IGNITE-6015
> URL: https://issues.apache.org/jira/browse/IGNITE-6015
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Govorukhin
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testGetAndTransform, timeout=30]
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1949)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:156)
> at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:82)
> at 
> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:82)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:951)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:831)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:3



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6015) Test fail in Ignite Cache 2: GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform

[Dmitriy Govorukhin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Govorukhin updated IGNITE-6015:
---
Labels: MakeTeamcityGreenAgain  (was: )

> Test fail in Ignite Cache 2: 
> GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform 
> --
>
> Key: IGNITE-6015
> URL: https://issues.apache.org/jira/browse/IGNITE-6015
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Govorukhin
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testGetAndTransform, timeout=30]
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1949)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:156)
> at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:82)
> at 
> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:82)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:951)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:831)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:3



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6015) Test fail in Ignite Cache 2: GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-6015:
--

 Summary: Test fail in Ignite Cache 2: 
GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform 
 Key: IGNITE-6015
 URL: https://issues.apache.org/jira/browse/IGNITE-6015
 Project: Ignite
  Issue Type: Test
Reporter: Dmitriy Govorukhin
 Fix For: 2.2


java.util.concurrent.TimeoutException: Test has been timed out 
[test=testGetAndTransform, timeout=30]
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1949)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:156)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:82)
at 
org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:82)
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:951)
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:831)
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:3



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5963) Ignite Cache 6: Flaky failure IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC

[Nikolay Izhikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov reassigned IGNITE-5963:
---

Assignee: Nikolay Izhikov

>  Ignite Cache 6: Flaky failure 
> IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC
> --
>
> Key: IGNITE-5963
> URL: https://issues.apache.org/jira/browse/IGNITE-5963
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Test sometimes fails on teamcity, please see
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-6026696383836355176=testDetails
> {noformat}
> java.lang.AssertionError: Exception has not been thrown.
> at 
> org.apache.ignite.testframework.GridTestUtils.assertThrowsWithCause(GridTestUtils.java:425)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:464)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:455)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:697)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:669)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnSuspend(IgniteOptimisticTxSuspendResumeTest.java:455)
> {noformat}
> Test was created under issue IGNITE-5712
> Does not reprocuced locally (30 runs on Win10).
> But on CI server success rate is 94%



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5986) Fix failed test in .NET suite.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-5986:
-
Attachment: ignite.log

PFA log from TC.

I see multiple issues with wrong text queries. Seems, some wildcard queries is 
not supported by Lucene.

We should fix texts as well as close iterator (query cursor) on query failure.

> Fix failed test in .NET suite.
> --
>
> Key: IGNITE-5986
> URL: https://issues.apache.org/jira/browse/IGNITE-5986
> Project: Ignite
>  Issue Type: Test
>  Components: cache, platforms
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: Fix_Lucene_index_closing_bug_.patch, ignite.log
>
>
> Preface:
> I've found we use closeQuiet() method in LuceneIndex.close() that suppress 
> exceptions. 
> So, this is why we have no issues here before.
> I'd think when index is closing, it is expected that all queries being 
> cancelled and at the moment all QueryCursors (which use IndexReaders) has 
> been closed already.
> But I' observe it is not true in some cases.
> Looking at GridCacheProcessor.stopCache() method we call onCacheStop()-> 
> unregisterCache -> table.onDrop() -> luceneIdx.close().
> Looks like someone forget to close Cursor or\and Cursor wasn't closed during 
> query cancelation.
> We have to investigate this and 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5865) TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing

[Vitaliy Biryukov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120048#comment-16120048
 ] 

Vitaliy Biryukov  commented on IGNITE-5865:
---

[~dpavlov],
Hi, muted tests are run too.
Please, take a look at these links:
[testDeadlocksPartitionedNear|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=8803221386026271009=testDetails]
[testDeadlocksPartitioned|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-6871793332841198308=testDetails]

> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing
> -
>
> Key: IGNITE-5865
> URL: https://issues.apache.org/jira/browse/IGNITE-5865
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Vitaliy Biryukov 
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-failure
> Fix For: 2.2
>
>
> Test is flaky.
> Also there is always failing test in suite: 
> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitionedNear
> TC build result: 
> http://ci.ignite.apache.org/viewLog.html?buildId=744109=buildResultsDiv=Ignite20Tests_IgniteCacheDeadlockDetection
> Stacktrace: 
> {noformat}
> [2017-07-28 
> 03:31:52,827][ERROR][grid-timeout-worker-#31%transactions.TxOptimisticDeadlockDetectionTest0%][IgniteTxHandler]
>  Failed to prepare DHT transaction: GridDhtTxLocal 
> [nearNodeId=d005de76-4378-4cd5-ad7e-f00593a2, 
> nearFutId=aab9f378d51-37ca90c9-03f5-417c-9731-2c29810e3cc0, nearMiniId=1, 
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], 
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], 
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxStateImpl [activeCacheIds=GridIntList [idx=1, 
> arr=[94416770]], recovery=false, txMap=[IgniteTxEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770, txKey=IgniteTxKey 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=694, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], val=null, 
> startVer=1501212673290, ver=GridCacheVersion [topVer=112692678, 
> order=1501212673290, nodeOrder=1], hash=-1228408719, 
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc 
> [locs=[GridCacheMvccCandidate [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, 
> ver=GridCacheVersion [topVer=112692678, order=1501212673287, nodeOrder=1], 
> threadId=846, id=520, topVer=AffinityTopologyVersion [topVer=8, 
> minorTopVer=8], reentry=null, 
> otherNodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673287, nodeOrder=1], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null], GridCacheMvccCandidate 
> [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, ver=GridCacheVersion 
> [topVer=112692678, order=1501212673314, nodeOrder=1], threadId=847, id=521, 
> topVer=AffinityTopologyVersion [topVer=8, minorTopVer=8], reentry=null, 
> otherNodeId=d005de76-4378-4cd5-ad7e-f00593a2, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=GridCacheVersion [topVer=112692678, 
> order=1501212673287, nodeOrder=1], serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=0|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null]], rmts=null]], flags=2]]], prepared=1, 
> locked=false, nodeId=null, locMapped=false, expiryPlc=null, 
> 

[jira] [Updated] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-5979:
---
Description: 
Example of failing  - 
http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497

{noformat}
junit.framework.AssertionFailedError: Failed to check value for key [key=72625, 
node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
was:<-1994497644>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.TestCase.assertEquals(TestCase.java:244)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
{noformat}

  was:Example of failing  - 
http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497


> [Test Failed]  
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync 
> 
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Example of failing  - 
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key 
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6004) SQL: add "inlineSize" to QuerySqlField annotation

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119881#comment-16119881
 ] 

Taras Ledkov edited comment on IGNITE-6004 at 8/9/17 2:51 PM:
--

Waits for [tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2420%2Fhead].

[~vozerov], [~skalashnikov], please review the patch.


was (Author: tledkov-gridgain):
Waits for [tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2420%2Fhead].

> SQL: add "inlineSize" to QuerySqlField annotation
> -
>
> Key: IGNITE-6004
> URL: https://issues.apache.org/jira/browse/IGNITE-6004
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> "inlineSize" is very important optimization allowing to avoid excessive data 
> page reads when using index. However, it can only be set through 
> {{QueryEntity}} -> {{QueryIndex}} chain, and cannot be set through 
> {{\@QuerySqlField}} annotation.
> Let's fix that and add {{int indexInlineSize}} parameter to that annotation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5736) Add test of backward-compatibility

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120026#comment-16120026
 ] 

ASF GitHub Bot commented on IGNITE-5736:


Github user daradurvs closed the pull request at:

https://github.com/apache/ignite/pull/2387


> Add test of backward-compatibility
> --
>
> Key: IGNITE-5736
> URL: https://issues.apache.org/jira/browse/IGNITE-5736
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> Need to add unit-test to test compatibility with AI 2.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5897) Ignite Cache Full API Multi JVM: 7 test failed in master

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120017#comment-16120017
 ] 

Dmitriy Pavlov commented on IGNITE-5897:


Passed in #904 builds 
https://ci.ignite.apache.org/viewLog.html?buildId=763326=buildResultsDiv=Ignite20Tests_IgniteCacheFullApiMultiJvm

> Ignite Cache Full API Multi JVM: 7 test failed in master
> 
>
> Key: IGNITE-5897
> URL: https://issues.apache.org/jira/browse/IGNITE-5897
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Dmitriy Pavlov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Failure on TC: 
> http://ci.ignite.apache.org/viewLog.html?buildId=749671=buildResultsDiv=Ignite20Tests_IgniteCacheFullApiMultiJvm#testNameId-6305397409161667157
> org.apache.ignite.internal.processors.cache.multijvm (7)
> - 
> GridCachePartitionedNearDisabledMultiJvmFullApiSelfTest.testTransformResourceInjection
>   
> - 
> GridCachePartitionedNearDisabledMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection
>
> - 
> GridCachePartitionedNearDisabledOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection
> 
> - GridCacheReplicatedMultiJvmFullApiSelfTest.testTransformResourceInjection   
> - 
> GridCacheReplicatedMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection
> 
> - 
> GridCacheReplicatedNearOnlyMultiJvmFullApiSelfTest.testTransformResourceInjection
>
> - 
> GridCacheReplicatedOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection
>  
> Stable reproducible locally
> First failure changes:
> http://ci.ignite.apache.org/viewLog.html?buildId=727280=buildChangesDiv=Ignite20Tests_IgniteCacheFullApiMultiJvm
> {noformat}
> IGNITE-5753: CPP Memory leak fixed.   Igor Sapego 
> IGNITE-5444: Collections.singletonList is not properly serialized by binary 
> marshaller. This closes #2217.andrey.mashenkov 
> ignite-5722 Cache entries stay in onheap after scan query execution for 
> OFFHEAP_TIRED cache with expiry policyAndrey Gura 
> ignite-5489 Fixed possible connection leaks when loadPreviousValue set to 
> truetikhonovnicolay 
> IGNITE-4831: Add an option to disable MBeans. This closes #2265.  
> andrey.mashenkov   
> {noformat}
> Stacktrace: 
> {noformat}
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] class 
> org.apache.ignite.IgniteCheckedException: java.lang.NullPointerException
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:327)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.load(GridCacheStoreManagerAdapter.java:282)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.readThrough(GridCacheMapEntry.java:445)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:699)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet(GridCacheMapEntry.java:461)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:389)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1213)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:668)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1034)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:410)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:459)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:121)
> [2017-08-01 16:27:28,330][INFO 

[jira] [Created] (IGNITE-6014) Add transaction prepare and commit markers to WAL

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-6014:


 Summary: Add transaction prepare and commit markers to WAL
 Key: IGNITE-6014
 URL: https://issues.apache.org/jira/browse/IGNITE-6014
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Affects Versions: 2.1
Reporter: Alexey Goncharuk
 Fix For: 2.2


This may be useful for various recovery procedures in the future



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5714) Context switching for pessimistic transactions

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-5714:


Assignee: Alexey Kuznetsov

> Context switching for pessimistic transactions
> --
>
> Key: IGNITE-5714
> URL: https://issues.apache.org/jira/browse/IGNITE-5714
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>
> Implement context switching for pessimistic transactions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-4767) rollback exception hides the origin exception (e.g. commit)

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103111#comment-16103111
 ] 

Dmitriy Pavlov edited comment on IGNITE-4767 at 8/9/17 2:36 PM:


Merged to master


was (Author: dpavlov):
Merged to master

Is to be resolved after PR to merged to master

> rollback exception hides the origin exception (e.g. commit)
> ---
>
> Key: IGNITE-4767
> URL: https://issues.apache.org/jira/browse/IGNITE-4767
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 1.8
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
> Fix For: 2.2
>
>
> There is too much code places like:
> {noformat}
> try {
>   return txFuture.get();
> }
> catch (IgniteCheckedException e) {
>   tx.rollbackAsync();
>   throw e;
> }
> {noformat}
> where an error upon rollback hides the actual exception {{e}}.
> This should be implemented in the way like try-with-resources does:
> {noformat}
> try {
>   return txFuture.get();
> }
> catch (IgniteCheckedException e1) {
>   try {
>   tx.rollbackAsync();
>   }
>   catch (Throwable inner) {
>   e.addSuppressed(inner);
>   }
>   throw e;
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-4767) rollback exception hides the origin exception (e.g. commit)

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103111#comment-16103111
 ] 

Dmitriy Pavlov edited comment on IGNITE-4767 at 8/9/17 2:35 PM:


Merged to master

Is to be resolved after PR to merged to master


was (Author: dpavlov):
Merged to 2.1.3

Is to be resolved after PR to merged to master

> rollback exception hides the origin exception (e.g. commit)
> ---
>
> Key: IGNITE-4767
> URL: https://issues.apache.org/jira/browse/IGNITE-4767
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 1.8
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
> Fix For: 2.2
>
>
> There is too much code places like:
> {noformat}
> try {
>   return txFuture.get();
> }
> catch (IgniteCheckedException e) {
>   tx.rollbackAsync();
>   throw e;
> }
> {noformat}
> where an error upon rollback hides the actual exception {{e}}.
> This should be implemented in the way like try-with-resources does:
> {noformat}
> try {
>   return txFuture.get();
> }
> catch (IgniteCheckedException e1) {
>   try {
>   tx.rollbackAsync();
>   }
>   catch (Throwable inner) {
>   e.addSuppressed(inner);
>   }
>   throw e;
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5865) TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119991#comment-16119991
 ] 

Dmitriy Pavlov commented on IGNITE-5865:


Hi, currently tests are muted on TC, see 
https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=mutedProblems_Ignite20Tests=__all_branches__
 for example

I suggest to re-run TC with umuted tests to find out if it is failing now 
TxDeadlockDetectionTestSuite

> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing
> -
>
> Key: IGNITE-5865
> URL: https://issues.apache.org/jira/browse/IGNITE-5865
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Vitaliy Biryukov 
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-failure
> Fix For: 2.2
>
>
> Test is flaky.
> Also there is always failing test in suite: 
> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitionedNear
> TC build result: 
> http://ci.ignite.apache.org/viewLog.html?buildId=744109=buildResultsDiv=Ignite20Tests_IgniteCacheDeadlockDetection
> Stacktrace: 
> {noformat}
> [2017-07-28 
> 03:31:52,827][ERROR][grid-timeout-worker-#31%transactions.TxOptimisticDeadlockDetectionTest0%][IgniteTxHandler]
>  Failed to prepare DHT transaction: GridDhtTxLocal 
> [nearNodeId=d005de76-4378-4cd5-ad7e-f00593a2, 
> nearFutId=aab9f378d51-37ca90c9-03f5-417c-9731-2c29810e3cc0, nearMiniId=1, 
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], 
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], 
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxStateImpl [activeCacheIds=GridIntList [idx=1, 
> arr=[94416770]], recovery=false, txMap=[IgniteTxEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770, txKey=IgniteTxKey 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=694, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], val=null, 
> startVer=1501212673290, ver=GridCacheVersion [topVer=112692678, 
> order=1501212673290, nodeOrder=1], hash=-1228408719, 
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc 
> [locs=[GridCacheMvccCandidate [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, 
> ver=GridCacheVersion [topVer=112692678, order=1501212673287, nodeOrder=1], 
> threadId=846, id=520, topVer=AffinityTopologyVersion [topVer=8, 
> minorTopVer=8], reentry=null, 
> otherNodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673287, nodeOrder=1], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null], GridCacheMvccCandidate 
> [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, ver=GridCacheVersion 
> [topVer=112692678, order=1501212673314, nodeOrder=1], threadId=847, id=521, 
> topVer=AffinityTopologyVersion [topVer=8, minorTopVer=8], reentry=null, 
> otherNodeId=d005de76-4378-4cd5-ad7e-f00593a2, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=GridCacheVersion [topVer=112692678, 
> order=1501212673287, nodeOrder=1], serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=0|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null]], rmts=null]], flags=2]]], prepared=1, 
> locked=false, nodeId=null, locMapped=false, expiryPlc=null, 
> transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null, 

[jira] [Commented] (IGNITE-5468) Need to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE on per query basis

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119987#comment-16119987
 ] 

Andrew Mashenkov commented on IGNITE-5468:
--

PR looks fine for me.

One thing bother me I've no idea to make better.
This is how we validate IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter and fallback 
to default if there is any issue.
Code looks too complex.

[~avinogradov] please take a look at it and merge if its ok for you.



> Need to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE on per query basis
> --
>
> Key: IGNITE-5468
> URL: https://issues.apache.org/jira/browse/IGNITE-5468
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.0
>Reporter: Yakov Zhdanov
>Assignee: Vitaliy Biryukov 
>Priority: Critical
> Fix For: 2.2
>
>
> Currently this property can be set via sys property only thus changing it 
> will require restart of the cluster. I think it is better to set it on 
> perquery basis with some default that is configured via cache configuration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-9) Need to implement IngniteReentrantReadWriteLock

[Alexey Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119973#comment-16119973
 ] 

Alexey Kuznetsov commented on IGNITE-9:
---

New implementation of ignite reentrant lock will be provided in 
https://issues.apache.org/jira/browse/IGNITE-4908
ignite reentrant read write lock should be based on this implementation.

> Need to implement IngniteReentrantReadWriteLock
> ---
>
> Key: IGNITE-9
> URL: https://issues.apache.org/jira/browse/IGNITE-9
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Alexey Kuznetsov
>
> See org.apache.ignite.IgniteLock for reference



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6013) Web agent: refactor processing response from cluster

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov updated IGNITE-6013:
-
Fix Version/s: 2.2

> Web agent: refactor processing response from cluster
> 
>
> Key: IGNITE-6013
> URL: https://issues.apache.org/jira/browse/IGNITE-6013
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>
> RestExecutor.sendRequest() contain following code:
> {code}
> 
> try (Response resp = 
> httpClient.newCall(reqBuilder.build()).execute()) {
> String content = resp.body().string();
> if (resp.isSuccessful()) {
> JsonNode node = mapper.readTree(content);
>  
> {code}
> Problems: 
> # String content = resp.body().string(); >> Generate not needed String.
> # JsonNode node = mapper.readTree(content);  >> Generates a big tree of 
> JsonNodes
>  
> Could be fixed like:
> RestResponseHolder res = MAPPER.readValue(resp.body().byteStream(), 
> RestResponseHolder.class); 
> Where for RestResponseHolder should also created optimized 
> RestResponseHolderDeserializer that will extract response as String without 
> building tree of JsonNodes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6013) Web agent: refactor processing response from cluster

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-6013:


 Summary: Web agent: refactor processing response from cluster
 Key: IGNITE-6013
 URL: https://issues.apache.org/jira/browse/IGNITE-6013
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov


RestExecutor.sendRequest() contain following code:
{code}

try (Response resp = httpClient.newCall(reqBuilder.build()).execute()) {
String content = resp.body().string();

if (resp.isSuccessful()) {
JsonNode node = mapper.readTree(content);
 
{code}

Problems: 
# String content = resp.body().string(); >> Generate not needed String.
# JsonNode node = mapper.readTree(content);  >> Generates a big tree of 
JsonNodes
 
Could be fixed like:
RestResponseHolder res = MAPPER.readValue(resp.body().byteStream(), 
RestResponseHolder.class); 

Where for RestResponseHolder should also created optimized 
RestResponseHolderDeserializer that will extract response as String without 
building tree of JsonNodes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-9) Need to implement IngniteReentrantReadWriteLock

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov updated IGNITE-9:
--
Attachment: (was: IgniteReentrantReadWriteLockSelfTest.java)

> Need to implement IngniteReentrantReadWriteLock
> ---
>
> Key: IGNITE-9
> URL: https://issues.apache.org/jira/browse/IGNITE-9
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Alexey Kuznetsov
>
> See org.apache.ignite.IgniteLock for reference



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5995) ODBC: SQLGetData gets data for the next row instead of current

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119961#comment-16119961
 ] 

ASF GitHub Bot commented on IGNITE-5995:


GitHub user isapego opened a pull request:

https://github.com/apache/ignite/pull/2421

IGNITE-5995: ODBC: Fix for SQLGetData



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-5995

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2421.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 #2421


commit af8c1a82977504378adabf35a8d58d444f81dfe9
Author: Igor Sapego 
Date:   2017-08-08T16:55:46Z

IGNITE-5995: Added tests.

commit 89064118f2e070de7785ce3cec251273d171ab0f
Author: Igor Sapego 
Date:   2017-08-08T17:50:44Z

IGNITE-5995: Fix for tests

commit f2ce7cee88bac5796c705fab297de1fb900a1bb0
Author: Igor Sapego 
Date:   2017-08-08T17:51:19Z

IGNITE-5995: Meta queries fixed




> ODBC: SQLGetData gets data for the next row instead of current
> --
>
> Key: IGNITE-5995
> URL: https://issues.apache.org/jira/browse/IGNITE-5995
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> {{SQLGetData}} when called after {{SQLFetch}} should retrieve data from the 
> same row as {{SQLFetch}}. But currently, {{SQLGetData}} retrieves data from 
> the next row.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6011) EntryProcessor can make data inconsistent if fails on TX cache.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-6011:
-
Description: 
I'd expect that with FULL_SYNC write mode and TX cache data always be 
consistent.
And if EntryProcessor fails on primary (or backup) node and pass on backup (or 
primary) then whole transaction will be rolled back.
But I observe old value on node where EP has failed and new value on other 
nodes.

PFA repro attached.

Looks like we should apply EP on lock phase and fail TX if there is any 
failures.

UPD: We should also check if ignite has an adequate behavior if possible when 
Error (not Exception) occurs, e.g. assert in user code.

  was:
I'd expect that with FULL_SYNC write mode and TX cache data always be 
consistent.
And if EntryProcessor fails on primary (or backup) node and pass on backup (or 
primary) then whole transaction will be rolled back.

But I observe old value on node where EP has failed and new value on other 
nodes.

PFA repro attached.


Looks like we should apply EP on lock phase and fail TX if there is any 
failures.


> EntryProcessor can make data inconsistent if fails on TX cache.
> ---
>
> Key: IGNITE-6011
> URL: https://issues.apache.org/jira/browse/IGNITE-6011
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Andrew Mashenkov
> Attachments: EntryProcessorBug.java
>
>
> I'd expect that with FULL_SYNC write mode and TX cache data always be 
> consistent.
> And if EntryProcessor fails on primary (or backup) node and pass on backup 
> (or primary) then whole transaction will be rolled back.
> But I observe old value on node where EP has failed and new value on other 
> nodes.
> PFA repro attached.
> Looks like we should apply EP on lock phase and fail TX if there is any 
> failures.
> UPD: We should also check if ignite has an adequate behavior if possible when 
> Error (not Exception) occurs, e.g. assert in user code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5986) Fix failed test in .NET suite.

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119944#comment-16119944
 ] 

Andrew Mashenkov edited comment on IGNITE-5986 at 8/9/17 2:06 PM:
--

Patch prevent node failure on stop attached.
But we still have an issue with query stopping and index closing order.


was (Author: amashenkov):
Patch prevent node failure on stop.
But we still have an issue with query stopping and index closing order.

> Fix failed test in .NET suite.
> --
>
> Key: IGNITE-5986
> URL: https://issues.apache.org/jira/browse/IGNITE-5986
> Project: Ignite
>  Issue Type: Test
>  Components: cache, platforms
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: Fix_Lucene_index_closing_bug_.patch
>
>
> Preface:
> I've found we use closeQuiet() method in LuceneIndex.close() that suppress 
> exceptions. 
> So, this is why we have no issues here before.
> I'd think when index is closing, it is expected that all queries being 
> cancelled and at the moment all QueryCursors (which use IndexReaders) has 
> been closed already.
> But I' observe it is not true in some cases.
> Looking at GridCacheProcessor.stopCache() method we call onCacheStop()-> 
> unregisterCache -> table.onDrop() -> luceneIdx.close().
> Looks like someone forget to close Cursor or\and Cursor wasn't closed during 
> query cancelation.
> We have to investigate this and 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5986) Fix failed test in .NET suite.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-5986:
-
Attachment: Fix_Lucene_index_closing_bug_.patch

Patch prevent node failure on stop.
But we still have an issue with query stopping and index closing order.

> Fix failed test in .NET suite.
> --
>
> Key: IGNITE-5986
> URL: https://issues.apache.org/jira/browse/IGNITE-5986
> Project: Ignite
>  Issue Type: Test
>  Components: cache, platforms
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: Fix_Lucene_index_closing_bug_.patch
>
>
> Preface:
> I've found we use closeQuiet() method in LuceneIndex.close() that suppress 
> exceptions. 
> So, this is why we have no issues here before.
> I'd think when index is closing, it is expected that all queries being 
> cancelled and at the moment all QueryCursors (which use IndexReaders) has 
> been closed already.
> But I' observe it is not true in some cases.
> Looking at GridCacheProcessor.stopCache() method we call onCacheStop()-> 
> unregisterCache -> table.onDrop() -> luceneIdx.close().
> Looks like someone forget to close Cursor or\and Cursor wasn't closed during 
> query cancelation.
> We have to investigate this and 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5986) Fix failed test in .NET suite.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov reassigned IGNITE-5986:


Assignee: Andrew Mashenkov

> Fix failed test in .NET suite.
> --
>
> Key: IGNITE-5986
> URL: https://issues.apache.org/jira/browse/IGNITE-5986
> Project: Ignite
>  Issue Type: Test
>  Components: cache, platforms
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Preface:
> I've found we use closeQuiet() method in LuceneIndex.close() that suppress 
> exceptions. 
> So, this is why we have no issues here before.
> I'd think when index is closing, it is expected that all queries being 
> cancelled and at the moment all QueryCursors (which use IndexReaders) has 
> been closed already.
> But I' observe it is not true in some cases.
> Looking at GridCacheProcessor.stopCache() method we call onCacheStop()-> 
> unregisterCache -> table.onDrop() -> luceneIdx.close().
> Looks like someone forget to close Cursor or\and Cursor wasn't closed during 
> query cancelation.
> We have to investigate this and 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4991) Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is set

[Evgenii Zhuravlev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgenii Zhuravlev reassigned IGNITE-4991:
-

Assignee: Evgenii Zhuravlev  (was: Valentin Kulichenko)

> Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is 
> set
> -
>
> Key: IGNITE-4991
> URL: https://issues.apache.org/jira/browse/IGNITE-4991
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>  Labels: newbie
> Fix For: 2.2
>
>
> {{IgniteKernal#ackSystemProperties}} and {{IgniteKernal#ackVmArguments}} 
> print out system properties that can contain sensitive data. This print outs 
> should be disabled when {{IGNITE_TO_STRING_INCLUDE_SENSITIVE}} system 
> property is set to {{true}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6012) Improve GridJettyRestHandler.processRequest()

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-6012:


Assignee: Andrey Novikov  (was: Alexey Kuznetsov)

Please review my changes.

> Improve GridJettyRestHandler.processRequest()
> -
>
> Key: IGNITE-6012
> URL: https://issues.apache.org/jira/browse/IGNITE-6012
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.1
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> In case of large result  
> {code}
> private void processRequest(String act, HttpServletRequest req, 
> HttpServletResponse res) {
> ...
> json = jsonMapper.writeValueAsString(cmdRes)
> 
> {code}
> Will fail with OOME, beacuse jsonMapper.writeValueAsString(cmdRes) internally 
> will create a StringBuilder and will try to allocate large amount of memory.
> This could be easily fixed by writing object directly to response output 
> stream via. 
> {code}
> jsonMapper.writeValue(out, cmdRes);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-642) Implement IgniteReentrantLock data structure

[Vladisav Jelisavcic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119935#comment-16119935
 ] 

Vladisav Jelisavcic commented on IGNITE-642:


HI Alexey,

If you think there is a bug please open a new ticket.

Thanks!

> Implement IgniteReentrantLock data structure
> 
>
> Key: IGNITE-642
> URL: https://issues.apache.org/jira/browse/IGNITE-642
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Affects Versions: 1.6
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>  Labels: features
> Fix For: 1.6
>
>
> We need to add {{IgniteReentrantLock}} data structure in addition to other 
> data structures provided by Ignite. {{IgniteReentrantLock}} should have 
> similar API to {{java.util.concurrent.locks.ReentrantLock}} class in JDK.
> As an example, you can see how 
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
>  is implemented in 
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
>  class.
> In general we need to have an entity in ATOMIC cache storing lock-owner 
> identifier together with a queue of waiters.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5865) TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing

[Vitaliy Biryukov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119923#comment-16119923
 ] 

Vitaliy Biryukov  edited comment on IGNITE-5865 at 8/9/17 1:50 PM:
---

Fixed.

[TC 
run|https://ci.ignite.apache.org/viewLog.html?buildId=762413=buildResultsDiv=Ignite20Tests_RunAll]


was (Author: vitaliyb):
Fixed.

[link TC 
run|https://ci.ignite.apache.org/viewLog.html?buildId=762413=buildResultsDiv=Ignite20Tests_RunAll]

> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing
> -
>
> Key: IGNITE-5865
> URL: https://issues.apache.org/jira/browse/IGNITE-5865
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Vitaliy Biryukov 
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-failure
> Fix For: 2.2
>
>
> Test is flaky.
> Also there is always failing test in suite: 
> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitionedNear
> TC build result: 
> http://ci.ignite.apache.org/viewLog.html?buildId=744109=buildResultsDiv=Ignite20Tests_IgniteCacheDeadlockDetection
> Stacktrace: 
> {noformat}
> [2017-07-28 
> 03:31:52,827][ERROR][grid-timeout-worker-#31%transactions.TxOptimisticDeadlockDetectionTest0%][IgniteTxHandler]
>  Failed to prepare DHT transaction: GridDhtTxLocal 
> [nearNodeId=d005de76-4378-4cd5-ad7e-f00593a2, 
> nearFutId=aab9f378d51-37ca90c9-03f5-417c-9731-2c29810e3cc0, nearMiniId=1, 
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], 
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], 
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxStateImpl [activeCacheIds=GridIntList [idx=1, 
> arr=[94416770]], recovery=false, txMap=[IgniteTxEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770, txKey=IgniteTxKey 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=694, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], val=null, 
> startVer=1501212673290, ver=GridCacheVersion [topVer=112692678, 
> order=1501212673290, nodeOrder=1], hash=-1228408719, 
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc 
> [locs=[GridCacheMvccCandidate [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, 
> ver=GridCacheVersion [topVer=112692678, order=1501212673287, nodeOrder=1], 
> threadId=846, id=520, topVer=AffinityTopologyVersion [topVer=8, 
> minorTopVer=8], reentry=null, 
> otherNodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673287, nodeOrder=1], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null], GridCacheMvccCandidate 
> [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, ver=GridCacheVersion 
> [topVer=112692678, order=1501212673314, nodeOrder=1], threadId=847, id=521, 
> topVer=AffinityTopologyVersion [topVer=8, minorTopVer=8], reentry=null, 
> otherNodeId=d005de76-4378-4cd5-ad7e-f00593a2, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=GridCacheVersion [topVer=112692678, 
> order=1501212673287, nodeOrder=1], serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=0|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null]], rmts=null]], flags=2]]], prepared=1, 
> locked=false, nodeId=null, locMapped=false, expiryPlc=null, 
> transferExpiryPlc=false, flags=0, 

[jira] [Updated] (IGNITE-6011) EntryProcessor can make data inconsistent if fails on TX cache.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-6011:
-
Description: 
I'd expect that with FULL_SYNC write mode and TX cache data always be 
consistent.
And if EntryProcessor fails on primary (or backup) node and pass on backup (or 
primary) then whole transaction will be rolled back.

But I observe old value on node where EP has failed and new value on other 
nodes.

PFA repro attached.


Looks like we should apply EP on lock phase and fail TX if there is any 
failures.

  was:
I'd expect that with FULL_SYNC write mode and TX cache data always be 
consistent.
And if EntryProcessor fails on primary (or backup) node and pass on backup (or 
primary) then whole transaction will be rolled back.

But looks like it is not true, I observe old value on node where EP has failed 
and new value on other nodes.

PFA repro attached.


> EntryProcessor can make data inconsistent if fails on TX cache.
> ---
>
> Key: IGNITE-6011
> URL: https://issues.apache.org/jira/browse/IGNITE-6011
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Andrew Mashenkov
> Attachments: EntryProcessorBug.java
>
>
> I'd expect that with FULL_SYNC write mode and TX cache data always be 
> consistent.
> And if EntryProcessor fails on primary (or backup) node and pass on backup 
> (or primary) then whole transaction will be rolled back.
> But I observe old value on node where EP has failed and new value on other 
> nodes.
> PFA repro attached.
> Looks like we should apply EP on lock phase and fail TX if there is any 
> failures.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6012) Improve GridJettyRestHandler.processRequest()

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-6012:


 Summary: Improve GridJettyRestHandler.processRequest()
 Key: IGNITE-6012
 URL: https://issues.apache.org/jira/browse/IGNITE-6012
 Project: Ignite
  Issue Type: Improvement
  Components: rest
Affects Versions: 2.1
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.2


In case of large result  
{code}
private void processRequest(String act, HttpServletRequest req, 
HttpServletResponse res) {
...
json = jsonMapper.writeValueAsString(cmdRes)

{code}

Will fail with OOME, beacuse jsonMapper.writeValueAsString(cmdRes) internally 
will create a StringBuilder and will try to allocate large amount of memory.

This could be easily fixed by writing object directly to response output stream 
via. 
{code}
jsonMapper.writeValue(out, cmdRes);
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null

[Yakov Zhdanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119890#comment-16119890
 ] 

Yakov Zhdanov commented on IGNITE-5994:
---

[~avinogradov] [~sharpler], now I see. That's definitely a bug. If return type 
is Future then it should return object of type returned by an entry 
processor.

> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
>  Labels: newbie
> Attachments: IgniteCacheSelfTest.java
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but 
> the IgniteInternalCache.invokeAsync().get() can return the null in case when 
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with 
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for 
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult 
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6004) SQL: add "inlineSize" to QuerySqlField annotation

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119881#comment-16119881
 ] 

Taras Ledkov commented on IGNITE-6004:
--

Waits for [tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2420%2Fhead].

> SQL: add "inlineSize" to QuerySqlField annotation
> -
>
> Key: IGNITE-6004
> URL: https://issues.apache.org/jira/browse/IGNITE-6004
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> "inlineSize" is very important optimization allowing to avoid excessive data 
> page reads when using index. However, it can only be set through 
> {{QueryEntity}} -> {{QueryIndex}} chain, and cannot be set through 
> {{\@QuerySqlField}} annotation.
> Let's fix that and add {{int indexInlineSize}} parameter to that annotation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (IGNITE-9) Need to implement IngniteReentrantReadWriteLock

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov updated IGNITE-9:
--
Comment: was deleted

(was: [~yzhdanov] I have some questions on this ticket :
1) Whether IngniteReentrantReadWriteLock must work the same as 
java.util.concurrent.locks.ReentrantReadWriteLock(when you have only one node 
in cluster) ?
2) Whether all methods in IngniteReentrantReadWriteLock must work fully shared 
on cluster(locks on one node, must be seen by another node. Signals could wake 
up threads on another nodes and so on) ?

PS. Implementation of java ReentrantLock in Ignite (GridCacheLockImpl) doesn't 
meet requirements above.(attached test, reproducing signal()\await() not work 
as in java ReentrantLock))

> Need to implement IngniteReentrantReadWriteLock
> ---
>
> Key: IGNITE-9
> URL: https://issues.apache.org/jira/browse/IGNITE-9
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Alexey Kuznetsov
> Attachments: IgniteReentrantReadWriteLockSelfTest.java
>
>
> See org.apache.ignite.IgniteLock for reference



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6004) SQL: add "inlineSize" to QuerySqlField annotation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119836#comment-16119836
 ] 

ASF GitHub Bot commented on IGNITE-6004:


GitHub user tledkov-gridgain opened a pull request:

https://github.com/apache/ignite/pull/2420

IGNITE-6004 SQL: add "inlineSize" to QuerySqlField annotation



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6004

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2420.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 #2420


commit d70f69bc8afe0b96421fca4e2004cc70c66a8434
Author: tledkov-gridgain 
Date:   2017-08-09T12:49:18Z

IGNITE-6004 SQL: add "inlineSize" to QuerySqlField annotation




> SQL: add "inlineSize" to QuerySqlField annotation
> -
>
> Key: IGNITE-6004
> URL: https://issues.apache.org/jira/browse/IGNITE-6004
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> "inlineSize" is very important optimization allowing to avoid excessive data 
> page reads when using index. However, it can only be set through 
> {{QueryEntity}} -> {{QueryIndex}} chain, and cannot be set through 
> {{\@QuerySqlField}} annotation.
> Let's fix that and add {{int indexInlineSize}} parameter to that annotation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6011) EntryProcessor can make data inconsistent if fails on TX cache.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-6011:
-
Attachment: EntryProcessorBug.java

> EntryProcessor can make data inconsistent if fails on TX cache.
> ---
>
> Key: IGNITE-6011
> URL: https://issues.apache.org/jira/browse/IGNITE-6011
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Andrew Mashenkov
> Attachments: EntryProcessorBug.java
>
>
> I'd expect that with FULL_SYNC write mode and TX cache data always be 
> consistent.
> And if EntryProcessor fails on primary (or backup) node and pass on backup 
> (or primary) then whole transaction will be rolled back.
> But looks like it is not true, I observe old value on node where EP has 
> failed and new value on other nodes.
> PFA repro attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6011) EntryProcessor can make data inconsistent if fails on TX cache.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-6011:


 Summary: EntryProcessor can make data inconsistent if fails on TX 
cache.
 Key: IGNITE-6011
 URL: https://issues.apache.org/jira/browse/IGNITE-6011
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Andrew Mashenkov


I'd expect that with FULL_SYNC write mode and TX cache data always be 
consistent.
And if EntryProcessor fails on primary (or backup) node and pass on backup (or 
primary) then whole transaction will be rolled back.

But looks like it is not true, I observe old value on node where EP has failed 
and new value on other nodes.

PFA repro attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-642) Implement IgniteReentrantLock data structure

[Alexey Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119832#comment-16119832
 ] 

Alexey Kuznetsov commented on IGNITE-642:
-

After a thread signals on a condition, another thread, waiting on the same 
condition(with the same name) doesn't awakens until first trhead unlocks the 
lock.
[~vladisav] admitted, it is desireable behavior for ignite lock implementation. 

As it stated in javadoc for Condition.await() : 
"In all cases, before this method can return the current thread must re-acquire 
the lock associated with this condition. When the thread returns it is 
guaranteed to hold this lock."
So , before sleeping thread awakens(and necessarily take a lock), the lock must 
be released by first lock.

In current implementation of GridCacheLockImpl, signal is transferred to 
cluster nodes when lock is released.


> Implement IgniteReentrantLock data structure
> 
>
> Key: IGNITE-642
> URL: https://issues.apache.org/jira/browse/IGNITE-642
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Affects Versions: 1.6
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>  Labels: features
> Fix For: 1.6
>
>
> We need to add {{IgniteReentrantLock}} data structure in addition to other 
> data structures provided by Ignite. {{IgniteReentrantLock}} should have 
> similar API to {{java.util.concurrent.locks.ReentrantLock}} class in JDK.
> As an example, you can see how 
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
>  is implemented in 
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
>  class.
> In general we need to have an entity in ATOMIC cache storing lock-owner 
> identifier together with a queue of waiters.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6010) ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper fails sometimes

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-6010:


 Summary: ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper 
fails sometimes
 Key: IGNITE-6010
 URL: https://issues.apache.org/jira/browse/IGNITE-6010
 Project: Ignite
  Issue Type: Bug
  Components: zookeeper
Affects Versions: 2.1
Reporter: Ilya Lantukh
 Fix For: 2.2


{noformat}
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at 
org.apache.ignite.spi.discovery.tcp.ipfinder.zk.ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper(ZookeeperIpFinderTest.java:365)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5897) Ignite Cache Full API Multi JVM: 7 test failed in master

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119792#comment-16119792
 ] 

Dmitriy Pavlov commented on IGNITE-5897:


I have unmuted these tests 
(https://ci.ignite.apache.org/viewLog.html?buildId=762913=buildResultsDiv=Ignite20Tests_IgniteCacheFullApiMultiJvm).
 Please consider run with number > # 903

> Ignite Cache Full API Multi JVM: 7 test failed in master
> 
>
> Key: IGNITE-5897
> URL: https://issues.apache.org/jira/browse/IGNITE-5897
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Dmitriy Pavlov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Failure on TC: 
> http://ci.ignite.apache.org/viewLog.html?buildId=749671=buildResultsDiv=Ignite20Tests_IgniteCacheFullApiMultiJvm#testNameId-6305397409161667157
> org.apache.ignite.internal.processors.cache.multijvm (7)
> - 
> GridCachePartitionedNearDisabledMultiJvmFullApiSelfTest.testTransformResourceInjection
>   
> - 
> GridCachePartitionedNearDisabledMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection
>
> - 
> GridCachePartitionedNearDisabledOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection
> 
> - GridCacheReplicatedMultiJvmFullApiSelfTest.testTransformResourceInjection   
> - 
> GridCacheReplicatedMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection
> 
> - 
> GridCacheReplicatedNearOnlyMultiJvmFullApiSelfTest.testTransformResourceInjection
>
> - 
> GridCacheReplicatedOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection
>  
> Stable reproducible locally
> First failure changes:
> http://ci.ignite.apache.org/viewLog.html?buildId=727280=buildChangesDiv=Ignite20Tests_IgniteCacheFullApiMultiJvm
> {noformat}
> IGNITE-5753: CPP Memory leak fixed.   Igor Sapego 
> IGNITE-5444: Collections.singletonList is not properly serialized by binary 
> marshaller. This closes #2217.andrey.mashenkov 
> ignite-5722 Cache entries stay in onheap after scan query execution for 
> OFFHEAP_TIRED cache with expiry policyAndrey Gura 
> ignite-5489 Fixed possible connection leaks when loadPreviousValue set to 
> truetikhonovnicolay 
> IGNITE-4831: Add an option to disable MBeans. This closes #2265.  
> andrey.mashenkov   
> {noformat}
> Stacktrace: 
> {noformat}
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] class 
> org.apache.ignite.IgniteCheckedException: java.lang.NullPointerException
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:327)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.load(GridCacheStoreManagerAdapter.java:282)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.readThrough(GridCacheMapEntry.java:445)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:699)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet(GridCacheMapEntry.java:461)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:389)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1213)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:668)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1034)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:410)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:459)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:121)
> 

[jira] [Created] (IGNITE-6009) CacheExamplesSelfTest.testCacheSemaphoreExample fails sometimes due to timeout

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-6009:


 Summary: CacheExamplesSelfTest.testCacheSemaphoreExample fails 
sometimes due to timeout
 Key: IGNITE-6009
 URL: https://issues.apache.org/jira/browse/IGNITE-6009
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ilya Lantukh
 Fix For: 2.2






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6008) CacheRemoveAllSelfTest.testRemoveAll fails sometimes

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-6008:


 Summary: CacheRemoveAllSelfTest.testRemoveAll fails sometimes
 Key: IGNITE-6008
 URL: https://issues.apache.org/jira/browse/IGNITE-6008
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ilya Lantukh
 Fix For: 2.2


{noformat}
[2017-08-09 01:18:15,172][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError: Local size: 58
On heap: 58
Off heap: 58
Primary: 58
Backup: 14 expected:<0> but was:<58>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.TestCase.assertEquals(TestCase.java:401)
at 
org.apache.ignite.internal.processors.cache.CacheRemoveAllSelfTest.testRemoveAll(CacheRemoveAllSelfTest.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6007) GridCacheBinaryObjectMetadataExchangeMultinodeTest.testSequentialUpdatesNoConflicts fails sometimes

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-6007:


 Summary: 
GridCacheBinaryObjectMetadataExchangeMultinodeTest.testSequentialUpdatesNoConflicts
 fails sometimes
 Key: IGNITE-6007
 URL: https://issues.apache.org/jira/browse/IGNITE-6007
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ilya Lantukh
 Fix For: 2.2


{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.binary.GridCacheBinaryObjectMetadataExchangeMultinodeTest.testSequentialUpdatesNoConflicts(GridCacheBinaryObjectMetadataExchangeMultinodeTest.java:289)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-4991) Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is set

[Evgenii Zhuravlev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119777#comment-16119777
 ] 

Evgenii Zhuravlev commented on IGNITE-4991:
---

Looks like PR contains changes that don't relate to this issue. I will 
implement it properly and create a new PR if you don't mind.

> Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is 
> set
> -
>
> Key: IGNITE-4991
> URL: https://issues.apache.org/jira/browse/IGNITE-4991
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>  Labels: newbie
> Fix For: 2.2
>
>
> {{IgniteKernal#ackSystemProperties}} and {{IgniteKernal#ackVmArguments}} 
> print out system properties that can contain sensitive data. This print outs 
> should be disabled when {{IGNITE_TO_STRING_INCLUDE_SENSITIVE}} system 
> property is set to {{true}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5987) visorcmd: add possibility do not close visorcmd in batch mode

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-5987:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Merged to master. Please retest.

> visorcmd: add possibility do not close visorcmd in batch mode
> -
>
> Key: IGNITE-5987
> URL: https://issues.apache.org/jira/browse/IGNITE-5987
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 2.2
>
>
> That possibility will be useful for alert command which works only while 
> visorcmd is active



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6006) IgniteCacheGetRestartTest fails sometimes on TC

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-6006:


 Summary: IgniteCacheGetRestartTest fails sometimes on TC
 Key: IGNITE-6006
 URL: https://issues.apache.org/jira/browse/IGNITE-6006
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ilya Lantukh
 Fix For: 2.2


{noformat}
junit.framework.AssertionFailedError: expected:<33244> but was:
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:86)
at junit.framework.TestCase.assertEquals(TestCase.java:253)
at 
org.apache.ignite.internal.processors.cache.distributed.IgniteCacheGetRestartTest.checkGet(IgniteCacheGetRestartTest.java:265)
at 
org.apache.ignite.internal.processors.cache.distributed.IgniteCacheGetRestartTest.access$200(IgniteCacheGetRestartTest.java:52)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null

[Anton Vinogradov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119754#comment-16119754
 ] 

Anton Vinogradov edited comment on IGNITE-5994 at 8/9/17 11:48 AM:
---

[~yzhdanov],

Currently,
{{IgniteCache.invokeAsync()}} is defined as {{ IgniteFuture 
invokeAsync(...)}},
but {{IgniteInternalCache.invokeAsync()}} is defined as {{ 
IgniteInternalFuture invokeAsync(...)}}
and question about second one.

When {{EntryProcessor}} returns {{null}} we will gain {{null}} at 
{{invokeAsync(...).get()}},
But when it returns {{not null}} we will gain {{EntryProcessorResult}} instance 
at {{invokeAsync(...).get()}}

So, the question is, is it optimization or bug?


was (Author: avinogradov):
[~yzhdanov],

Currently,
{{IgniteCache.invokeAsync()}} is defined as {{ IgniteFuture 
invokeAsync(...)}},
but {{IgniteInternalCache.invokeAsync()}} is defined as {{ 
IgniteInternalFuture invokeAsync(...)}}
and question about second one.

When {{EntryProcessor}} returns {{null}} we will gain {{null}} at 
{{invokeAsync(...).get()}},
But when it returns {{not null}} we will gain {{EntryProcessorResult}} instance 
at {{invokeAsync("test", ep).get()}}

So, the question is, is it optimization or bug?

> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
>  Labels: newbie
> Attachments: IgniteCacheSelfTest.java
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but 
> the IgniteInternalCache.invokeAsync().get() can return the null in case when 
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with 
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for 
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult 
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null

[Anton Vinogradov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119754#comment-16119754
 ] 

Anton Vinogradov commented on IGNITE-5994:
--

[~yzhdanov],

Currently,
{{IgniteCache.invokeAsync()}} is defined as {{ IgniteFuture 
invokeAsync(...)}},
but {{IgniteInternalCache.invokeAsync()}} is defined as {{ 
IgniteInternalFuture invokeAsync(...)}}
and question about second one.

When {{EntryProcessor}} returns {{null}} we will gain {{null}} at 
{{invokeAsync(...).get()}},
But when it returns {{not null}} we will gain {{EntryProcessorResult}} instance 
at {{invokeAsync("test", ep).get()}}

So, the question is, is it optimization or bug?

> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
>  Labels: newbie
> Attachments: IgniteCacheSelfTest.java
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but 
> the IgniteInternalCache.invokeAsync().get() can return the null in case when 
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with 
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for 
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult 
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6003) Detecting low memory on ignite node startup

[Sergey Chugunov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-6003:

Description: 
h2. Motivation
Starting from version 2.0 Ignite keeps all data in offheap area and allocates 
this area on startup based on MemoryPolicy settings.
So several Ignite nodes started on the same machine may allocate an order of 
magnitude more memory than physically available so when putting pressure on 
such cluster will cause the machine to hang.

h2. Acceptance Criteria
# Reliable cross-platform algorithm to detect low memory is developed.
# Ignite node fails to start with descriptive error message when the algorithm 
detects low memory which may cause hang.


  was:
h2. Motivation
Starting from version 2.0 Ignite keeps all data offheap and allocates it on 
startup based on MemoryPolicy settings.
So several Ignite nodes started on the same machine may allocate an order of 
magnitude more memory than physically available so when putting pressure on 
such cluster will cause the machine to hang.

h2. Acceptance Criteria
# Reliable cross-platform algorithm to detect low memory is developed.
# Ignite node fails to start with descriptive error message when the algorithm 
detects low memory which may cause hang.



> Detecting low memory on ignite node startup
> ---
>
> Key: IGNITE-6003
> URL: https://issues.apache.org/jira/browse/IGNITE-6003
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
> Fix For: 2.2
>
>
> h2. Motivation
> Starting from version 2.0 Ignite keeps all data in offheap area and allocates 
> this area on startup based on MemoryPolicy settings.
> So several Ignite nodes started on the same machine may allocate an order of 
> magnitude more memory than physically available so when putting pressure on 
> such cluster will cause the machine to hang.
> h2. Acceptance Criteria
> # Reliable cross-platform algorithm to detect low memory is developed.
> # Ignite node fails to start with descriptive error message when the 
> algorithm detects low memory which may cause hang.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6003) Detecting low memory on ignite node startup

[Sergey Chugunov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-6003:

Description: 
h2. Motivation
Starting from version 2.0 Ignite keeps all data in offheap area and allocates 
this area on startup based on MemoryPolicy settings.
So several Ignite nodes started on the same machine may allocate an order of 
magnitude more memory than physically available so putting pressure on such 
cluster will cause the machine to hang.

h2. Acceptance Criteria
# Reliable cross-platform algorithm to detect low memory is developed.
# Ignite node fails to start with descriptive error message when the algorithm 
detects low memory which may cause hang.


  was:
h2. Motivation
Starting from version 2.0 Ignite keeps all data in offheap area and allocates 
this area on startup based on MemoryPolicy settings.
So several Ignite nodes started on the same machine may allocate an order of 
magnitude more memory than physically available so when putting pressure on 
such cluster will cause the machine to hang.

h2. Acceptance Criteria
# Reliable cross-platform algorithm to detect low memory is developed.
# Ignite node fails to start with descriptive error message when the algorithm 
detects low memory which may cause hang.



> Detecting low memory on ignite node startup
> ---
>
> Key: IGNITE-6003
> URL: https://issues.apache.org/jira/browse/IGNITE-6003
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
> Fix For: 2.2
>
>
> h2. Motivation
> Starting from version 2.0 Ignite keeps all data in offheap area and allocates 
> this area on startup based on MemoryPolicy settings.
> So several Ignite nodes started on the same machine may allocate an order of 
> magnitude more memory than physically available so putting pressure on such 
> cluster will cause the machine to hang.
> h2. Acceptance Criteria
> # Reliable cross-platform algorithm to detect low memory is developed.
> # Ignite node fails to start with descriptive error message when the 
> algorithm detects low memory which may cause hang.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5897) Ignite Cache Full API Multi JVM: 7 test failed in master

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119744#comment-16119744
 ] 

ASF GitHub Bot commented on IGNITE-5897:


Github user nizhikov closed the pull request at:

https://github.com/apache/ignite/pull/2384


> Ignite Cache Full API Multi JVM: 7 test failed in master
> 
>
> Key: IGNITE-5897
> URL: https://issues.apache.org/jira/browse/IGNITE-5897
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Dmitriy Pavlov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Failure on TC: 
> http://ci.ignite.apache.org/viewLog.html?buildId=749671=buildResultsDiv=Ignite20Tests_IgniteCacheFullApiMultiJvm#testNameId-6305397409161667157
> org.apache.ignite.internal.processors.cache.multijvm (7)
> - 
> GridCachePartitionedNearDisabledMultiJvmFullApiSelfTest.testTransformResourceInjection
>   
> - 
> GridCachePartitionedNearDisabledMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection
>
> - 
> GridCachePartitionedNearDisabledOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection
> 
> - GridCacheReplicatedMultiJvmFullApiSelfTest.testTransformResourceInjection   
> - 
> GridCacheReplicatedMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection
> 
> - 
> GridCacheReplicatedNearOnlyMultiJvmFullApiSelfTest.testTransformResourceInjection
>
> - 
> GridCacheReplicatedOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection
>  
> Stable reproducible locally
> First failure changes:
> http://ci.ignite.apache.org/viewLog.html?buildId=727280=buildChangesDiv=Ignite20Tests_IgniteCacheFullApiMultiJvm
> {noformat}
> IGNITE-5753: CPP Memory leak fixed.   Igor Sapego 
> IGNITE-5444: Collections.singletonList is not properly serialized by binary 
> marshaller. This closes #2217.andrey.mashenkov 
> ignite-5722 Cache entries stay in onheap after scan query execution for 
> OFFHEAP_TIRED cache with expiry policyAndrey Gura 
> ignite-5489 Fixed possible connection leaks when loadPreviousValue set to 
> truetikhonovnicolay 
> IGNITE-4831: Add an option to disable MBeans. This closes #2265.  
> andrey.mashenkov   
> {noformat}
> Stacktrace: 
> {noformat}
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] class 
> org.apache.ignite.IgniteCheckedException: java.lang.NullPointerException
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:327)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.load(GridCacheStoreManagerAdapter.java:282)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.readThrough(GridCacheMapEntry.java:445)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:699)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet(GridCacheMapEntry.java:461)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:389)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1213)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:668)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1034)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:410)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:459)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:121)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea]  at 
> 

[jira] [Commented] (IGNITE-5452) GridTimeoutProcessor can hang on stop.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119742#comment-16119742
 ] 

ASF GitHub Bot commented on IGNITE-5452:


GitHub user dmekhanikov opened a pull request:

https://github.com/apache/ignite/pull/2419

IGNITE-5452 GridTimeoutProcessor can hang on stop

Created for testing

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-5452-1.7

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2419.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 #2419


commit d5e15af76044cf65385672f8528d48ecdeca3cb6
Author: Pavel Tupitsyn 
Date:   2016-11-02T09:02:00Z

IGNITE-4121 .NET: add ScanQuery example

commit 74f8308d10fc011c00e52efcdb315b35cc79e60a
Author: Pavel Tupitsyn 
Date:   2016-11-02T12:59:15Z

IGNITE-4123 .NET: Remove [Serializable] from Employee in examples

commit 92fff630fbf36c82f93bbd9ddd53d11bed44e772
Author: devozerov 
Date:   2016-11-02T14:50:51Z

Restored services compatibility.

commit a62a0136d295486d95c6e2ab5bba88270d831753
Author: dkarachentsev 
Date:   2016-11-02T16:07:45Z

GG-11655 - Fix merge

commit 348593986b56ddfcec4a4455e49d9b279eae4dc8
Author: devozerov 
Date:   2016-11-05T10:28:03Z

Merge branch 'ignite-1.7.3' into ignite-1.7.4

commit 175da6b7e394dd76c27d5155ff98a5b2ef03bb9d
Author: tledkov-gridgain 
Date:   2016-11-07T06:16:58Z

IGNITE-3432:  check data/meta cache names are different for different IGFS 
instances. This closes #1201

commit ead15193899d08f41491166003cabed0560f0c59
Author: Pavel Tupitsyn 
Date:   2016-11-07T07:49:03Z

IGNITE-4028 Get rid of OP_META in PlatformAbstractTarget

This closes #1192

commit 40ef2f5ae42826fe8fd077e3013e8f55c8512bdd
Author: Dmitriy Govorukhin 
Date:   2016-11-07T09:09:41Z

ignite-4178 support permission builder

commit df670c7d64046d282c053f296c47a4743c58c8b1
Author: Pavel Tupitsyn 
Date:   2016-11-07T09:40:00Z

IGNITE-4118 .NET: Optimistic transaction example

This closes #1200

commit 474f22fda4c7cf4d7b2623c451cd7c10f0d8c636
Author: Pavel Tupitsyn 
Date:   2016-11-07T09:55:20Z

IGNITE-4119 .NET: add TransactionDeadlockException

commit fc7ce5a4d72145f2e8a86debeda264ef0a5b37e3
Author: isapego 
Date:   2016-11-07T10:26:05Z

IGNITE-4090: Added flags so stdint and limits can be used in C++.

commit a98804a249496ba9bafbc96daa7aaf25b3d36724
Author: Igor Sapego 
Date:   2016-11-07T11:00:00Z

IGNITE-4113: Added tests. Added Statement::Set/GetAttribute.

commit b1c7c9bb95c900083702d0ba0362edf3aea5a7b4
Author: sboikov 
Date:   2016-11-07T12:40:36Z

GG-11360 - Implement SQL queries cancellation
Fix for commit 80abd1b: for distributed joins need always send cancel 
request.

commit 319014de075c80fb15e58172cc24e35ce16b56cf
Author: Pavel Tupitsyn 
Date:   2016-11-07T14:53:40Z

IGNITE-4132 .NET: Improve BinaryConfiguration documentation

commit 950bad474ef29f9b808e74034c49a69d57eb2740
Author: dkarachentsev 
Date:   2016-11-08T11:03:34Z

GG-11655 - Restore service compatibility with releases before 1.5.30.

commit 3d19bfc2b66574e3945ce17c7a4dfe77d0070b8d
Author: dkarachentsev 
Date:   2016-11-08T11:04:36Z

Merge remote-tracking branch 'origin/ignite-1.6.11' into ignite-1.6.11

commit 1612b6d66fed032182a41e90da71e6b986ae087b
Author: Pavel Tupitsyn 
Date:   2016-11-08T11:07:54Z

.NET: Fix minor analysis warnings

commit e821dc0083003bc81058b1cb223d8a8a2ee44daf
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:09:21Z

IGNITE-2079 (revert commit) GridCacheIoManager eats exception trail if it 
falls into the directed case

commit c2c82ca44befe4570325dd6cf2ba885e0d90596c
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:10:10Z

Merge remote-tracking branch 'professional/ignite-1.6.11' into ignite-1.6.11

commit 865bbcf0f41a0c4944e0928f1758d43a0eae82c5
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:18:29Z

Revert "Merge remote-tracking branch 'professional/ignite-1.6.11' into 
ignite-1.6.11"

This reverts commit c2c82ca44befe4570325dd6cf2ba885e0d90596c, reversing
changes made to e821dc0083003bc81058b1cb223d8a8a2ee44daf.

commit 9726421ff9efb2b19813b2fd6ad27a3728b5ab1a
Author: Dmitriy Govorukhin 

[jira] [Created] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-6005:
-

 Summary: [Test failed] 
GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
 Key: IGNITE-6005
 URL: https://issues.apache.org/jira/browse/IGNITE-6005
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Eduard Shangareev
 Fix For: 2.2


Example of fail
https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures

Typical problem is 
{code}
org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
operation permit (thread got interrupted).
at org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
at org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
at 
org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
at 
org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.InterruptedException: null
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
at 
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
at 
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635)
at 
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519)
at 
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629)
at 
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188)
at 
org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023)
at 
org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe

[Eduard Shangareev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eduard Shangareev updated IGNITE-6005:
--
Labels: MakeTeamcityGreenAgain  (was: )

> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> 

[jira] [Updated] (IGNITE-6001) [Test failed] DynamicIndexReplicatedAtomicConcurrentSelfTest.testCoordinatorChange

[Eduard Shangareev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eduard Shangareev updated IGNITE-6001:
--
Affects Version/s: 2.1

> [Test failed] 
> DynamicIndexReplicatedAtomicConcurrentSelfTest.testCoordinatorChange
> --
>
> Key: IGNITE-6001
> URL: https://issues.apache.org/jira/browse/IGNITE-6001
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.2
>
>
> Fails with error
> {code}
> java.lang.IllegalStateException: Cache doesn't exist: cache
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cacheConfiguration(GridCacheProcessor.java:3342)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.(DataStreamerImpl.java:284)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.dataStreamer(DataStreamProcessor.java:181)
> at 
> org.apache.ignite.internal.IgniteKernal.dataStreamer(IgniteKernal.java:3288)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractSelfTest.put(DynamicIndexAbstractSelfTest.java:318)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractConcurrentSelfTest.testCoordinatorChange(DynamicIndexAbstractConcurrentSelfTest.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1999)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1914)
> at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6001) [Test failed] DynamicIndexReplicatedAtomicConcurrentSelfTest.testCoordinatorChange

[Eduard Shangareev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eduard Shangareev updated IGNITE-6001:
--
Fix Version/s: 2.2

> [Test failed] 
> DynamicIndexReplicatedAtomicConcurrentSelfTest.testCoordinatorChange
> --
>
> Key: IGNITE-6001
> URL: https://issues.apache.org/jira/browse/IGNITE-6001
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.2
>
>
> Fails with error
> {code}
> java.lang.IllegalStateException: Cache doesn't exist: cache
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cacheConfiguration(GridCacheProcessor.java:3342)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.(DataStreamerImpl.java:284)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.dataStreamer(DataStreamProcessor.java:181)
> at 
> org.apache.ignite.internal.IgniteKernal.dataStreamer(IgniteKernal.java:3288)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractSelfTest.put(DynamicIndexAbstractSelfTest.java:318)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractConcurrentSelfTest.testCoordinatorChange(DynamicIndexAbstractConcurrentSelfTest.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1999)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1914)
> at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6003) Detecting low memory on ignite node startup

[Sergey Chugunov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-6003:

Fix Version/s: 2.2

> Detecting low memory on ignite node startup
> ---
>
> Key: IGNITE-6003
> URL: https://issues.apache.org/jira/browse/IGNITE-6003
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
> Fix For: 2.2
>
>
> h2. Motivation
> Starting from version 2.0 Ignite keeps all data offheap and allocates it on 
> startup based on MemoryPolicy settings.
> So several Ignite nodes started on the same machine may allocate an order of 
> magnitude more memory than physically available so when putting pressure on 
> such cluster will cause the machine to hang.
> h2. Acceptance Criteria
> # Reliable cross-platform algorithm to detect low memory is developed.
> # Ignite node fails to start with descriptive error message when the 
> algorithm detects low memory which may cause hang.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5549) Ignite Cache Failover2: test suite hands up from CacheAsyncOperationsFailoverTxTest.testAsyncFailover()

[Sergey Chugunov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-5549:

Description: 
Timeout came from CacheAsyncOperationsFailoverTxTest.testAsyncFailover() test:
http://ci.ignite.apache.org/viewLog.html?buildId=756819=Ignite20Tests_IgniteCacheFailover2=buildResultsDiv

{noformat}
ransaction has been already completed.
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:787)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:727)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:683)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:95)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:165)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:163)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:485)
[16:29:30]W: [org.apache.ignite:ignite-core]at 
java.lang.Thread.run(Thread.java:745)
[16:29:30]W: [org.apache.ignite:ignite-core] 
java.lang.AssertionError: Invalid threadId [this=GridCacheMvccCandidate 
[nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion 
[topVer=11427, order=1501856691702, nodeOrder=1], threadId=211336, 
id=30502322, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0], 
reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70, 
otherVer=GridCacheVersion [topVer=11427, order=1501856691702, nodeOrder=1], 
mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null, 
key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbstractTest$TestKey
 [idHash=742616132, hash=-1080846605, key=48], 
masks=local=1|owner=0|ready=0|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
 prevVer=null, nextVer=null], prev=GridCacheMvccCandidate 
[nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion 
[topVer=11425, order=1501856674174, nodeOrder=1], threadId=216954, 
id=30502305, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0], 
reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70, 
otherVer=GridCacheVersion [topVer=11425, order=1501856674174, nodeOrder=1], 
mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null, 
key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbstractTest$TestKey
 [idHash=950720167, hash=-1566972591, key=146], 

[jira] [Commented] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null

[Yakov Zhdanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119676#comment-16119676
 ] 

Yakov Zhdanov commented on IGNITE-5994:
---

Currently {{invokeAsync()}} is defined as {{public  IgniteFuture 
invokeAsync(.)}}.

If we need EntryProcessorResult to be returned from Future then it should be 
{{public  IgniteFuture invokeAsync(.)}}. I am 
not sure why we have this difference in sync/async counterpart. Probably, 
[~vozerov] or [~tledkov-gridgain] can provide some info.

I also think that we will not changing the public API in 2.0. Let's leave it as 
is and then fix in next major version.


> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
>  Labels: newbie
> Attachments: IgniteCacheSelfTest.java
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but 
> the IgniteInternalCache.invokeAsync().get() can return the null in case when 
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with 
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for 
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult 
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6004) SQL: add "inlineSize" to QuerySqlField annotation

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6004:
---

 Summary: SQL: add "inlineSize" to QuerySqlField annotation
 Key: IGNITE-6004
 URL: https://issues.apache.org/jira/browse/IGNITE-6004
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Assignee: Taras Ledkov
 Fix For: 2.2


"inlineSize" is very important optimization allowing to avoid excessive data 
page reads when using index. However, it can only be set through 
{{QueryEntity}} -> {{QueryIndex}} chain, and cannot be set through 
{{\@QuerySqlField}} annotation.

Let's fix that and add {{int indexInlineSize}} parameter to that annotation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null

[Yakov Zhdanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yakov Zhdanov updated IGNITE-5994:
--
Description: 
The IgniteInternalCache.invoke() always return an EntryProcessorResult, but the 
IgniteInternalCache.invokeAsync().get() can return the null in case when an 
EntryProcessor has returned the null.

Code from reproducer:

{noformat}
final EntryProcessor ep = new EntryProcessor() {
@Override
public Object process(MutableEntry entry,
Object... objects) throws EntryProcessorException {
return null;
}
};

EntryProcessorResult result = utilCache.invoke("test", ep);

assertNotNull(result);
assertNull(result.get());


result = utilCache.invokeAsync("test", ep).get();

// Assert here!!!
assertNotNull(result);
assertNull(result.get());

{noformat}
It can be optimization. Nevertheless results of invoke() must be equals with 
results of invokeAsync().get(). So there are two options:

1) To do so would be the invokeAsync(key, ep).get() returned the null too for 
the optimization.
2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult 
for a logical consistency.

NOTE: Don't confuse with IgniteCache.invoke.

  was:
The IgniteInternalCache.invoke() always return an EntryProcessorResult, but the 
IgniteInternalCache.invokeAsync().get() can return the null in case when an 
EntryProcessor has returned the null.

Code from reproducer:

```Java
final EntryProcessor ep = new EntryProcessor() {
@Override
public Object process(MutableEntry entry,
Object... objects) throws EntryProcessorException {
return null;
}
};

EntryProcessorResult result = utilCache.invoke("test", ep);

assertNotNull(result);
assertNull(result.get());


result = utilCache.invokeAsync("test", ep).get();

// Assert here!!!
assertNotNull(result);
assertNull(result.get());
```
It can be optimization. Nevertheless results of invoke() must be equals with 
results of invokeAsync().get(). So there are two options:

1) To do so would be the invokeAsync(key, ep).get() returned the null too for 
the optimization.
2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult 
for a logical consistency.

NOTE: Don't confuse with IgniteCache.invoke.


> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
>  Labels: newbie
> Attachments: IgniteCacheSelfTest.java
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but 
> the IgniteInternalCache.invokeAsync().get() can return the null in case when 
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with 
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for 
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult 
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-9) Need to implement IngniteReentrantReadWriteLock

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov updated IGNITE-9:
--
Attachment: (was: IgniteReentrantReadWriteLockSelfTest.java)

> Need to implement IngniteReentrantReadWriteLock
> ---
>
> Key: IGNITE-9
> URL: https://issues.apache.org/jira/browse/IGNITE-9
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Alexey Kuznetsov
> Attachments: IgniteReentrantReadWriteLockSelfTest.java
>
>
> See org.apache.ignite.IgniteLock for reference



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-9) Need to implement IngniteReentrantReadWriteLock

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov updated IGNITE-9:
--
Attachment: IgniteReentrantReadWriteLockSelfTest.java

> Need to implement IngniteReentrantReadWriteLock
> ---
>
> Key: IGNITE-9
> URL: https://issues.apache.org/jira/browse/IGNITE-9
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Alexey Kuznetsov
> Attachments: IgniteReentrantReadWriteLockSelfTest.java
>
>
> See org.apache.ignite.IgniteLock for reference



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6003) Detecting low memory on ignite node startup

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-6003:
---

 Summary: Detecting low memory on ignite node startup
 Key: IGNITE-6003
 URL: https://issues.apache.org/jira/browse/IGNITE-6003
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Chugunov


h2. Motivation
Starting from version 2.0 Ignite keeps all data offheap and allocates it on 
startup based on MemoryPolicy settings.
So several Ignite nodes started on the same machine may allocate an order of 
magnitude more memory than physically available so when putting pressure on 
such cluster will cause the machine to hang.

h2. Acceptance Criteria
# Reliable cross-platform algorithm to detect low memory is developed.
# Ignite node fails to start with descriptive error message when the algorithm 
detects low memory which may cause hang.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5993) SQL: Dead code cleanup

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119588#comment-16119588
 ] 

ASF GitHub Bot commented on IGNITE-5993:


Github user devozerov closed the pull request at:

https://github.com/apache/ignite/pull/2414


> SQL: Dead code cleanup
> --
>
> Key: IGNITE-5993
> URL: https://issues.apache.org/jira/browse/IGNITE-5993
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.2
>
>
> We have several unused code pieces in indexing module. Mostly - unused 
> methods and variables from 1.x times, old index implementations, snapshots, 
> etc.. Let's remove it altogether for now.
> Git history will help should we need something of that in future.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5076) Optimization of multi-threaded start nodes in tests

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119579#comment-16119579
 ] 

ASF GitHub Bot commented on IGNITE-5076:


Github user sk0x50 closed the pull request at:

https://github.com/apache/ignite/pull/2202


> Optimization of multi-threaded start nodes in tests
> ---
>
> Key: IGNITE-5076
> URL: https://issues.apache.org/jira/browse/IGNITE-5076
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Dmitriy Govorukhin
>Assignee: Vyacheslav Koptilin
> Fix For: 2.1
>
>
> Concurrent start,will more effective if we have coordinator before, 
> multi-threaded start nodes. If start all nodes concurrent, they will be 
> compete for coordinator role, it is not effective way.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5076) Optimization of multi-threaded start nodes in tests

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119578#comment-16119578
 ] 

ASF GitHub Bot commented on IGNITE-5076:


Github user sk0x50 closed the pull request at:

https://github.com/apache/ignite/pull/2194


> Optimization of multi-threaded start nodes in tests
> ---
>
> Key: IGNITE-5076
> URL: https://issues.apache.org/jira/browse/IGNITE-5076
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Dmitriy Govorukhin
>Assignee: Vyacheslav Koptilin
> Fix For: 2.1
>
>
> Concurrent start,will more effective if we have coordinator before, 
> multi-threaded start nodes. If start all nodes concurrent, they will be 
> compete for coordinator role, it is not effective way.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5026) getOrCreateCaches() hangs if any exception in GridDhtPartitionsExchangeFuture.init()

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-5026:


Assignee: (was: Alexey Kuznetsov)

> getOrCreateCaches() hangs if any exception in 
> GridDhtPartitionsExchangeFuture.init()
> 
>
> Key: IGNITE-5026
> URL: https://issues.apache.org/jira/browse/IGNITE-5026
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.9, 2.0
>Reporter: Alexandr Kuramshin
> Fix For: 2.2
>
>
> Any exception has been thrown by {{GridDhtPartitionsExchangeFuture.init()}} 
> causes to wait indefinitely {{GridCompoundFuture}} returned by 
> {{GridCacheProcessor.dynamicStartCaches()}}.
> Reproduced by 
> {{IgniteDynamicCacheStartSelfTest.testGetOrCreateCollectionExceptional()}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)