[jira] [Created] (IGNITE-5875) Implement memory metric that will signal about uneven distribution of pages between segments of durable memory

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-5875:
--

 Summary: Implement memory metric that will signal about uneven 
distribution of pages between segments of durable memory
 Key: IGNITE-5875
 URL: https://issues.apache.org/jira/browse/IGNITE-5875
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Affects Versions: 2.1
Reporter: Ivan Rakov
 Fix For: 2.2


When persistence is enabled, we split memory policy into K equal segments (K = 
concurrency level). We calculate hash of pageId to determine segment where page 
will be stored.
Pages eviction to disk starts when segment is full. If hash function is bad 
enough, one segment can overflow when there are lots of free space, and 
evictions can start too early. We want to be able to distinguish such 
situations. 
Proposed name for metrics: pageHashFunctionScore
Proposed formula: difference between maximum and minimum percentage of segment 
fill



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

[jira] [Updated] (IGNITE-5874) Store TTL expire times in B+ tree on per-partition basis

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5874:
---
Description: 
TTL expire times for entries are stored in PendingEntriesTree, which is 
singleton for cache. When expiration occurs, all system threads iterate through 
the tree in order to remove expired entries. Iterating through single tree 
causes contention and perfomance loss. 
Related performance issue: https://issues.apache.org/jira/browse/IGNITE-5793
We should keep instance of PendingEntriesTree for each partition, like we do 
for CacheDataTree.

  was:
TTL expire times for entries are stored in PendingEntriesTree, which is 
singleton for cache. When expiration occurs, all system threads iterate through 
the tree in order to remove expired entries. Iterating through single tree 
causes contention and perfomance loss. Related performance issue: 
https://issues.apache.org/jira/browse/IGNITE-5793
We should keep instance of PendingEntriesTree for each partition, like we do 
for CacheDataTree.


> Store TTL expire times in B+ tree on per-partition basis
> 
>
> Key: IGNITE-5874
> URL: https://issues.apache.org/jira/browse/IGNITE-5874
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Ivan Rakov
> Fix For: 2.2
>
>
> TTL expire times for entries are stored in PendingEntriesTree, which is 
> singleton for cache. When expiration occurs, all system threads iterate 
> through the tree in order to remove expired entries. Iterating through single 
> tree causes contention and perfomance loss. 
> Related performance issue: https://issues.apache.org/jira/browse/IGNITE-5793
> We should keep instance of PendingEntriesTree for each partition, like we do 
> for CacheDataTree.



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

[jira] [Updated] (IGNITE-5874) Store TTL expire times in B+ tree on per-partition basis

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5874:
---
Description: 
TTL expire times for entries are stored in PendingEntriesTree, which is 
singleton for cache. When expiration occurs, all system threads iterate through 
the tree in order to remove expired entries. Iterating through single tree 
causes contention and perfomance loss. Related performance issue: 
https://issues.apache.org/jira/browse/IGNITE-5793
We should keep instance of PendingEntriesTree for each partition, like we do 
for CacheDataTree.

  was:
TTL expire times for entries are stored in PendingEntriesTree, which is 
singleton for cache. When expiration occurs, all system threads iterate through 
the tree in order to remove expired entries. Iterating through single tree 
causes contention and perfomance loss.
We should keep instance of PendingEntriesTree for each partition, like we do 
for CacheDataTree.


> Store TTL expire times in B+ tree on per-partition basis
> 
>
> Key: IGNITE-5874
> URL: https://issues.apache.org/jira/browse/IGNITE-5874
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Ivan Rakov
> Fix For: 2.2
>
>
> TTL expire times for entries are stored in PendingEntriesTree, which is 
> singleton for cache. When expiration occurs, all system threads iterate 
> through the tree in order to remove expired entries. Iterating through single 
> tree causes contention and perfomance loss. Related performance issue: 
> https://issues.apache.org/jira/browse/IGNITE-5793
> We should keep instance of PendingEntriesTree for each partition, like we do 
> for CacheDataTree.



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

[jira] [Created] (IGNITE-5874) Store TTL expire times in B+ tree on per-partition basis

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-5874:
--

 Summary: Store TTL expire times in B+ tree on per-partition basis
 Key: IGNITE-5874
 URL: https://issues.apache.org/jira/browse/IGNITE-5874
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.1
Reporter: Ivan Rakov
 Fix For: 2.2


TTL expire times for entries are stored in PendingEntriesTree, which is 
singleton for cache. When expiration occurs, all system threads iterate through 
the tree in order to remove expired entries. Iterating through single tree 
causes contention and perfomance loss.
We should keep instance of PendingEntriesTree for each partition, like we do 
for CacheDataTree.



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

[jira] [Created] (IGNITE-5873) Zookeeper discovery does not work correctly when isolated clusters got deployed on similar hosts

[MIKHAIL LIKHASHVA (JIRA)]

MIKHAIL LIKHASHVA created IGNITE-5873:
-

 Summary: Zookeeper discovery does not work correctly when isolated 
clusters got deployed on similar hosts
 Key: IGNITE-5873
 URL: https://issues.apache.org/jira/browse/IGNITE-5873
 Project: Ignite
  Issue Type: Bug
  Components: zookeeper
Affects Versions: 1.9
Reporter: MIKHAIL LIKHASHVA
Priority: Minor


Steps:
1. Start Cluster X on machine A and B (under zookeeper path /xxx )
2. Look at what is registered in zookeeper under /xxx
 /xxx/88x8x8  HOST_A:47500
 /xxx/88x8x8  127.0.0.1:47500
 /xxx/54d32d  HOST_B:47500
 /xxx/54d32d  127.0.0.1:47500

3 . Start Cluster Y on machine A and B (under zookeeper path /yyy ) 
4.   Look at what is registered in zookeeper under /yyy
 /yyy/34564rt  HOST_A:47501
 /yyy/34564rt  127.0.0.1:47501
 /yyy/sdf3232  HOST_B:47501
 /yyy/sdf3232  127.0.0.1:47501

Look correct. Shutdown and try to execute steps 1&3 simultaneously, several 
times, you could end up with situation like this:

 /xxx/88x8x8  HOST_A:47500
 /xxx/88x8x8  127.0.0.1:47500
 /xxx/54d32d  HOST_B:47501
 /xxx/54d32d  127.0.0.1:47501

 /yyy/34564rt  HOST_A:47501
 /yyy/34564rt  127.0.0.1:47501
 /yyy/sdf3232  HOST_B:47500
 /yyy/sdf3232  127.0.0.1:47500

So now node could incorrect connect to different cluster. Possible solution to 
filter out 127.0.0.1 and 0.0.0.0 during start up in registerAddresses of 
TcpDiscoveryZookeeperIpFinder




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

[jira] [Commented] (IGNITE-5621) CPP: Support BINARY and VARBINARY types for C++

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-5621:


[~isapego]
I'm OK with the changes.

> CPP: Support BINARY and VARBINARY types for C++
> ---
>
> Key: IGNITE-5621
> URL: https://issues.apache.org/jira/browse/IGNITE-5621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.2
>
>
> We need to add an ability for user to get columns of {{byte[]}} types using 
> {{SqlFieldsQuery}} in C\+\+. Also, we need to add ability to add SQL 
> parameters of type {{byte[]}} using C\+\+.



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

[jira] [Updated] (IGNITE-5621) CPP: Support BINARY and VARBINARY types for C++

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-5621:

Description: We need to add an ability for user to get columns of 
{{byte[]}} types using {{SqlFieldsQuery}} in C\+\+. Also, we need to add 
ability to add SQL parameters of type {{byte[]}} using C++.  (was: We need to 
add an ability for user to get columns of {{byte[]}} types using 
{{SqlFieldsQuery}} in C++. Also, we need to add ability to add SQL parameters 
of type {{byte[]}} using C++.)

> CPP: Support BINARY and VARBINARY types for C++
> ---
>
> Key: IGNITE-5621
> URL: https://issues.apache.org/jira/browse/IGNITE-5621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.2
>
>
> We need to add an ability for user to get columns of {{byte[]}} types using 
> {{SqlFieldsQuery}} in C\+\+. Also, we need to add ability to add SQL 
> parameters of type {{byte[]}} using C++.



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

[jira] [Updated] (IGNITE-5621) CPP: Support BINARY and VARBINARY types for C++

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-5621:

Description: We need to add an ability for user to get columns of 
{{byte[]}} types using {{SqlFieldsQuery}} in C\+\+. Also, we need to add 
ability to add SQL parameters of type {{byte[]}} using C\+\+.  (was: We need to 
add an ability for user to get columns of {{byte[]}} types using 
{{SqlFieldsQuery}} in C\+\+. Also, we need to add ability to add SQL parameters 
of type {{byte[]}} using C++.)

> CPP: Support BINARY and VARBINARY types for C++
> ---
>
> Key: IGNITE-5621
> URL: https://issues.apache.org/jira/browse/IGNITE-5621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.2
>
>
> We need to add an ability for user to get columns of {{byte[]}} types using 
> {{SqlFieldsQuery}} in C\+\+. Also, we need to add ability to add SQL 
> parameters of type {{byte[]}} using C\+\+.



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

[jira] [Commented] (IGNITE-5771) Add Ignite.setActive method to C++ API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5771:


Github user isapego closed the pull request at:

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


> Add Ignite.setActive method to C++ API
> --
>
> Key: IGNITE-5771
> URL: https://issues.apache.org/jira/browse/IGNITE-5771
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.2
>
>
> Presently, {{Ignite.setActive}} method is unavailable in C++ API which means 
> that there is now way to activate a cluster with the Ignite Persistent Store 
> enabled from a C++ application side.
> Add this method and add a respective documentation paragraph to that section
> https://apacheignite-cpp.readme.io/v2.1/docs/ignite-persistence#section-usage
> in the same way as it's aleady done for .NET:
> https://apacheignite-net.readme.io/v2.1/docs/ignite-persistent-store#section-usage



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

[jira] [Commented] (IGNITE-5758) CPP: Add pointer semantics for primitive types

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5758:


Github user isapego closed the pull request at:

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


> CPP: Add pointer semantics for primitive types
> --
>
> Key: IGNITE-5758
> URL: https://issues.apache.org/jira/browse/IGNITE-5758
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently, we can write any user object using two types of semantics:
> {code}
> // Basic
> writer.WriteObject(obj);
> // Pointer-based
> writer.WriteObject();
> {code}
> However, this does not work for primitive types:
> {code}
> // Basic. Works just fine
> writer.WriteObject(str);
> // Pointer-based. Compilation error.
> writer.WriteObject();
> {code}
> Need to add support of the pointer semantics for the primitive types as well.



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

[jira] [Commented] (IGNITE-5753) CPP: Memory leak on argument cleaning for SqlQuery and SqlFieldsQuery

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5753:


Github user isapego closed the pull request at:

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


> CPP: Memory leak on argument cleaning for SqlQuery and SqlFieldsQuery
> -
>
> Key: IGNITE-5753
> URL: https://issues.apache.org/jira/browse/IGNITE-5753
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> There is a memory leak in {{SqlQuery::ClearArguments()}} and 
> {{SqlFieldsQuery::ClearArguments()}}.



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

[jira] [Commented] (IGNITE-5621) CPP: Support BINARY and VARBINARY types for C++

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5621:


GitHub user isapego opened a pull request:

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

IGNITE-5621: Support BINARY and VARBINARY SQL types for C++



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

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

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

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


commit fc354d6ff0cd06136a135cbff52cee5708aa7c9b
Author: Igor Sapego 
Date:   2017-07-28T15:04:36Z

IGNITE-5621: Implemented for selects.

commit 13c20f4f8ed6f3dd6fc48ec7d52a909b767570ee
Author: Igor Sapego 
Date:   2017-07-28T15:25:57Z

IGNITE-5621: Implemented for inserts

commit 62aad18236d4f5509c6cd1c0c0c015ac37f2fa5e
Author: Igor Sapego 
Date:   2017-07-28T16:19:33Z

IGNITE-5621: Added test and fix




> CPP: Support BINARY and VARBINARY types for C++
> ---
>
> Key: IGNITE-5621
> URL: https://issues.apache.org/jira/browse/IGNITE-5621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.2
>
>
> We need to add an ability for user to get columns of {{byte[]}} types using 
> {{SqlFieldsQuery}} in C++. Also, we need to add ability to add SQL parameters 
> of type {{byte[]}} using C++.



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

[jira] [Assigned] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException

[Sergey Dorozhkin (JIRA)]

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

Sergey Dorozhkin reassigned IGNITE-5823:


Assignee: Sergey Dorozhkin

> Need to remove CacheAtomicUpdateTimeoutException
> 
>
> Key: IGNITE-5823
> URL: https://issues.apache.org/jira/browse/IGNITE-5823
> Project: Ignite
>  Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Sergey Dorozhkin
>Priority: Minor
>  Labels: newbie
>
> And releated - CacheAtomicUpdateTimeoutCheckedException
> These exceptions are not used any more and can be removed.



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

[jira] [Created] (IGNITE-5872) Replace standard java maps for partition counters to more effective data structures

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-5872:


 Summary: Replace standard java maps for partition counters to more 
effective data structures
 Key: IGNITE-5872
 URL: https://issues.apache.org/jira/browse/IGNITE-5872
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.1
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.2


Currently we have map of Integer -> Tuple  which is passed for each 
cache group. This is very inefficient as at causes a lot of boxes and overheads 
in marshalling.
This particular map can be replaced with a sorted primitive array.



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

[jira] [Updated] (IGNITE-5866) JettyRestProcessorUnsignedSelfTest and JettyRestProcessorSignedSelfTest fails on master

[Dmitriy Pavlov (JIRA)]

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

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

> JettyRestProcessorUnsignedSelfTest and JettyRestProcessorSignedSelfTest fails 
> on master
> ---
>
> Key: IGNITE-5866
> URL: https://issues.apache.org/jira/browse/IGNITE-5866
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.1
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> JettyRestProcessorSignedSelfTest and JettyRestProcessorUnsignedSelfTest fails 
> on master
> when run whole test class.
> If run single method both tests succeed.
> testMetadataLocal:
> {noformat}
> junit.framework.AssertionFailedError: expected:<5> but was:<6>
>   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.rest.JettyRestProcessorAbstractSelfTest.testMetadataLocal(JettyRestProcessorAbstractSelfTest.java:1127)
> {noformat}
> testMetadataRemote
> {noformat}
> junit.framework.AssertionFailedError: expected:<6> but was:<7>
>   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.rest.JettyRestProcessorAbstractSelfTest.testMetadataRemote(JettyRestProcessorAbstractSelfTest.java:1174)
> {noformat}



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

[jira] [Updated] (IGNITE-5871) IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed fails

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-5871:
---
Fix Version/s: 2.2

> IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed
>  fails
> 
>
> Key: IGNITE-5871
> URL: https://issues.apache.org/jira/browse/IGNITE-5871
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Success rate is 20%.
> http://ci.ignite.apache.org/project.html?tab=testDetails=Ignite20Tests=-720637123828878=10
> Seems that it was broken in build #179, where [~sboikov] had merged cache 
> groupd (ignite-5075)



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

[jira] [Commented] (IGNITE-5382) SQL: frequent switch between schemas cause severe slowdown

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-5382:


[~al.psc]
Thanks! I have fixed the comments. Please take a look once again.

> SQL: frequent switch between schemas cause severe slowdown
> --
>
> Key: IGNITE-5382
> URL: https://issues.apache.org/jira/browse/IGNITE-5382
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: important, performance
> Fix For: 2.2
>
>
> We have thread-bound cached connection to H2 database which is bound to 
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command, 
> which is rather expensive and may cause slowdown when queries form different 
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be 
> careful with concurrency and resource leaks.



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

[jira] [Commented] (IGNITE-5858) Ignite Cache 5 Timeout: CacheLateAffinityAssignmentTests hangs after assertion error

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5858:


Hi, [~sboikov], thank you for this fix. Ignite Cache 5 Suite started to 
passing. The only one known problem remained [IGNITE-5759]

> Ignite Cache 5 Timeout: CacheLateAffinityAssignmentTests hangs after 
> assertion error
> 
>
> Key: IGNITE-5858
> URL: https://issues.apache.org/jira/browse/IGNITE-5858
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Dmitriy Pavlov
>Assignee: Semen Boikov
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: 
> lastStartedTest_CacheLateAffinityAssignmentTest.testRandomOperations.log.zip, 
> ThreadDump0.zip
>
>
> Reproduced for master:
> {noformat}
> Invalid affinity version [last=AffinityTopologyVersion [topVer=-1, 
> minorTopVer=0], 
> {noformat}
> Failed tests
> CacheLateAffinityAssignmentTest.testRandomOperations
> CacheLateAffinityAssignmentTest.testAffinitySimpleNoCacheOnCoordinator1
> Failed builds
> http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache5=buildTypeHistoryList_Ignite20Tests=%3Cdefault%3E
> Following builds were failed
> 742325,742326,742327,742328,742329,742330,742331,742332,742333,742334,742335,742336,742337,742338,742339,742340,742341,742342,742343,742344



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

[jira] [Commented] (IGNITE-5806) IgniteCache5 suite timed out, assertions in sessions close logic

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5806:


Passing after merge IGNITE-5858, The only one known problem remained IGNITE-5759

> IgniteCache5 suite timed out, assertions in sessions close logic
> 
>
> Key: IGNITE-5806
> URL: https://issues.apache.org/jira/browse/IGNITE-5806
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: Ignite_2.0_Tests_Ignite_Cache_5_748.log.zip
>
>
> Ignite Cache 5 timeouts observed in master
> http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache5_Ignite20Tests=%3Cdefault%3E=buildTypeStatusDiv
> Reproduced for builds 725, 740 and 748 
> Log contains assertion coming from 
> {code}
> !sesHolder.get().ended(store); 
> {code}
> at
> {noformat} [2017-07-21 
> 07:59:44,774][ERROR][sys-stripe-3-#117%cache.CacheSerializableTransactionsTest2%][G]
>  Failed to execute runnable.
>  
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.sessionEnd0(GridCacheStoreManagerAdapter.java:878)
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:335)
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.load(GridCacheStoreManagerAdapter.java:282)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.readThrough(GridCacheMapEntry.java:445)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:699)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet(GridCacheMapEntry.java:461)
> {noformat}
> First time assertion came from test 
> org.apache.ignite.internal.processors.cache.CacheSerializableTransactionsTest#testRandomOperations
> Assertion is reproducible locally. But test is considered passed



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

[jira] [Updated] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-602:
-
Labels: MakeTeamcityGreenAgain Muted_test  (was: Muted_test)

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.2
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



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

[jira] [Updated] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-602:
-
Description: 
See test 
org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
 and related TODO in same source file.
Also take a look at 
http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring

Test should be unmuted on TC after fix.

  was:
See test 
org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
 and related TODO in same source file.
Also take a look at 
http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring

Test should be unmuted on TC after fix.

see GG-5000.


> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.2
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



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

[jira] [Updated] (IGNITE-1386) IPC semaphores are not released on server endpoint abrupt stop

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-1386:
--
Labels: MakeTeamcityGreenAgain Muted_test  (was: Muted_test)

> IPC semaphores are not released on server endpoint abrupt stop
> --
>
> Key: IGNITE-1386
> URL: https://issues.apache.org/jira/browse/IGNITE-1386
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> {{IpcSharedMemoryCrashDetectionSelfTest.testIgfsClientServerInteractionsUponServerKilling}}
>  stops a server endpoint abruptly with 'kill' command and right after that 
> start a new endpoint. 
> The test expects that such a flow will release all previously allocated 
> memory segments and semaphores. 
> In fact, only memory segments are released while semaphores stay in the 
> system. However, the test successfully ends.
> Steps to reproduce:
> - check existing semaphores with {{ipcs -s}};
> - start the test on Linux or Mac OS;
> - call {{ipcs -s}} and you will see that semaphores hasn't been released.
> In addition, TeamCity agents fail a test suite because of this reason from 
> time to time
> {noformat}
> [16:14:03][Step 7/7] Failing build because of remaining IPC resources.
> [16:14:03][Step 7/7] Process exited with code 1
> [16:14:03][Step 7/7] Step Check IPC / Clean up (Command Line) failed
> {noformat}



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

[jira] [Updated] (IGNITE-4551) Reconsider cache key/value peer class loading

[Eduard Shangareev (JIRA)]

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

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

> Reconsider cache key/value peer class loading
> -
>
> Key: IGNITE-4551
> URL: https://issues.apache.org/jira/browse/IGNITE-4551
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Tikhonov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> In new cache implementation after entry is written in offheap information 
> about key/value classloaders in lost (before classloader ids were stored in 
> swap/offheap see GridCacheMapEntry.swap in 'master').
> Need decide how it should work with new architecture (maybe single type per 
> cache can simplify implementation).



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

[jira] [Comment Edited] (IGNITE-5382) SQL: frequent switch between schemas cause severe slowdown

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko edited comment on IGNITE-5382 at 7/28/17 2:30 PM:
--

[~skalashnikov]
my comments:

- are we right to pass {{null}} as first arg when calling 
{{h2.executeSqlQueryWithTimer(null, c, "SELECT PLAN FROM "...}} in 
{{GridReduceQueryExecutor#explainPlan}}?

- please create an explicit class for new map's key in {{IgniteH2Indexing}}

- in {{IgniteH2Indexing#unregisterCache}}, we don't touch new {{connCache}} map 
at all, we should traverse all its elements and close/remove everything we 
don't need. Also we mutate {{conns}} without touching {{connCache}} in 
{{cancelAllQueries}} and {{stop}}. All in all I believe we should remove 
{{conns}} ultimately and leave map only - in fact, we don't benefit from that 
Set in any way now that we have single Map for everything (I don't see any 
random access cases for which Set semantic would be useful, we either always 
have a full key  or iterate over all collection anyway).







was (Author: al.psc):
[~skalashnikov]
my comments:

- are we right to pass {{null}} as first arg when calling 
{{h2.executeSqlQueryWithTimer(null, c, "SELECT PLAN FROM "...}} in 
{{GridReduceQueryExecutor#explainPlan}}?

- please create an explicit class for new map's key in {{IgniteH2Indexing}}

- in {{IgniteH2Indexing#unregisterCache}}, we don't touch new {{connCache}} map 
at all, we should traverse all its elements and close/remove everything we 
don't need. Also we mutate {{conns}} without touching {{connCache}} in 
{{cancelAllQueries}} and {{stop}}. All in all I believe we should remove 
{{conns}} at all and leave map only - in fact, we don't benefit for it in any 
way (I don't see any random access cases for which Set semantic would be 
useful, we either always have a full key  or iterate over all 
collection anyway).






> SQL: frequent switch between schemas cause severe slowdown
> --
>
> Key: IGNITE-5382
> URL: https://issues.apache.org/jira/browse/IGNITE-5382
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: important, performance
> Fix For: 2.2
>
>
> We have thread-bound cached connection to H2 database which is bound to 
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command, 
> which is rather expensive and may cause slowdown when queries form different 
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be 
> careful with concurrency and resource leaks.



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

[jira] [Commented] (IGNITE-5382) SQL: frequent switch between schemas cause severe slowdown

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-5382:
-

[~skalashnikov]
my comments:

- are we right to pass {{null}} as first arg when calling 
{{h2.executeSqlQueryWithTimer(null, c, "SELECT PLAN FROM "...}} in 
{{GridReduceQueryExecutor#explainPlan}}?

- please create an explicit class for new map's key in {{IgniteH2Indexing}}

- in {{IgniteH2Indexing#unregisterCache}}, we don't touch new {{connCache}} map 
at all, we should traverse all its elements and close/remove everything we 
don't need. Also we mutate {{conns}} without touching {{connCache}} in 
{{cancelAllQueries}} and {{stop}}. All in all I believe we should remove 
{{conns}} at all and leave map only - in fact, we don't benefit for it in any 
way (I don't see any random access cases for which Set semantic would be 
useful, we either always have a full key  or iterate over all 
collection anyway).






> SQL: frequent switch between schemas cause severe slowdown
> --
>
> Key: IGNITE-5382
> URL: https://issues.apache.org/jira/browse/IGNITE-5382
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: important, performance
> Fix For: 2.2
>
>
> We have thread-bound cached connection to H2 database which is bound to 
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command, 
> which is rather expensive and may cause slowdown when queries form different 
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be 
> careful with concurrency and resource leaks.



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

[jira] [Resolved] (IGNITE-5816) Race in WAL segment leading to ClosedChannelException

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk resolved IGNITE-5816.
--
Resolution: Fixed

Merged

> Race in WAL segment leading to ClosedChannelException
> -
>
> Key: IGNITE-5816
> URL: https://issues.apache.org/jira/browse/IGNITE-5816
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 2.2
>
>
> In current flushOrWait() code we acquire writtenBytes before we try to flush. 
> If flush fails, we wait for written be equal to expWritten.
> When a segment is being closed, this leads to one thread returning from 
> flushOrWait early because written is updated, but expWritten does not match 
> the last record position.



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

[jira] [Commented] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov commented on IGNITE-4172:
--

This ticket has been fixed in the scope of 
[https://issues.apache.org/jira/browse/IGNITE-5483].
Only tests are introduced in the scope of this particular ticket.

> SQL: Add support for Java 8 Time API classes in date\time functions
> ---
>
> Key: IGNITE-4172
> URL: https://issues.apache.org/jira/browse/IGNITE-4172
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrew Mashenkov
>Assignee: Alexandr Fedotov
> Fix For: 2.2
>
>
> We have is issue with querying LocalDateTime objects with our SQL engine. 
> Next query can fails with error, if one of row localDateTimeField value has 
> zero-time: 
> select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t;
> Startpoint is IgniteH2Indexing.wrap() method. 
> We need add support to these classes: LocalDate, LocalTime, LocalDateTime.



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

[jira] [Updated] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-4172:
-
Affects Version/s: (was: 1.7)
   (was: 1.6)

> SQL: Add support for Java 8 Time API classes in date\time functions
> ---
>
> Key: IGNITE-4172
> URL: https://issues.apache.org/jira/browse/IGNITE-4172
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrew Mashenkov
>Assignee: Alexandr Fedotov
> Fix For: 2.2
>
>
> We have is issue with querying LocalDateTime objects with our SQL engine. 
> Next query can fails with error, if one of row localDateTimeField value has 
> zero-time: 
> select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t;
> Startpoint is IgniteH2Indexing.wrap() method. 
> We need add support to these classes: LocalDate, LocalTime, LocalDateTime.



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

[jira] [Commented] (IGNITE-5856) BLAS integration phase 1

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5856:


[~amalykh] please take a look.

> BLAS integration phase 1
> 
>
> Key: IGNITE-5856
> URL: https://issues.apache.org/jira/browse/IGNITE-5856
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>
> (i) BLAS multiplication for dense and sparse local matrices.



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

[jira] [Created] (IGNITE-5871) IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed fails

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-5871:
-

 Summary: 
IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed
 fails
 Key: IGNITE-5871
 URL: https://issues.apache.org/jira/browse/IGNITE-5871
 Project: Ignite
  Issue Type: Bug
Reporter: Eduard Shangareev


Success rate is 20%.

http://ci.ignite.apache.org/project.html?tab=testDetails=Ignite20Tests=-720637123828878=10

Seems that it was broken in build #179, where [~sboikov] had merged cache 
groupd (ignite-5075)



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

[jira] [Updated] (IGNITE-5871) IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed fails

[Eduard Shangareev (JIRA)]

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

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

> IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed
>  fails
> 
>
> Key: IGNITE-5871
> URL: https://issues.apache.org/jira/browse/IGNITE-5871
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>  Labels: MakeTeamcityGreenAgain
>
> Success rate is 20%.
> http://ci.ignite.apache.org/project.html?tab=testDetails=Ignite20Tests=-720637123828878=10
> Seems that it was broken in build #179, where [~sboikov] had merged cache 
> groupd (ignite-5075)



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

[jira] [Updated] (IGNITE-5870) IgniteTopologyValidatorGridSplitCacheTest#testTopologyValidator fails

[Eduard Shangareev (JIRA)]

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

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

> IgniteTopologyValidatorGridSplitCacheTest#testTopologyValidator fails
> -
>
> Key: IGNITE-5870
> URL: https://issues.apache.org/jira/browse/IGNITE-5870
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>  Labels: MakeTeamcityGreenAgain
>
> Success rate is 10%.
> History is too short to say when it starts failing.
> http://ci.ignite.apache.org/project.html?tab=testDetails=Ignite20Tests=-318150309218360964=1



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

[jira] [Created] (IGNITE-5870) IgniteTopologyValidatorGridSplitCacheTest#testTopologyValidator fails

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-5870:
-

 Summary: 
IgniteTopologyValidatorGridSplitCacheTest#testTopologyValidator fails
 Key: IGNITE-5870
 URL: https://issues.apache.org/jira/browse/IGNITE-5870
 Project: Ignite
  Issue Type: Bug
Reporter: Eduard Shangareev


Success rate is 10%.
History is too short to say when it starts failing.

http://ci.ignite.apache.org/project.html?tab=testDetails=Ignite20Tests=-318150309218360964=1



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

[jira] [Updated] (IGNITE-5869) Unexpected timeout exception while client connected with different BinaryConfiguration compactFooter param.

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-5869:
---
Attachment: TcpClientDiscoveryMarshallerCheckSelfTest.java

> Unexpected timeout exception while client connected with different 
> BinaryConfiguration compactFooter param.
> ---
>
> Key: IGNITE-5869
> URL: https://issues.apache.org/jira/browse/IGNITE-5869
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
> Attachments: TcpClientDiscoveryMarshallerCheckSelfTest.java
>
>
> While client connecting with different from cluster 
> BinaryConfiguration::setCompactFooter param, instead of expecting: 
> "configuration is not equal" exception catch: Join process timed out 
> exception.



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

[jira] [Created] (IGNITE-5868) Fix Activate/Deactivate cluster suite for windows agents

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-5868:
--

 Summary: Fix Activate/Deactivate cluster suite for windows agents
 Key: IGNITE-5868
 URL: https://issues.apache.org/jira/browse/IGNITE-5868
 Project: Ignite
  Issue Type: Test
Reporter: Dmitriy Pavlov


Failed on windows agents, all from 134 tests were failed.
Passed on linux

http://ci.ignite.apache.org/viewLog.html?buildId=744004=buildResultsDiv=Ignite20Tests_IgniteActivateDeactivateCluster

{noformat}
org.apache.ignite.IgniteCheckedException: Work directory path must be absolute: 
\data\teamcity\tmpfs\work
at 
org.apache.ignite.internal.util.IgniteUtils.workDirectory(IgniteUtils.java:9056)
at 
org.apache.ignite.internal.util.IgniteUtils.defaultWorkDirectory(IgniteUtils.java:9023)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.beforeTestsStarted(GridAbstractTest.java:539)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.setUp(GridAbstractTest.java:598)
at 
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.setUp(GridCommonAbstractTest.java:482)
{noformat}



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

[jira] [Commented] (IGNITE-5866) JettyRestProcessorUnsignedSelfTest and JettyRestProcessorSignedSelfTest fails on master

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-5866:
-

US - http://reviews.ignite.apache.org/ignite/review/IGNT-CR-247
PR - https://github.com/apache/ignite/pull/2359

> JettyRestProcessorUnsignedSelfTest and JettyRestProcessorSignedSelfTest fails 
> on master
> ---
>
> Key: IGNITE-5866
> URL: https://issues.apache.org/jira/browse/IGNITE-5866
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.1
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.2
>
>
> JettyRestProcessorSignedSelfTest and JettyRestProcessorUnsignedSelfTest fails 
> on master
> when run whole test class.
> If run single method both tests succeed.
> testMetadataLocal:
> {noformat}
> junit.framework.AssertionFailedError: expected:<5> but was:<6>
>   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.rest.JettyRestProcessorAbstractSelfTest.testMetadataLocal(JettyRestProcessorAbstractSelfTest.java:1127)
> {noformat}
> testMetadataRemote
> {noformat}
> junit.framework.AssertionFailedError: expected:<6> but was:<7>
>   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.rest.JettyRestProcessorAbstractSelfTest.testMetadataRemote(JettyRestProcessorAbstractSelfTest.java:1174)
> {noformat}



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

[jira] [Updated] (IGNITE-4784) Web Console: Revise demo mode

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-4784:
--
Description: 
Let's add animated blue line.
Demo: https://marvelapp.com/32e928b

# Link 'Close Demo' should be red onhover.
# We should use affix behaviour (*y)

  was:
Let's add animated blue line.
Demo: https://marvelapp.com/32e928b

Link 'Close Demo' should be red onhover.


> Web Console: Revise demo mode
> -
>
> Key: IGNITE-4784
> URL: https://issues.apache.org/jira/browse/IGNITE-4784
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
>
> Let's add animated blue line.
> Demo: https://marvelapp.com/32e928b
> # Link 'Close Demo' should be red onhover.
> # We should use affix behaviour (*y)



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

[jira] [Updated] (IGNITE-5621) CPP: Support BINARY and VARBINARY types for C++

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-5621:

Description: We need to add an ability for user to get columns of 
{{byte[]}} types using {{SqlFieldsQuery}} in C++. Also, we need to add ability 
to add SQL parameters of type {{byte[]}} using C++.  (was: We need to add an 
ability for user to get columns of {{byte[]}} types using {{SqlFieldsQuery}} in 
C++.)

> CPP: Support BINARY and VARBINARY types for C++
> ---
>
> Key: IGNITE-5621
> URL: https://issues.apache.org/jira/browse/IGNITE-5621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.2
>
>
> We need to add an ability for user to get columns of {{byte[]}} types using 
> {{SqlFieldsQuery}} in C++. Also, we need to add ability to add SQL parameters 
> of type {{byte[]}} using C++.



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

[jira] [Created] (IGNITE-5867) Web console: Add parameter for adding primary key columns to generated POJO class

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-5867:
-

 Summary: Web console: Add parameter for adding primary key columns 
to generated POJO class
 Key: IGNITE-5867
 URL: https://issues.apache.org/jira/browse/IGNITE-5867
 Project: Ignite
  Issue Type: Improvement
Reporter: Evgenii Zhuravlev






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

[jira] [Assigned] (IGNITE-5867) Web console: Add parameter for adding primary key columns to generated POJO class

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev reassigned IGNITE-5867:
-

Assignee: Alexey Kuznetsov

> Web console: Add parameter for adding primary key columns to generated POJO 
> class
> -
>
> Key: IGNITE-5867
> URL: https://issues.apache.org/jira/browse/IGNITE-5867
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Kuznetsov
>




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

[jira] [Commented] (IGNITE-5866) JettyRestProcessorUnsignedSelfTest and JettyRestProcessorSignedSelfTest fails on master

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5866:


GitHub user nizhikov opened a pull request:

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

IGNITE-5866: Fix tests



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

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

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

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


commit 87ffac598b89c95fc87e546ae1b535232fd91bcd
Author: Nikolay Izhikov 
Date:   2017-07-28T12:31:06Z

IGNITE-5866: Fix tests




> JettyRestProcessorUnsignedSelfTest and JettyRestProcessorSignedSelfTest fails 
> on master
> ---
>
> Key: IGNITE-5866
> URL: https://issues.apache.org/jira/browse/IGNITE-5866
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.1
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.2
>
>
> JettyRestProcessorSignedSelfTest and JettyRestProcessorUnsignedSelfTest fails 
> on master
> when run whole test class.
> If run single method both tests succeed.
> testMetadataLocal:
> {noformat}
> junit.framework.AssertionFailedError: expected:<5> but was:<6>
>   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.rest.JettyRestProcessorAbstractSelfTest.testMetadataLocal(JettyRestProcessorAbstractSelfTest.java:1127)
> {noformat}
> testMetadataRemote
> {noformat}
> junit.framework.AssertionFailedError: expected:<6> but was:<7>
>   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.rest.JettyRestProcessorAbstractSelfTest.testMetadataRemote(JettyRestProcessorAbstractSelfTest.java:1174)
> {noformat}



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

[jira] [Updated] (IGNITE-5621) CPP: Support BINARY and VARBINARY types for C++

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-5621:

Description: We need to add an ability for user to get columns of 
{{byte[]}} types using {{SqlFieldsQuery}} in C++.  (was: We need to support 
BINARY and VARBINARY types at C++ and ODBC levels.)

> CPP: Support BINARY and VARBINARY types for C++
> ---
>
> Key: IGNITE-5621
> URL: https://issues.apache.org/jira/browse/IGNITE-5621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.2
>
>
> We need to add an ability for user to get columns of {{byte[]}} types using 
> {{SqlFieldsQuery}} in C++.



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

[jira] [Updated] (IGNITE-5777) BLAS integration

[Yury Babak (JIRA)]

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

Yury Babak updated IGNITE-5777:
---
Issue Type: New Feature  (was: Task)

> BLAS integration
> 
>
> Key: IGNITE-5777
> URL: https://issues.apache.org/jira/browse/IGNITE-5777
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>
> Replace all naive computations by BLAS from 5278



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

[jira] [Commented] (IGNITE-5856) BLAS integration phase 1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5856:


GitHub user ybabak opened a pull request:

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

IGNITE-5856: BLAS integration phase 1

The first part of BLAS integration with Ignite ML. Current only gemm for 
local matrix multiply.

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

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

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

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


commit e6482b49c551528b1db9ae5ad21dabe607e7401e
Author: Yury Babak 
Date:   2017-07-27T19:42:13Z

IGNITE-5777: BLAS integration phase 1
- used gemm for Matrix.times()
- Some fixes.

commit 95a58c7649c281c1c7db0bae1ed8ed5a01741267
Author: Yury Babak 
Date:   2017-07-28T11:55:11Z

IGNITE-5777: BLAS integration phase 1
- Code cleanup.




> BLAS integration phase 1
> 
>
> Key: IGNITE-5856
> URL: https://issues.apache.org/jira/browse/IGNITE-5856
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>
> (i) BLAS multiplication for dense and sparse local matrices.



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

[jira] [Created] (IGNITE-5866) JettyRestProcessorUnsignedSelfTest and JettyRestProcessorSignedSelfTest fails on master

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-5866:
---

 Summary: JettyRestProcessorUnsignedSelfTest and 
JettyRestProcessorSignedSelfTest fails on master
 Key: IGNITE-5866
 URL: https://issues.apache.org/jira/browse/IGNITE-5866
 Project: Ignite
  Issue Type: Bug
  Components: clients
Affects Versions: 2.1
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
 Fix For: 2.2


JettyRestProcessorSignedSelfTest and JettyRestProcessorUnsignedSelfTest fails 
on master
when run whole test class.
If run single method both tests succeed.

testMetadataLocal:

{noformat}
junit.framework.AssertionFailedError: expected:<5> but was:<6>
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.rest.JettyRestProcessorAbstractSelfTest.testMetadataLocal(JettyRestProcessorAbstractSelfTest.java:1127)
{noformat}

testMetadataRemote
{noformat}
junit.framework.AssertionFailedError: expected:<6> but was:<7>
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.rest.JettyRestProcessorAbstractSelfTest.testMetadataRemote(JettyRestProcessorAbstractSelfTest.java:1174)
{noformat}





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

[jira] [Commented] (IGNITE-5792) IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint is failing on TC

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-5792:
-

IGNITE-5302 describes very similar issue with broken partition update counters 
after resetLostPartitions call.

> IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint 
> is failing on TC
> 
>
> Key: IGNITE-5792
> URL: https://issues.apache.org/jira/browse/IGNITE-5792
> Project: Ignite
>  Issue Type: Test
>  Components: persistence
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>  Labels: MakeTeamcityGreenAgain, test-fail
>
> Test 
> IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint 
> started failing on TC.
> Failures must be investigated and fixed.



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

[jira] [Commented] (IGNITE-5863) Implement common component to show item selected for table

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-5863:


Reviewed. Looks good. Merged.

> Implement common component to show item selected for table
> --
>
> Key: IGNITE-5863
> URL: https://issues.apache.org/jira/browse/IGNITE-5863
> Project: Ignite
>  Issue Type: Improvement
>  Components: UI, wizards
>Affects Versions: 2.2
>Reporter: Dmitriy Shabalin
>Assignee: Andrey Novikov
>




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

[jira] [Updated] (IGNITE-5773) Scheduler throwing NullPointerException

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-5773:
---
Description: 
NPE occurs during deploying a service as cluster singleton. Ignite scheduler is 
used as a cron for this purpose, however NPE occurs for ignite version 2.0.0.

Below is the log information for the exception:
{noformat}
2017-06-06 13:21:08 ERROR GridServiceProcessor:495 - Failed to initialize 
service (service will not be deployed): AVxezSbWNphcxa1CYjfP
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.schedule.ScheduleFutureImpl.schedule(ScheduleFutureImpl.java:299)
at 
org.apache.ignite.internal.processors.schedule.IgniteScheduleProcessor.schedule(IgniteScheduleProcessor.java:56)
at 
org.apache.ignite.internal.IgniteSchedulerImpl.scheduleLocal(IgniteSchedulerImpl.java:109)
at 
com.mypackage.state.services.MyService.startScheduler(MyService.scala:172)
at com.mypackage.state.services.MyService.init(MyService.scala:149)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.redeploy(GridServiceProcessor.java:1097)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.processAssignment(GridServiceProcessor.java:1698)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.onSystemCacheUpdated(GridServiceProcessor.java:1372)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.access$300(GridServiceProcessor.java:117)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceEntriesListener$1.run0(GridServiceProcessor.java:1339)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1753)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
2017-06-06 13:21:08:868 ERROR application - Unable to initialise GRID:
class org.apache.ignite.IgniteException: null
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:949)
at 
org.apache.ignite.internal.IgniteServicesImpl.deployClusterSingleton(IgniteServicesImpl.java:122)
at 
com.mypackage.state.mypackage1.InitialiseGrid$$anonfun$apply$1.apply(InitialiseGrid.scala:22)
at 
com.mypackage.state.mypackage1.InitialiseGrid$$anonfun$apply$1.apply(InitialiseGrid.scala:19)
at 
scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
at 
com.mypackage.state.mypackage1.InitialiseGrid$.apply(InitialiseGrid.scala:19)
at com.mypackage.state.Application$.main(Application.scala:54)
at com.mypackage.state.Application.main(Application.scala)
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:498)
at sbt.Run.invokeMain(Run.scala:67)
at sbt.Run.run0(Run.scala:61)
at sbt.Run.sbt$Run$$execute$1(Run.scala:51)
at sbt.Run$$anonfun$run$1.apply$mcV$sp(Run.scala:55)
at sbt.Run$$anonfun$run$1.apply(Run.scala:55)
at sbt.Run$$anonfun$run$1.apply(Run.scala:55)
at sbt.Logger$$anon$4.apply(Logger.scala:85)
at sbt.TrapExit$App.run(TrapExit.scala:248)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteCheckedException: null
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7242)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
at 
org.apache.ignite.internal.AsyncSupportAdapter.saveOrGet(AsyncSupportAdapter.java:112)
at 
org.apache.ignite.internal.IgniteServicesImpl.deployClusterSingleton(IgniteServicesImpl.java:119)
... 20 more
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.schedule.ScheduleFutureImpl.schedule(ScheduleFutureImpl.java:299)
at 
org.apache.ignite.internal.processors.schedule.IgniteScheduleProcessor.schedule(IgniteScheduleProcessor.java:56)
at 
org.apache.ignite.internal.IgniteSchedulerImpl.scheduleLocal(IgniteSchedulerImpl.java:109)
at 
com.mypackage.state.services.MyService.startScheduler(MyService.scala:172)
at 

[jira] [Closed] (IGNITE-5863) Implement common component to show item selected for table

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-5863.
--
Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Implement common component to show item selected for table
> --
>
> Key: IGNITE-5863
> URL: https://issues.apache.org/jira/browse/IGNITE-5863
> Project: Ignite
>  Issue Type: Improvement
>  Components: UI, wizards
>Affects Versions: 2.2
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
>




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

[jira] [Commented] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-5302:
-

The same behavior is observed for *testRebalancingOnRestartAfterCheckpoint* 
test.

It was found that sometimes in four-nodes cluster after stopping two nodes some 
partitions on left nodes get [re]created and partition update counters are 
initialized to zero.

After returning stopped nodes back to cluster partitions from them are 
considered as up-to-date although they should have been declared as outdated 
and rebalanced from other nodes.

> Empty LOST partition may be used as OWNING after resetting lost partitions
> --
>
> Key: IGNITE-5302
> URL: https://issues.apache.org/jira/browse/IGNITE-5302
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.2
>
>
> h2. Notes
> Test *testPartitionLossAndRecover* reproducing the issue can be found in 
> ignite-5267 branch with PDS functionality.
> h2. Steps to reproduce
> # Four nodes are started, some key is added to partitioned cache
> # Primary and backup nodes for the key are stopped, key's partition is 
> declared LOST on remaining nodes
> # Primary and backup nodes are started again, cache's lost partitions are 
> reset
> # Key is requested from cache
> h2. Expected behavior
> Correct value is returned from primary for this partition
> h2. Actual behavior
> Request for value is sent to node where partition is empty (not to primary 
> node), null is returned
> h2. Latest findings
> # The main problem with the scenario is that request for key gets mapped not 
> only to P/B nodes with real value but also to the node where that partition 
> existed only in LOST state after P/B shutdown on step #2
> # It was found that on step #3 after primary and backup are joined partition 
> counter is increased for empty partition in LOST state which looks wrong



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

[jira] [Updated] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-5302:

Fix Version/s: 2.2

> Empty LOST partition may be used as OWNING after resetting lost partitions
> --
>
> Key: IGNITE-5302
> URL: https://issues.apache.org/jira/browse/IGNITE-5302
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.2
>
>
> h2. Notes
> Test *testPartitionLossAndRecover* reproducing the issue can be found in 
> ignite-5267 branch with PDS functionality.
> h2. Steps to reproduce
> # Four nodes are started, some key is added to partitioned cache
> # Primary and backup nodes for the key are stopped, key's partition is 
> declared LOST on remaining nodes
> # Primary and backup nodes are started again, cache's lost partitions are 
> reset
> # Key is requested from cache
> h2. Expected behavior
> Correct value is returned from primary for this partition
> h2. Actual behavior
> Request for value is sent to node where partition is empty (not to primary 
> node), null is returned
> h2. Latest findings
> # The main problem with the scenario is that request for key gets mapped not 
> only to P/B nodes with real value but also to the node where that partition 
> existed only in LOST state after P/B shutdown on step #2
> # It was found that on step #3 after primary and backup are joined partition 
> counter is increased for empty partition in LOST state which looks wrong



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

[jira] [Updated] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-5302:

Priority: Blocker  (was: Major)

> Empty LOST partition may be used as OWNING after resetting lost partitions
> --
>
> Key: IGNITE-5302
> URL: https://issues.apache.org/jira/browse/IGNITE-5302
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.2
>
>
> h2. Notes
> Test *testPartitionLossAndRecover* reproducing the issue can be found in 
> ignite-5267 branch with PDS functionality.
> h2. Steps to reproduce
> # Four nodes are started, some key is added to partitioned cache
> # Primary and backup nodes for the key are stopped, key's partition is 
> declared LOST on remaining nodes
> # Primary and backup nodes are started again, cache's lost partitions are 
> reset
> # Key is requested from cache
> h2. Expected behavior
> Correct value is returned from primary for this partition
> h2. Actual behavior
> Request for value is sent to node where partition is empty (not to primary 
> node), null is returned
> h2. Latest findings
> # The main problem with the scenario is that request for key gets mapped not 
> only to P/B nodes with real value but also to the node where that partition 
> existed only in LOST state after P/B shutdown on step #2
> # It was found that on step #3 after primary and backup are joined partition 
> counter is increased for empty partition in LOST state which looks wrong



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

[jira] [Commented] (IGNITE-5859) IgniteUtils.ceilPow2 overflow for values greater than 2^30

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5859:


[~avinogradov] looks fine for me.

[~VitaliyB] please run all related tests on TC and link the result, just for 
avoid of regression.

> IgniteUtils.ceilPow2 overflow for values greater than 2^30
> --
>
> Key: IGNITE-5859
> URL: https://issues.apache.org/jira/browse/IGNITE-5859
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov 
>Assignee: Vitaliy Biryukov 
> Attachments: CeilPow2Test.java
>
>
> Method "IgniteUtils.ceilPow2" can overflow for values greater than 2^30 and 
> return Integer.MIN_VALUE for them.
> Maybe this check was skipped for method speed. In this case, we need to add 
> information about this into javaDoc.



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

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-5865:
---
Labels: MakeTeamcityGreenAgain Muted_test test-failure  (was: test-failure)

> 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
>  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, 
> xidVer=null]]], super=IgniteTxAdapter [xidVer=GridCacheVersion 
> [topVer=112692678, order=1501212673314, nodeOrder=1], writeVer=null, 
> implicit=false, loc=true, threadId=847, startTime=1501212712015, 
> nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, 

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

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-5865:
---

 Summary: 
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
 Fix For: 2.2


Test is flaky.

Also there is always failing test in suite: 
TxOptimisticDeadlockDetectionTest.testDeadlocksPartitionedNear

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, 
xidVer=null]]], super=IgniteTxAdapter [xidVer=GridCacheVersion 
[topVer=112692678, order=1501212673314, nodeOrder=1], writeVer=null, 
implicit=false, loc=true, threadId=847, startTime=1501212712015, 
nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, startVer=GridCacheVersion 
[topVer=112692678, order=1501212673314, nodeOrder=1], endVer=null, 
isolation=REPEATABLE_READ, concurrency=OPTIMISTIC, timeout=800, 
sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion 
[topVer=112692678, order=1501212673314, nodeOrder=1], finalizing=NONE, 
invalidParts=null, state=MARKED_ROLLBACK, timedOut=false, 
topVer=AffinityTopologyVersion [topVer=8, minorTopVer=8], duration=808ms, 
onePhaseCommit=false], size=1]]]
class org.apache.ignite.internal.transactions.IgniteTxTimeoutCheckedException: 
Failed to acquire lock within provided timeout for transaction 

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

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-5865:

Description: 
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, 
xidVer=null]]], super=IgniteTxAdapter [xidVer=GridCacheVersion 
[topVer=112692678, order=1501212673314, nodeOrder=1], writeVer=null, 
implicit=false, loc=true, threadId=847, startTime=1501212712015, 
nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, startVer=GridCacheVersion 
[topVer=112692678, order=1501212673314, nodeOrder=1], endVer=null, 
isolation=REPEATABLE_READ, concurrency=OPTIMISTIC, timeout=800, 
sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion 
[topVer=112692678, order=1501212673314, nodeOrder=1], finalizing=NONE, 
invalidParts=null, state=MARKED_ROLLBACK, timedOut=false, 
topVer=AffinityTopologyVersion [topVer=8, minorTopVer=8], duration=808ms, 
onePhaseCommit=false], size=1]]]
class org.apache.ignite.internal.transactions.IgniteTxTimeoutCheckedException: 
Failed to acquire lock within provided timeout for transaction [timeout=800, 
tx=GridDhtTxLocal [nearNodeId=d005de76-4378-4cd5-ad7e-f00593a2, 

[jira] [Commented] (IGNITE-5729) IgniteCacheProxy instances from "with..." methods are not reusable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5729:


GitHub user Jokser opened a pull request:

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

IGNITE-5729 Memoize GatewayProtectedProxy



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-5729-reference-fix

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

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


commit 00babb4bcb0d432ae614a3cb98dfa7a61dfdbc1c
Author: Pavel Kovalenko 
Date:   2017-07-25T12:50:43Z

IGNITE-5829 Linked TODO with ticket.

commit 243913ee24fbc09d0ae5469bb1d99926b1a8e8d5
Author: EdShangGG 
Date:   2017-07-25T13:50:35Z

IGNITE-5747 GridCommonAbstractTest.startGridsMultiThreaded works very 
slowly if persistence is enabled - Fixes #2294.

Signed-off-by: Alexey Goncharuk 

commit 85f17027d0ca7cfa6dfaa3711ad8b4a7a6eb1e79
Author: Aleksandr_Meterko 
Date:   2017-07-19T12:55:15Z

IGNITE-5781 Visor throws ClassCastException if cache store implementation 
is other than CacheJdbcPojoStore
Signed-off-by: Konstantin Boudnik 
(cherry picked from commit 02e2507)

commit 7915fd88b1f3e399777bbc46f4e5625b68fb90c9
Author: Jokser 
Date:   2017-07-26T09:08:03Z

IGNITE-5830 - Introduce cache start and stop order during cluster activation

commit a790dface730eae11f98c6b6f74232f0ec32cf6b
Author: Ivan Rakov 
Date:   2017-07-26T10:41:33Z

Failing flaky test with link to ticket number

commit e001a063a9c2260c4732093e54c332cb8af33b0b
Author: EdShangGG 
Date:   2017-07-26T13:37:45Z

new utility methods for working with files

commit 50c5b1dfc1cf182f42bd36dc5d5757f61180ff36
Author: EdShangGG 
Date:   2017-07-26T13:38:08Z

small improvements in abstract tests
-checking "checkTopology" flag in startGridsMultiThreaded
-auto cluster activation in startGridsMultiThreaded

commit 586a96eaf4570f4f2020041cfef07550025421d8
Author: Evgeny Stanilovskiy 
Date:   2017-07-26T15:49:41Z

IGNITE-5174: list only server nodes for specified topology version

Fixes #2312

commit b49469f469e3ad9f64d009a474b6e09686ec9203
Author: Dmitriy Shabalin 
Date:   2017-07-27T03:39:54Z

IGNITE-5835 Web Console: Highlight active element in select input.

commit 995258f9a326bb5a08b1e004d92e2760c25f20c0
Author: Vasiliy Sisko 
Date:   2017-07-27T04:06:52Z

IGNITE-5767 Web Console: Changed mapping for BINARY SQL type to byte[].

commit bcbb10d4ed72c3ac2cd8149bb5cd148f63e95725
Author: Igor Seliverstov 
Date:   2017-07-27T06:44:34Z

IGNITE-5761 Add correct message when entries are not mapped to at least one 
node and avoid hang on rollback

commit 5172541f71e9878b4cc9df18580cdf1863a5820b
Author: Pavel Kovalenko 
Date:   2017-07-27T07:41:41Z

IGNITE-5729 - IgniteCacheProxy instances from with() methods are not 
reusable after cache restart

commit 9825eaa35c5c95485f7d7c3b60de7d0ca47dad23
Author: Alexey Goncharuk 
Date:   2017-07-27T07:42:30Z

IGNITE-5761 - Fixed header license

commit 004e5aa7df72a16efb02e7500b56475916515ba7
Author: Alexey Goncharuk 
Date:   2017-07-27T08:42:09Z

IGNITE-5729 - Removed RendezvousAffinityFunction with extra partitions in 
GridCacheAbstractSelfTest

commit be5a9eaf77877b02a46f30730cd6d8e1e3919f41
Author: Sergey Chugunov 
Date:   2017-07-27T10:02:59Z

GG-12485 added test to verify issue on 8.1.x version

commit a07d7b91d148df8dfd7c4bbad2a63f8dea97b036
Author: Alexandr Kuramshin 
Date:   2017-07-27T12:04:42Z

IGNITE-4767: rollback exception hides the origin exception (e.g. commit): 
Suppressing or logging rollback exceptions instead of hiding the origin 
exception
Fixes #1599

commit 98a524067b2d2349c558256ee38efdf81e0ba7ff
Author: Igor Sapego 
Date:   2017-07-27T16:39:51Z

IGNITE-5771: Added Ignite::SetActive() for C++

(cherry picked from commit 47fea40)

commit 6031ed85aa0242e8a56dee43c14c73bcafa7fab7
Author: vsisko 
Date:   2017-07-28T02:54:07Z

GG-12544 Removed limitation for stacktrace showing.

commit 9d9e472e679ac85e07767623bb314e8cea2ea7d8
Author: Pavel Kovalenko 
Date:   2017-07-28T10:21:04Z

IGNITE-5729 

[jira] [Commented] (IGNITE-5758) CPP: Add pointer semantics for primitive types

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5758:


[~isapego] looks good to me.

> CPP: Add pointer semantics for primitive types
> --
>
> Key: IGNITE-5758
> URL: https://issues.apache.org/jira/browse/IGNITE-5758
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently, we can write any user object using two types of semantics:
> {code}
> // Basic
> writer.WriteObject(obj);
> // Pointer-based
> writer.WriteObject();
> {code}
> However, this does not work for primitive types:
> {code}
> // Basic. Works just fine
> writer.WriteObject(str);
> // Pointer-based. Compilation error.
> writer.WriteObject();
> {code}
> Need to add support of the pointer semantics for the primitive types as well.



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

[jira] [Created] (IGNITE-5864) .NET: LINQPad ComputeExample missing namespace import

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5864:
--

 Summary: .NET: LINQPad ComputeExample missing namespace import
 Key: IGNITE-5864
 URL: https://issues.apache.org/jira/browse/IGNITE-5864
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.2


{{Apache.Ignite.Core.Deployment}} namespace import is missing in 
{{ComputeExample.linq}}, it does not compile without manual changes.



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

[jira] [Assigned] (IGNITE-5860) Client disconnects if server it is connected to goes unresponsive

[Denis Mekhanikov (JIRA)]

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

Denis Mekhanikov reassigned IGNITE-5860:


Assignee: Denis Mekhanikov

> Client disconnects if server it is connected to goes unresponsive 
> --
>
> Key: IGNITE-5860
> URL: https://issues.apache.org/jira/browse/IGNITE-5860
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Denis Mekhanikov
> Fix For: 2.2
>
>
> Scenario is the following:
> # Start at least two server nodes.
> # Start a client node.
> # Detect server node client is connected to in discovery SPI.
> # Suspend that server (^Z in terminal or 'kill -SIGSTOP ').
> # It's expected that client will drop connection with this server and 
> connect to another one.
> # However, a client gets dropped from topology and disconnects.
> A client should reconnect cluster before the timeout and without 
> EVT_CLIENT_NODE_RECONNECTED event.
> In ClientImpl.Reconnector in joinTopology method it gets all addresses from 
> discoverySpi and addresses of the server that was suspended on top of this 
> list.
> *Proposed solution:*
> Move addresses of the suspended server to the end of the list for the join.



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

[jira] [Resolved] (IGNITE-5864) .NET: LINQPad ComputeExample missing namespace import

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-5864.

Resolution: Fixed

> .NET: LINQPad ComputeExample missing namespace import
> -
>
> Key: IGNITE-5864
> URL: https://issues.apache.org/jira/browse/IGNITE-5864
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.2
>
>
> {{Apache.Ignite.Core.Deployment}} namespace import is missing in 
> {{ComputeExample.linq}}, it does not compile without manual changes.



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

[jira] [Commented] (IGNITE-5864) .NET: LINQPad ComputeExample missing namespace import

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5864:


Fixed in master: {{ab899cf2e383190b71cc8d7940f2880f8b6ee670}}

> .NET: LINQPad ComputeExample missing namespace import
> -
>
> Key: IGNITE-5864
> URL: https://issues.apache.org/jira/browse/IGNITE-5864
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.2
>
>
> {{Apache.Ignite.Core.Deployment}} namespace import is missing in 
> {{ComputeExample.linq}}, it does not compile without manual changes.



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

[jira] [Assigned] (IGNITE-5863) Implement common component to show item selected for table

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-5863:


Assignee: Andrey Novikov  (was: Dmitriy Shabalin)

Added. pls review it

> Implement common component to show item selected for table
> --
>
> Key: IGNITE-5863
> URL: https://issues.apache.org/jira/browse/IGNITE-5863
> Project: Ignite
>  Issue Type: Improvement
>  Components: UI, wizards
>Affects Versions: 2.2
>Reporter: Dmitriy Shabalin
>Assignee: Andrey Novikov
>




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

[jira] [Created] (IGNITE-5863) Implement common component to show item selected for table

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-5863:


 Summary: Implement common component to show item selected for table
 Key: IGNITE-5863
 URL: https://issues.apache.org/jira/browse/IGNITE-5863
 Project: Ignite
  Issue Type: Improvement
  Components: UI, wizards
Affects Versions: 2.2
Reporter: Dmitriy Shabalin






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

[jira] [Assigned] (IGNITE-5863) Implement common component to show item selected for table

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-5863:


Assignee: Dmitriy Shabalin

> Implement common component to show item selected for table
> --
>
> Key: IGNITE-5863
> URL: https://issues.apache.org/jira/browse/IGNITE-5863
> Project: Ignite
>  Issue Type: Improvement
>  Components: UI, wizards
>Affects Versions: 2.2
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
>




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

[jira] [Commented] (IGNITE-5712) Context switching for optimistic transactions

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-5712:
--

Hi,

Ok, you can keep synchronized if you wish, but probably it is not really 
needed. First scenario when resume is called from another before suspend 
finished is incorrect API usage, second case when several threads try resume is 
guarded by tx.state(ACTIVE).

Please  do last TeamCity run and I'll merge changes. 

Thanks!

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



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

[jira] [Resolved] (IGNITE-5858) Ignite Cache 5 Timeout: CacheLateAffinityAssignmentTests hangs after assertion error

[Semen Boikov (JIRA)]

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

Semen Boikov resolved IGNITE-5858.
--
Resolution: Fixed

Fixed hang in CacheLateAffinityAssignmentTest.

> Ignite Cache 5 Timeout: CacheLateAffinityAssignmentTests hangs after 
> assertion error
> 
>
> Key: IGNITE-5858
> URL: https://issues.apache.org/jira/browse/IGNITE-5858
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Dmitriy Pavlov
>Assignee: Semen Boikov
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: 
> lastStartedTest_CacheLateAffinityAssignmentTest.testRandomOperations.log.zip, 
> ThreadDump0.zip
>
>
> Reproduced for master:
> {noformat}
> Invalid affinity version [last=AffinityTopologyVersion [topVer=-1, 
> minorTopVer=0], 
> {noformat}
> Failed tests
> CacheLateAffinityAssignmentTest.testRandomOperations
> CacheLateAffinityAssignmentTest.testAffinitySimpleNoCacheOnCoordinator1
> Failed builds
> http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache5=buildTypeHistoryList_Ignite20Tests=%3Cdefault%3E
> Following builds were failed
> 742325,742326,742327,742328,742329,742330,742331,742332,742333,742334,742335,742336,742337,742338,742339,742340,742341,742342,742343,742344



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

[jira] [Created] (IGNITE-5862) PlatformMessageParser & PlatformRequestHandler

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5862:
--

 Summary: PlatformMessageParser & PlatformRequestHandler
 Key: IGNITE-5862
 URL: https://issues.apache.org/jira/browse/IGNITE-5862
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.2


Inherit {{SqlListenerMessageParser}} and {{SqlListenerRequestHandler}}, 
implement basic handshake protocol (see how {{OdbcMessageParser}} works).



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

[jira] [Updated] (IGNITE-5861) Basic cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5861:
---
Labels: .NET  (was: )

> Basic cache operations
> --
>
> Key: IGNITE-5861
> URL: https://issues.apache.org/jira/browse/IGNITE-5861
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.2
>
>
> Implement basic cache operations (put/get) via thin client (no Java 
> callbacks).
> This is a first step towards full API support and will show if any issues 
> emerge.



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

[jira] [Updated] (IGNITE-5549) Ignite Cache Failover2: test suite hands up for more than 2 hours

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-5549:
---
Description: 
{noformat}
[19:22:43] : [Step 4/5] [2017-06-19 16:22:43,352][INFO ][main][root] >>> 
Starting test: CacheAsyncOperationsFailoverTxTest#testPutAllAsyncFailover <<<
...
[19:24:43]W: [org.apache.ignite:ignite-core] [2017-06-19 
16:24:43,353][ERROR][main][root] Test has been timed out and will be 
interrupted (threads dump will be taken before interruption) 
[test=testPutAllAsyncFailover, timeout=12]
{noformat}

Failed builds: 675158, 674915, 674698, 727946

  was:
{noformat}
[19:22:43] : [Step 4/5] [2017-06-19 16:22:43,352][INFO ][main][root] >>> 
Starting test: CacheAsyncOperationsFailoverTxTest#testPutAllAsyncFailover <<<
...
[19:24:43]W: [org.apache.ignite:ignite-core] [2017-06-19 
16:24:43,353][ERROR][main][root] Test has been timed out and will be 
interrupted (threads dump will be taken before interruption) 
[test=testPutAllAsyncFailover, timeout=12]
{noformat}

Failed builds 
http://ci.ignite.apache.org/viewLog.html?buildId=675158=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2

http://ci.ignite.apache.org/viewLog.html?buildId=674915=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2

http://ci.ignite.apache.org/viewLog.html?buildId=674698=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2



> Ignite Cache Failover2: test suite hands up for more than 2 hours
> -
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>  Labels: MakeTeamcityGreenAgain, test-fail
>
> {noformat}
> [19:22:43] :   [Step 4/5] [2017-06-19 16:22:43,352][INFO ][main][root] >>> 
> Starting test: CacheAsyncOperationsFailoverTxTest#testPutAllAsyncFailover <<<
> ...
> [19:24:43]W:   [org.apache.ignite:ignite-core] [2017-06-19 
> 16:24:43,353][ERROR][main][root] Test has been timed out and will be 
> interrupted (threads dump will be taken before interruption) 
> [test=testPutAllAsyncFailover, timeout=12]
> {noformat}
> Failed builds: 675158, 674915, 674698, 727946



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

[jira] [Updated] (IGNITE-5861) Basic cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5861:
---
Description: 
Implement basic cache operations (put/get) via thin client (no Java callbacks).
This is a first step towards full API support and will show if any issues 
emerge.

> Basic cache operations
> --
>
> Key: IGNITE-5861
> URL: https://issues.apache.org/jira/browse/IGNITE-5861
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
> Fix For: 2.2
>
>
> Implement basic cache operations (put/get) via thin client (no Java 
> callbacks).
> This is a first step towards full API support and will show if any issues 
> emerge.



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

[jira] [Issue Comment Deleted] (IGNITE-5549) Ignite Cache Failover2: test suite hands up for more than 2 hours

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-5549:
---
Comment: was deleted

(was: Now suite is passing, 
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCacheFailover2_Ignite20Tests=pull%2F2157%2Fhead=buildTypeStatusDiv)

> Ignite Cache Failover2: test suite hands up for more than 2 hours
> -
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>  Labels: MakeTeamcityGreenAgain, test-fail
>
> {noformat}
> [19:22:43] :   [Step 4/5] [2017-06-19 16:22:43,352][INFO ][main][root] >>> 
> Starting test: CacheAsyncOperationsFailoverTxTest#testPutAllAsyncFailover <<<
> ...
> [19:24:43]W:   [org.apache.ignite:ignite-core] [2017-06-19 
> 16:24:43,353][ERROR][main][root] Test has been timed out and will be 
> interrupted (threads dump will be taken before interruption) 
> [test=testPutAllAsyncFailover, timeout=12]
> {noformat}
> Failed builds: 675158, 674915, 674698, 727946



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

[jira] [Comment Edited] (IGNITE-5549) Ignite Cache Failover2: test suite hands up for more than 2 hours

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-5549 at 7/28/17 7:09 AM:
-

Latest timeout
http://ci.ignite.apache.org/viewLog.html?buildId=744034=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2


was (Author: dpavlov):
Latest timeout
http://ci.ignite.apache.org/viewLog.html?buildId=727946=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2

> Ignite Cache Failover2: test suite hands up for more than 2 hours
> -
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>  Labels: MakeTeamcityGreenAgain, test-fail
>
> {noformat}
> [19:22:43] :   [Step 4/5] [2017-06-19 16:22:43,352][INFO ][main][root] >>> 
> Starting test: CacheAsyncOperationsFailoverTxTest#testPutAllAsyncFailover <<<
> ...
> [19:24:43]W:   [org.apache.ignite:ignite-core] [2017-06-19 
> 16:24:43,353][ERROR][main][root] Test has been timed out and will be 
> interrupted (threads dump will be taken before interruption) 
> [test=testPutAllAsyncFailover, timeout=12]
> {noformat}
> Failed builds 
> http://ci.ignite.apache.org/viewLog.html?buildId=675158=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2
> http://ci.ignite.apache.org/viewLog.html?buildId=674915=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2
> http://ci.ignite.apache.org/viewLog.html?buildId=674698=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2



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

[jira] [Updated] (IGNITE-5549) Ignite Cache Failover2: test suite hands up for more than 2 hours

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-5549:
---
Description: 
{noformat}
[19:22:43] : [Step 4/5] [2017-06-19 16:22:43,352][INFO ][main][root] >>> 
Starting test: CacheAsyncOperationsFailoverTxTest#testPutAllAsyncFailover <<<
...
[19:24:43]W: [org.apache.ignite:ignite-core] [2017-06-19 
16:24:43,353][ERROR][main][root] Test has been timed out and will be 
interrupted (threads dump will be taken before interruption) 
[test=testPutAllAsyncFailover, timeout=12]
{noformat}

Failed builds 
http://ci.ignite.apache.org/viewLog.html?buildId=675158=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2

http://ci.ignite.apache.org/viewLog.html?buildId=674915=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2

http://ci.ignite.apache.org/viewLog.html?buildId=674698=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2


  was:
{noformat}
[19:22:43] : [Step 4/5] [2017-06-19 16:22:43,352][INFO ][main][root] >>> 
Starting test: CacheAsyncOperationsFailoverTxTest#testPutAllAsyncFailover <<<
...
[19:24:43]W: [org.apache.ignite:ignite-core] [2017-06-19 
16:24:43,353][ERROR][main][root] Test has been timed out and will be 
interrupted (threads dump will be taken before interruption) 
[test=testPutAllAsyncFailover, timeout=12]
{noformat}

http://ci.ignite.apache.org/viewLog.html?buildId=675158=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2

http://ci.ignite.apache.org/viewLog.html?buildId=674915=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2

http://ci.ignite.apache.org/viewLog.html?buildId=674698=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2



> Ignite Cache Failover2: test suite hands up for more than 2 hours
> -
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>  Labels: MakeTeamcityGreenAgain, test-fail
>
> {noformat}
> [19:22:43] :   [Step 4/5] [2017-06-19 16:22:43,352][INFO ][main][root] >>> 
> Starting test: CacheAsyncOperationsFailoverTxTest#testPutAllAsyncFailover <<<
> ...
> [19:24:43]W:   [org.apache.ignite:ignite-core] [2017-06-19 
> 16:24:43,353][ERROR][main][root] Test has been timed out and will be 
> interrupted (threads dump will be taken before interruption) 
> [test=testPutAllAsyncFailover, timeout=12]
> {noformat}
> Failed builds 
> http://ci.ignite.apache.org/viewLog.html?buildId=675158=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2
> http://ci.ignite.apache.org/viewLog.html?buildId=674915=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2
> http://ci.ignite.apache.org/viewLog.html?buildId=674698=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2



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

[jira] [Updated] (IGNITE-5769) Abstract away .NET->Java calls

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5769:
---
Fix Version/s: 2.2

> Abstract away .NET->Java calls
> --
>
> Key: IGNITE-5769
> URL: https://issues.apache.org/jira/browse/IGNITE-5769
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.2
>
>
> All JNI interaction goes through static {{UnmanagedUtils}} calls. This should 
> be refactored so that unmanaged call mechanism can be replaced with something 
> else for each particular node.



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

[jira] [Created] (IGNITE-5861) Basic cache operations

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5861:
--

 Summary: Basic cache operations
 Key: IGNITE-5861
 URL: https://issues.apache.org/jira/browse/IGNITE-5861
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.2






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

[jira] [Commented] (IGNITE-5769) Abstract away .NET->Java calls

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5769:


Github user asfgit closed the pull request at:

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


> Abstract away .NET->Java calls
> --
>
> Key: IGNITE-5769
> URL: https://issues.apache.org/jira/browse/IGNITE-5769
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.2
>
>
> All JNI interaction goes through static {{UnmanagedUtils}} calls. This should 
> be refactored so that unmanaged call mechanism can be replaced with something 
> else for each particular node.



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

[jira] [Resolved] (IGNITE-5769) Abstract away .NET->Java calls

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-5769.

Resolution: Fixed

> Abstract away .NET->Java calls
> --
>
> Key: IGNITE-5769
> URL: https://issues.apache.org/jira/browse/IGNITE-5769
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> All JNI interaction goes through static {{UnmanagedUtils}} calls. This should 
> be refactored so that unmanaged call mechanism can be replaced with something 
> else for each particular node.



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

[jira] [Commented] (IGNITE-5769) Abstract away .NET->Java calls

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5769:


TC is green. Performance checked by running built-in put/get benchmarks: no 
changes.

Merged to master: {{89bba2fa2c423d5713c8412ba0069b869005694c}}

> Abstract away .NET->Java calls
> --
>
> Key: IGNITE-5769
> URL: https://issues.apache.org/jira/browse/IGNITE-5769
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> All JNI interaction goes through static {{UnmanagedUtils}} calls. This should 
> be refactored so that unmanaged call mechanism can be replaced with something 
> else for each particular node.



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