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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-5655:
-
Description: 
Currently binary marshaller encodes strings in UTF-8. However, sometimes it 
makes sense to serialize strings with different encodings to save space. Let's 
add global property to control String encoding and customize our binary 
protocol to support it. For instance, we can add another flag 
{{ENCODED_STRING}}, which will write strings as follows:
[flag][encoding_flag][str_len][str_bytes]

First implementation should set preferred encoding for strings in 
BinaryConfiguration. This setting is optional, default encoding is UTF-8. 
Currently, the same BinaryConfiguration is used for all cluster nodes, thus no 
encoding clashes are possible.

  was:
Currently binary marshaller encodes strings in UTF-8. However, sometimes it 
makes sense to serialize strings with different encodings to save space. Let's 
add global property to control String encoding and customize our binary 
protocol to support it. For instance, we can add another flag 
{{ENCODED_STRING}}, which will write strings as follows:
[flag][encoding_flag][str_len][str_bytes]


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



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

[jira] [Created] (IGNITE-6043) Fix GridCacheSemaphoreImpl methods semantics

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-6043:


 Summary: Fix GridCacheSemaphoreImpl methods semantics
 Key: IGNITE-6043
 URL: https://issues.apache.org/jira/browse/IGNITE-6043
 Project: Ignite
  Issue Type: Bug
  Components: data structures
Affects Versions: 2.1
Reporter: Andrey Kuznetsov
Priority: Critical


Current semaphore implementation, {{GridCacheSemaphoreImpl}}, has inverted 
method semantics: {{acquire()}} releases the permit and {{release()}} acquires 
it. Also, debug-level method {{availablePermits()}} returns permits acquired so 
far. This confusing behaviour should be fixed.

Also, it's worth noting in IgniteSemaphore's javadoc it's unbounded nature, as 
opposed to {{java.util.concurrent.Semaphore}}.



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

[jira] [Updated] (IGNITE-6043) Fix GridCacheSemaphoreImpl methods semantics

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6043:
-
Description: 
Current semaphore implementation, {{GridCacheSemaphoreImpl}}, has inverted 
method semantics: {{acquire()}} releases the permit and {{release()}} acquires 
it. Also, debug-level method {{availablePermits()}} returns permits acquired so 
far. This confusing behaviour should be fixed.

Also, it's worth noting in IgniteSemaphore's javadoc its unbounded nature, as 
opposed to {{java.util.concurrent.Semaphore}}.

  was:
Current semaphore implementation, {{GridCacheSemaphoreImpl}}, has inverted 
method semantics: {{acquire()}} releases the permit and {{release()}} acquires 
it. Also, debug-level method {{availablePermits()}} returns permits acquired so 
far. This confusing behaviour should be fixed.

Also, it's worth noting in IgniteSemaphore's javadoc it's unbounded nature, as 
opposed to {{java.util.concurrent.Semaphore}}.


> Fix GridCacheSemaphoreImpl methods semantics
> 
>
> Key: IGNITE-6043
> URL: https://issues.apache.org/jira/browse/IGNITE-6043
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Priority: Critical
>
> Current semaphore implementation, {{GridCacheSemaphoreImpl}}, has inverted 
> method semantics: {{acquire()}} releases the permit and {{release()}} 
> acquires it. Also, debug-level method {{availablePermits()}} returns permits 
> acquired so far. This confusing behaviour should be fixed.
> Also, it's worth noting in IgniteSemaphore's javadoc its unbounded nature, as 
> opposed to {{java.util.concurrent.Semaphore}}.



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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6009:
--

Blocking compute jobs leaded to compute threads exhausting, and to deadlock, 
consequently. Fixed by limiting blocking ("consumer") job count by value less 
than total compute thread count.

[~DmitriyGovorukhin], please review my changes.

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




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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6009:


Assignee: Andrey Kuznetsov

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




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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-5655:


Assignee: Andrey Kuznetsov

> Introduce pluggable string encoder/decoder
> --
>
> Key: IGNITE-5655
> URL: https://issues.apache.org/jira/browse/IGNITE-5655
> Project: Ignite
>  Issue Type: New Feature
>  Components: binary
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Andrey Kuznetsov
>
> Currently binary marshaller encodes strings in UTF-8. However, sometimes it 
> makes sense to serialize strings with different encodings to save space. 
> Let's add global property to control String encoding and customize our binary 
> protocol to support it. For instance, we can add another flag 
> {{ENCODED_STRING}}, which will write strings as follows:
> [flag][encoding_flag][str_len][str_bytes]



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

[jira] [Commented] (IGNITE-4181) The several runs of ServicesExample causes NPE

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-4181:
--

[~avinogradov], Please review our changes. Public API reproducer was added 
recently.

> The several runs of ServicesExample causes NPE
> --
>
> Key: IGNITE-4181
> URL: https://issues.apache.org/jira/browse/IGNITE-4181
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6, 1.7, 2.0
> Environment: Windows 10, Oracle JDK 7
>Reporter: Sergey Kozlov
>Assignee: Dmitriy Sorokin
>  Labels: newbie
> Fix For: 2.2
>
>
> 0. Open example project in IDEA
> 1. Start 2-3 {{ExampleNodeStartup}}
> 2. Run {{ServicesExample}} several times.
> Sometimes it causes NullPointerException:
> {noformat}
> Executing closure [mapSize=10]
> Service was cancelled: myNodeSingletonService
> [15:37:20,020][INFO ][srvc-deploy-#24%null%][GridServiceProcessor] Cancelled 
> service instance [name=myNodeSingletonService, 
> execId=88a92a4d-c1cb-4a9b-8930-c67ac7f42bf3]
> [15:37:20,032][INFO ][sys-#33%null%][GridCacheProcessor] Stopped cache: 
> myNodeSingletonService
> [15:37:20,033][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=4], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,045][INFO ][sys-#39%null%][GridCacheProcessor] Stopped cache: 
> myClusterSingletonService
> [15:37:20,046][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=5], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,062][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Node left topology: TcpDiscoveryNode 
> [id=4f9cbc67-d756-4c25-9ee4-aee6528da024, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.107, 2001:0:9d38:6ab8:34b2:9f3e:3c6f:269], 
> sockAddrs=[/2001:0:9d38:6ab8:34b2:9f3e:3c6f:269:0, /127.0.0.1:0, 
> /0:0:0:0:0:0:0:1:0, work-pc/172.25.4.107:0], discPort=0, order=10, 
> intOrder=7, lastExchangeTime=1478522239236, loc=false, 
> ver=1.7.3#20161107-sha1:5132ac87, isClient=true]
> [15:37:20,063][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Topology snapshot [ver=11, servers=3, clients=0, CPUs=8, heap=11.0GB]
> [15:37:20,064][INFO ][sys-#44%null%][GridCacheProcessor] Stopped cache: 
> myMultiService
> [15:37:20,066][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=6], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,076][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myClusterSingletonService, mode=PARTITIONED]
> [15:37:20,115][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=7], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,121][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], evt=NODE_LEFT, node=4f9cbc67-d756-4c25-9ee4-aee6528da024]
> [15:37:20,133][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myMultiService, mode=PARTITIONED]
> [15:37:20,135][ERROR][exchange-worker-#23%null%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=11, 
> minorTopVer=1], nodeId=5faac72a, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initStartedCacheOnCoordinator(CacheAffinitySharedManager.java:743)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:413)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:565)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:448)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1447)
>   at 
> 

[jira] [Assigned] (IGNITE-4181) The several runs of ServicesExample causes NPE

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-4181:


Assignee: Andrey Kuznetsov

> The several runs of ServicesExample causes NPE
> --
>
> Key: IGNITE-4181
> URL: https://issues.apache.org/jira/browse/IGNITE-4181
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6, 1.7
> Environment: Windows 10, Oracle JDK 7
>Reporter: Sergey Kozlov
>Assignee: Andrey Kuznetsov
>  Labels: newbie
> Fix For: 2.2
>
>
> 0. Open example project in IDEA
> 1. Start 2-3 {{ExampleNodeStartup}}
> 2. Run {{ServicesExample}} several times.
> Sometimes it causes NullPointerException:
> {noformat}
> Executing closure [mapSize=10]
> Service was cancelled: myNodeSingletonService
> [15:37:20,020][INFO ][srvc-deploy-#24%null%][GridServiceProcessor] Cancelled 
> service instance [name=myNodeSingletonService, 
> execId=88a92a4d-c1cb-4a9b-8930-c67ac7f42bf3]
> [15:37:20,032][INFO ][sys-#33%null%][GridCacheProcessor] Stopped cache: 
> myNodeSingletonService
> [15:37:20,033][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=4], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,045][INFO ][sys-#39%null%][GridCacheProcessor] Stopped cache: 
> myClusterSingletonService
> [15:37:20,046][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=5], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,062][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Node left topology: TcpDiscoveryNode 
> [id=4f9cbc67-d756-4c25-9ee4-aee6528da024, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.107, 2001:0:9d38:6ab8:34b2:9f3e:3c6f:269], 
> sockAddrs=[/2001:0:9d38:6ab8:34b2:9f3e:3c6f:269:0, /127.0.0.1:0, 
> /0:0:0:0:0:0:0:1:0, work-pc/172.25.4.107:0], discPort=0, order=10, 
> intOrder=7, lastExchangeTime=1478522239236, loc=false, 
> ver=1.7.3#20161107-sha1:5132ac87, isClient=true]
> [15:37:20,063][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Topology snapshot [ver=11, servers=3, clients=0, CPUs=8, heap=11.0GB]
> [15:37:20,064][INFO ][sys-#44%null%][GridCacheProcessor] Stopped cache: 
> myMultiService
> [15:37:20,066][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=6], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,076][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myClusterSingletonService, mode=PARTITIONED]
> [15:37:20,115][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=7], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,121][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], evt=NODE_LEFT, node=4f9cbc67-d756-4c25-9ee4-aee6528da024]
> [15:37:20,133][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myMultiService, mode=PARTITIONED]
> [15:37:20,135][ERROR][exchange-worker-#23%null%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=11, 
> minorTopVer=1], nodeId=5faac72a, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initStartedCacheOnCoordinator(CacheAffinitySharedManager.java:743)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:413)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:565)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:448)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1447)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> 

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-5655:
--

[~devozerov], please review my changes.

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



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

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

[Andrey Kuznetsov (JIRA)]

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

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

[~vozerov], please review my changes.


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

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



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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6015:


Assignee: Andrey Kuznetsov

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



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

[jira] [Commented] (IGNITE-6137) Inaccurate CAS handling in GridNearTxLocal async commit

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6137:
--

[~DmitriyGovorukhin], TC link has been added.

> Inaccurate CAS handling in GridNearTxLocal async commit
> ---
>
> Key: IGNITE-6137
> URL: https://issues.apache.org/jira/browse/IGNITE-6137
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
> Fix For: 2.3
>
>
> CAS for commitFuture is handled inaccurate in commitNearTxLocalAsync method. 
> Can fail on muliple calls, either concurrent or sequential.



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

[jira] [Assigned] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-5553:


Assignee: Andrey Kuznetsov

> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Andrey Kuznetsov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



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

[jira] [Assigned] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6186:


Assignee: Andrey Kuznetsov

> Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
> ---
>
> Key: IGNITE-6186
> URL: https://issues.apache.org/jira/browse/IGNITE-6186
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
>
> The method is not thread-safe unless actual parameter is currentThread.



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

[jira] [Commented] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6186:
--

[~sboikov], please review my changes.

> Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
> ---
>
> Key: IGNITE-6186
> URL: https://issues.apache.org/jira/browse/IGNITE-6186
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
>
> The method is not thread-safe unless actual parameter is currentThread.



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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6015:
--

[~sboikov], please review my fix.

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



--
This message was sent by Atlassian 

[jira] [Assigned] (IGNITE-6043) Fix GridCacheSemaphoreImpl methods semantics

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6043:


Assignee: Andrey Kuznetsov

> Fix GridCacheSemaphoreImpl methods semantics
> 
>
> Key: IGNITE-6043
> URL: https://issues.apache.org/jira/browse/IGNITE-6043
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Critical
>
> Current semaphore implementation, {{GridCacheSemaphoreImpl}}, has inverted 
> method semantics: {{acquire()}} releases the permit and {{release()}} 
> acquires it. Also, debug-level method {{availablePermits()}} returns permits 
> acquired so far. This confusing behaviour should be fixed.
> Also, it's worth noting in IgniteSemaphore's javadoc its unbounded nature, as 
> opposed to {{java.util.concurrent.Semaphore}}.



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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6015:
--

[~sboikov], I attached it to this issue earlier 
https://ci.ignite.apache.org/viewQueued.html?itemId=853896. Something wrong 
with the link?

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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6015:
--

[~sboikov], I've checked TC build results. I haven't add new test failures with 
this change. 

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

[jira] [Commented] (IGNITE-6520) IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6520:
--

[~sboikov], thanks for your review.

Initially, flaky timeouts were caused by IllegalStateException in 
GridAffinityAssignmentCache::cachedAffinity which propagated up to 
GridPartitionedSingleGetFuture::mapKeyToNode and prevented the future from 
completion. First, I caught this possible exception, and test became to fail 
instead of hanging. Then I fixed the reason of IllegalStateException itself.

> IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)
> 
>
> Key: IGNITE-6520
> URL: https://issues.apache.org/jira/browse/IGNITE-6520
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
>




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

[jira] [Commented] (IGNITE-6520) IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6520:
--

[~sboikov], could you please tell why frozen-forever future is better than 
failed one (in case of RuntimeException)?

> IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)
> 
>
> Key: IGNITE-6520
> URL: https://issues.apache.org/jira/browse/IGNITE-6520
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>




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

[jira] [Commented] (IGNITE-6520) IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6520:
--

[~dpavlov], we have another issue related to this test method -- IGNITE-6006. I 
coudn't reproduce failure described there, so I need some extra time to 
investigate it.

> IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)
> 
>
> Key: IGNITE-6520
> URL: https://issues.apache.org/jira/browse/IGNITE-6520
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>




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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6006:


Assignee: Andrey Kuznetsov

> IgniteCacheGetRestartTest fails sometimes on TC
> ---
>
> Key: IGNITE-6006
> URL: https://issues.apache.org/jira/browse/IGNITE-6006
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Andrey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
>
> {noformat}
> junit.framework.AssertionFailedError: expected:<33244> but was:
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:86)
> at junit.framework.TestCase.assertEquals(TestCase.java:253)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCacheGetRestartTest.checkGet(IgniteCacheGetRestartTest.java:265)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCacheGetRestartTest.access$200(IgniteCacheGetRestartTest.java:52)
> {noformat}



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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov edited comment on IGNITE-6015 at 9/29/17 4:49 PM:
---

[~sboikov], I've updated build link. Now we have 2 other hanging suites 
(instead of that 5).


was (Author: andrey-kuznetsov):
[~sboikov], I've update build link. Now we have 2 other hanging suites (instead 
of that 5).

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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6015:
--

[~sboikov], I've update build link. Now we have 2 other hanging suites (instead 
of that 5).

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

[jira] [Commented] (IGNITE-6520) IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6520:
--

[~sboikov], please take a look at PR. It fixes this very issue, and if my logic 
is OK, then we are to revise other AffinityReadyFuture usages.

> IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)
> 
>
> Key: IGNITE-6520
> URL: https://issues.apache.org/jira/browse/IGNITE-6520
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
>




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

[jira] [Commented] (IGNITE-6520) IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6520:
--

[~dpavlov], I've marked this test as fixed on TC, but it's still visible in 
'muted problems' tab for some reason. Please check its state.

> IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)
> 
>
> Key: IGNITE-6520
> URL: https://issues.apache.org/jira/browse/IGNITE-6520
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>




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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov resolved IGNITE-6006.
--
Resolution: Cannot Reproduce

Could not reproduce, neither for 2.1, nor for current master. 

> IgniteCacheGetRestartTest fails sometimes on TC
> ---
>
> Key: IGNITE-6006
> URL: https://issues.apache.org/jira/browse/IGNITE-6006
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Andrey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
>
> {noformat}
> junit.framework.AssertionFailedError: expected:<33244> but was:
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:86)
> at junit.framework.TestCase.assertEquals(TestCase.java:253)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCacheGetRestartTest.checkGet(IgniteCacheGetRestartTest.java:265)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCacheGetRestartTest.access$200(IgniteCacheGetRestartTest.java:52)
> {noformat}



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

[jira] [Commented] (IGNITE-6520) IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6520:
--

Thanks, [~dpavlov]. Probably I have less permissions than you and I can't 
mute/unmute explicitly.

> IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)
> 
>
> Key: IGNITE-6520
> URL: https://issues.apache.org/jira/browse/IGNITE-6520
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
> Attachments: unmute.jpg.png
>
>




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

[jira] [Commented] (IGNITE-5998) Assertion during partition creation in tests

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-5998:
--

[~avinogradov], couldn't make it fail on 2.1 as well.

> Assertion during partition creation in tests
> 
>
> Key: IGNITE-5998
> URL: https://issues.apache.org/jira/browse/IGNITE-5998
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> It was cause of hang of 
> DynamicIndexReplicatedAtomicConcurrentSelfTest.testQueryConsistencyMultithreaded
> {code}
> [2017-08-08 
> 19:02:01,877][ERROR][exchange-worker-#4300529%index.DynamicIndexReplicatedAtomicConcurrentSelfTest1%][CacheAffinitySharedManager]
>  Failed to initialize cache. Will try to rollback cache start routine. 
> [cacheName=cache]
> class org.apache.ignite.IgniteCheckedException: Failed to register MBean for 
> component: 
> org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl@4d0397a2
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:3624)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1637)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1863)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:742)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:739)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:468)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1954)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.management.InstanceAlreadyExistsException: 
> org.apache:clsLdr=6d06d69c,igniteInstanceName=index.DynamicIndexReplicatedAtomicConcurrentSelfTest1,group=cache,name=org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.registerCacheMBean(IgniteUtils.java:4574)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:3620)
>   ... 8 more
> [2017-08-08 
> 19:02:01,878][ERROR][exchange-worker-#4300529%index.DynamicIndexReplicatedAtomicConcurrentSelfTest1%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=DynamicCacheChangeBatch 
> [id=2490c129e51-bbb352cc-e911-41e1-afd6-67e8ed91809c, 
> reqs=[DynamicCacheChangeRequest [cacheName=cache, hasCfg=true, 
> nodeId=fdc8ffc4-3da3-470e-a8ac-5f8b4204, clientStartOnly=false, 
> stop=false, destroy=false]], exchangeActions=ExchangeActions 
> [startCaches=[cache], stopCaches=null, startGrps=[cache], stopGrps=[], 
> resetParts=null, stateChangeRequest=null], startCaches=false], 
> affTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=fdc8ffc4-3da3-470e-a8ac-5f8b4204, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:0], discPort=0, order=4, intOrder=4, 
> lastExchangeTime=1502208121825, loc=false, ver=2.2.0#19700101-sha1:, 
> isClient=true], topVer=4, nodeId8=0e697ca6, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1502208121873]], nodeId=fdc8ffc4, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:344)
>   at 
> 

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6015:
--

I have some data related to bug reason.

Sometimes during this test transactions may fail with 'Missing commit version' 
error. In most cases it does not prevent the test from successful completion, 
since transaction is being rolling back  after error occurs. This happens under 
the following call stack:

class org.apache.ignite.IgniteCheckedException: Missing commit version 
(consider increasing IGNITE_MAX_COMPLETED_TX_COUNT system property) 
[ver=GridCacheVersion [topVer=117822884, order=1506342887333, nodeOrder=4], 
committed0=false, tx=GridNearTxRemote]
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.commitTx(IgniteTxManager.java:1196)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:769)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:799)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1317)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1232)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
at java.lang.Thread.run(Thread.java:748)

But sometimes (less frequently) we have another call stack: 

class org.apache.ignite.IgniteCheckedException: Missing commit version 
(consider increasing IGNITE_MAX_COMPLETED_TX_COUNT system property) 
[ver=GridCacheVersion [topVer=117822884, order=1506342887353, nodeOrder=4], 
committed0=false, tx=GridNearTxRemote]
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.commitTx(IgniteTxManager.java:1196)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:769)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.onOwnerChanged(GridDistributedTxRemoteAdapter.java:329)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.onOwnerChanged(IgniteTxManager.java:1490)
at 
org.apache.ignite.internal.processors.cache.GridCacheMvccManager.notifyOwnerChanged(GridCacheMvccManager.java:238)
at 
org.apache.ignite.internal.processors.cache.GridCacheMvccManager.access$200(GridCacheMvccManager.java:80)
at 
org.apache.ignite.internal.processors.cache.GridCacheMvccManager$3.onOwnerChanged(GridCacheMvccManager.java:163)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkOwnerChanged(GridCacheMapEntry.java:3681)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.removeLock(GridDistributedCacheEntry.java:400)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.txUnlock(GridDistributedCacheEntry.java:665)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.unlockMultiple(IgniteTxManager.java:1662)
at 

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov edited comment on IGNITE-6015 at 9/26/17 9:00 AM:
---

I have some data related to bug reason.

Sometimes during this test transactions may fail with 'Missing commit version' 
error. In most cases it does not prevent the test from successful completion, 
since transaction is being rolled back  after error occurs. This happens under 
the following call stack:

class org.apache.ignite.IgniteCheckedException: Missing commit version 
(consider increasing IGNITE_MAX_COMPLETED_TX_COUNT system property) 
[ver=GridCacheVersion [topVer=117822884, order=1506342887333, nodeOrder=4], 
committed0=false, tx=GridNearTxRemote]
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.commitTx(IgniteTxManager.java:1196)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:769)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:799)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1317)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1232)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
at java.lang.Thread.run(Thread.java:748)

But sometimes (less frequently) we have another call stack: 

class org.apache.ignite.IgniteCheckedException: Missing commit version 
(consider increasing IGNITE_MAX_COMPLETED_TX_COUNT system property) 
[ver=GridCacheVersion [topVer=117822884, order=1506342887353, nodeOrder=4], 
committed0=false, tx=GridNearTxRemote]
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.commitTx(IgniteTxManager.java:1196)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:769)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.onOwnerChanged(GridDistributedTxRemoteAdapter.java:329)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.onOwnerChanged(IgniteTxManager.java:1490)
at 
org.apache.ignite.internal.processors.cache.GridCacheMvccManager.notifyOwnerChanged(GridCacheMvccManager.java:238)
at 
org.apache.ignite.internal.processors.cache.GridCacheMvccManager.access$200(GridCacheMvccManager.java:80)
at 
org.apache.ignite.internal.processors.cache.GridCacheMvccManager$3.onOwnerChanged(GridCacheMvccManager.java:163)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkOwnerChanged(GridCacheMapEntry.java:3681)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.removeLock(GridDistributedCacheEntry.java:400)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.txUnlock(GridDistributedCacheEntry.java:665)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.unlockMultiple(IgniteTxManager.java:1662)
at 

[jira] [Created] (IGNITE-6520) IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-6520:


 Summary: IgniteCacheGetRestartTest.testGetRestartReplicated fails 
sometimes (timeout)
 Key: IGNITE-6520
 URL: https://issues.apache.org/jira/browse/IGNITE-6520
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov






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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-5655:
--

[~vozerov], thanks for your comments.

As for ignoring encoding byte in binary fields comparison (#7), it works 
without changes right now, since we have only one non-UTF-8 encoding. But it's 
fragile, and I'll fix it, of course.

As for #7.2, we don't need to deserialize fields when encodings match, since we 
just test for equality (as opposed to {{c1.compareTo(c2)}}).

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



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

[jira] [Commented] (IGNITE-6137) Inaccurate CAS handling in GridNearTxLocal async commit

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6137:
--

[~DmitriyGovorukhin], please review my changes.

> Inaccurate CAS handling in GridNearTxLocal async commit
> ---
>
> Key: IGNITE-6137
> URL: https://issues.apache.org/jira/browse/IGNITE-6137
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
> Fix For: 2.2
>
>
> CAS for commitFuture is handled inaccurate in commitNearTxLocalAsync method. 
> Can fail on muliple calls, either concurrent or sequential.



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

[jira] [Created] (IGNITE-6137) Inaccurate CAS handling in GridNearTxLocal async commit

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-6137:


 Summary: Inaccurate CAS handling in GridNearTxLocal async commit
 Key: IGNITE-6137
 URL: https://issues.apache.org/jira/browse/IGNITE-6137
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.1
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
 Fix For: 2.2


CAS for commitFuture is handled inaccurate in commitNearTxLocalAsync method. 
Can fail on muliple calls, either concurrent or sequential.



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

[jira] [Created] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-6186:


 Summary: Remove redundant parameter of 
GridFutureAdapter::unregisterWaiter()
 Key: IGNITE-6186
 URL: https://issues.apache.org/jira/browse/IGNITE-6186
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.1
Reporter: Andrey Kuznetsov
Priority: Minor
 Fix For: 2.2


The method is not thread-safe unless actual parameter is currentThread.



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

[jira] [Resolved] (IGNITE-6043) Fix GridCacheSemaphoreImpl methods semantics

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov resolved IGNITE-6043.
--
Resolution: Not A Problem

> Fix GridCacheSemaphoreImpl methods semantics
> 
>
> Key: IGNITE-6043
> URL: https://issues.apache.org/jira/browse/IGNITE-6043
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Critical
>
> Current semaphore implementation, {{GridCacheSemaphoreImpl}}, has inverted 
> method semantics: {{acquire()}} releases the permit and {{release()}} 
> acquires it. Also, debug-level method {{availablePermits()}} returns permits 
> acquired so far. This confusing behaviour should be fixed.
> Also, it's worth noting in IgniteSemaphore's javadoc its unbounded nature, as 
> opposed to {{java.util.concurrent.Semaphore}}.



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

[jira] [Commented] (IGNITE-6043) Fix GridCacheSemaphoreImpl methods semantics

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6043:
--

I've misunderstood the implementation. That is, GridCacheSemaphoreImpl is 
bounded and works similar to java.util.concurrent.Semaphore.

> Fix GridCacheSemaphoreImpl methods semantics
> 
>
> Key: IGNITE-6043
> URL: https://issues.apache.org/jira/browse/IGNITE-6043
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Critical
>
> Current semaphore implementation, {{GridCacheSemaphoreImpl}}, has inverted 
> method semantics: {{acquire()}} releases the permit and {{release()}} 
> acquires it. Also, debug-level method {{availablePermits()}} returns permits 
> acquired so far. This confusing behaviour should be fixed.
> Also, it's worth noting in IgniteSemaphore's javadoc its unbounded nature, as 
> opposed to {{java.util.concurrent.Semaphore}}.



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

[jira] [Commented] (IGNITE-2399) Add asynchronous acquire to IgniteSemaphore

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-2399:
--

Why should this high-level functionality pollute Semaphore API? Resource 
acquisition control is not an only semaphore use case. To my mind, it's better 
to put this method to some utility class like IgniteUtils.

> Add asynchronous acquire to IgniteSemaphore
> ---
>
> Key: IGNITE-2399
> URL: https://issues.apache.org/jira/browse/IGNITE-2399
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Reporter: Vladisav Jelisavcic
>
> Usually a permit acquisition is followed by an action, followed by a release 
> of the permit. A simple enhancement to the existing Semaphore API can be made 
> that enables asynchronous acquire:
>  IgniteFuture acquireAndExecute(Callable action, int numPermits);
> The method would immediately return a future to be later completed by the 
> action's result. Permits are to be released after the future is completed.



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

[jira] [Updated] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6186:
-
Description: 
The method is not thread-safe unless actual parameter is currentThread.

Let future state is a list of listeners and two concurrent threads are removing 
two adjacent non-root listener nodes from list simultaneously by calling 
{{unregisterWaiter()}}. Then data race is possible: one of these listeners can 
survive its removal. If the listener is a thread waiting for completion in 
{{get0()}} then this race leads at worst case to 1 extra call to 
{{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
arbitrary listener, and its {{apply()}} will be called twice.

  was:The method is not thread-safe unless actual parameter is currentThread.


> Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
> ---
>
> Key: IGNITE-6186
> URL: https://issues.apache.org/jira/browse/IGNITE-6186
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
>
> The method is not thread-safe unless actual parameter is currentThread.
> Let future state is a list of listeners and two concurrent threads are 
> removing two adjacent non-root listener nodes from list simultaneously by 
> calling {{unregisterWaiter()}}. Then data race is possible: one of these 
> listeners can survive its removal. If the listener is a thread waiting for 
> completion in {{get0()}} then this race leads at worst case to 1 extra call 
> to {{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
> arbitrary listener, and its {{apply()}} will be called twice.



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

[jira] [Updated] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6186:
-
Description: 
The method is not thread-safe unless actual parameter is currentThread.

Let future state is a list of listeners and two concurrent threads are removing 
two adjacent non-root listener nodes from list simultaneously by calling 
{{unregisterWaiter()}}. Then data race is possible: one of these listeners can 
survive its removal. If the listener is a thread waiting for completion in 
{{get0()}} then this race leads at worst case to 1 extra call to 
{{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
arbitrary listener, and its {{apply()}} will be called twice.

To be precise, this Jira issue does not relate to any existing bug, but it 
eliminates fragile construct that can explode on future chages/refactorings.

  was:
The method is not thread-safe unless actual parameter is currentThread.

Let future state is a list of listeners and two concurrent threads are removing 
two adjacent non-root listener nodes from list simultaneously by calling 
{{unregisterWaiter()}}. Then data race is possible: one of these listeners can 
survive its removal. If the listener is a thread waiting for completion in 
{{get0()}} then this race leads at worst case to 1 extra call to 
{{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
arbitrary listener, and its {{apply()}} will be called twice.


> Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
> ---
>
> Key: IGNITE-6186
> URL: https://issues.apache.org/jira/browse/IGNITE-6186
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
>
> The method is not thread-safe unless actual parameter is currentThread.
> Let future state is a list of listeners and two concurrent threads are 
> removing two adjacent non-root listener nodes from list simultaneously by 
> calling {{unregisterWaiter()}}. Then data race is possible: one of these 
> listeners can survive its removal. If the listener is a thread waiting for 
> completion in {{get0()}} then this race leads at worst case to 1 extra call 
> to {{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
> arbitrary listener, and its {{apply()}} will be called twice.
> To be precise, this Jira issue does not relate to any existing bug, but it 
> eliminates fragile construct that can explode on future chages/refactorings.



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

[jira] [Assigned] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6711:


Assignee: Andrey Kuznetsov

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Commented] (IGNITE-6740) Java 9: rework DirectBuffer.address() usages

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6740:
--

[~avinogradov], could you please review my changes?

> Java 9: rework DirectBuffer.address() usages
> 
>
> Key: IGNITE-6740
> URL: https://issues.apache.org/jira/browse/IGNITE-6740
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> We have two usages of {{DirectBuffer.address()}} method which is no longer 
> accessible in Java 9: 
> 1) {{DirectByteBufferStreamImplV1}}
> 2) {{DirectByteBufferStreamImplV2}}
> Need to rework this code using reflection and/or {{Unsafe}}, so that it 
> compiles and work on all Java versions.



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

[jira] [Commented] (IGNITE-6740) Java 9: rework DirectBuffer.address() usages

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6740:
--

[~avinogradov], I beg for your review.

> Java 9: rework DirectBuffer.address() usages
> 
>
> Key: IGNITE-6740
> URL: https://issues.apache.org/jira/browse/IGNITE-6740
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> We have two usages of {{DirectBuffer.address()}} method which is no longer 
> accessible in Java 9: 
> 1) {{DirectByteBufferStreamImplV1}}
> 2) {{DirectByteBufferStreamImplV2}}
> Need to rework this code using reflection and/or {{Unsafe}}, so that it 
> compiles and work on all Java versions.



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

[jira] [Commented] (IGNITE-6740) Java 9: rework DirectBuffer.address() usages

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6740:
--

[~ezhuravl], I've changed the code to read buffer address field with Unsafe. 
Please take a look.

> Java 9: rework DirectBuffer.address() usages
> 
>
> Key: IGNITE-6740
> URL: https://issues.apache.org/jira/browse/IGNITE-6740
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> We have two usages of {{DirectBuffer.address()}} method which is no longer 
> accessible in Java 9: 
> 1) {{DirectByteBufferStreamImplV1}}
> 2) {{DirectByteBufferStreamImplV2}}
> Need to rework this code using reflection and/or {{Unsafe}}, so that it 
> compiles and work on all Java versions.



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

[jira] [Resolved] (IGNITE-7171) .NET: Support additional Data Region metrics

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov resolved IGNITE-7171.
--
Resolution: Invalid

This change should be done as part of [1].

[1] https://issues.apache.org/jira/browse/IGNITE-6902


> .NET: Support additional Data Region metrics
> 
>
> Key: IGNITE-7171
> URL: https://issues.apache.org/jira/browse/IGNITE-7171
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Andrey Kuznetsov
>  Labels: iep-6
> Fix For: 2.4
>
>
> Issue [1] adds some new Data Region metrics. They should be added to .NET as 
> well:
> * totalAllocatedSize
> * physicalMemorySize
> * checkpointBufferSize
> [1] https://issues.apache.org/jira/browse/IGNITE-6902



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

[jira] [Assigned] (IGNITE-6732) Java 9: Hadoop module should not start on Java 9

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6732:


Assignee: Andrey Kuznetsov

> Java 9: Hadoop module should not start on Java 9
> 
>
> Key: IGNITE-6732
> URL: https://issues.apache.org/jira/browse/IGNITE-6732
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> Hadoop module heavily relies on the fact that application class loader is 
> {{URLClassLoader}}. It is used to inspect class path and hack it in various 
> ways. But in Java 9 another class loader type is used. 
> Looks like there is no simple solution at the moment. Let's check for Java 
> version during startup and throw an exception if it Java 9 or later.



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

[jira] [Commented] (IGNITE-6740) Java 9: rework DirectBuffer.address() usages

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6740:
--

[~ezhuravl], could you please review the change?

> Java 9: rework DirectBuffer.address() usages
> 
>
> Key: IGNITE-6740
> URL: https://issues.apache.org/jira/browse/IGNITE-6740
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> We have two usages of {{DirectBuffer.address()}} method which is no longer 
> accessible in Java 9: 
> 1) {{DirectByteBufferStreamImplV1}}
> 2) {{DirectByteBufferStreamImplV2}}
> Need to rework this code using reflection and/or {{Unsafe}}, so that it 
> compiles and work on all Java versions.



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

[jira] [Commented] (IGNITE-6729) Java 9: fix IgniteUtils#close(URLClassLoader, IgniteLogger)

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6729:
--

[~ezhuravl], could you please review the change?

> Java 9: fix IgniteUtils#close(URLClassLoader, IgniteLogger)
> ---
>
> Key: IGNITE-6729
> URL: https://issues.apache.org/jira/browse/IGNITE-6729
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> This method use some internal API which is no longer accessible to cleanup 
> {{URLCLassLoader}} properly. The only usage of this method is in 
> {{GridUriDeploymentFileProcessor}} class.



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

[jira] [Commented] (IGNITE-6736) Java 9: rework GridCacheMapEntry synchronization logic to avoid Unsafe.monitor* methods

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6736:
--

Choosing ReentrantLock approach. See [1].

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Separate-code-paths-for-Java-8-and-Java-9-tp25289p25291.html

> Java 9: rework GridCacheMapEntry synchronization logic to avoid 
> Unsafe.monitor* methods
> ---
>
> Key: IGNITE-6736
> URL: https://issues.apache.org/jira/browse/IGNITE-6736
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
> Fix For: 2.4
>
>
> {{GridCacheMapEntry}} class rely on {{synchronized}} on itself heavily. In 
> {{ATOMIC}} caches we lock multiple entries at once using 
> {{Unsafe.monitorEnter/Exit}} methods. Unfortunately these methods were 
> removed in Java 9. Recursion is not an option, as it would cause stack 
> overflow for {{putAll}} operations with multiple entries.
> Possible fixes:
> 1) Rework {{synchronized}} to {{ReentrantLock}}. Easy, but may cause 
> additional memory pressure.
> 2) Have different implementations for Java 8 ({{synchronzied}}) and Java 9 
> ({{ReentrantLock}}) - much more complex solution, because we will require 
> separate module for Java 8 and Java 9.
> 3) Rework {{ATOMIC}} caches, so that {{putAll}} operation updates entries 
> one-by-one. As a side effect it will eliminate deadlocks.



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

[jira] [Assigned] (IGNITE-6736) Java 9: rework GridCacheMapEntry synchronization logic to avoid Unsafe.monitor* methods

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6736:


Assignee: Andrey Kuznetsov

> Java 9: rework GridCacheMapEntry synchronization logic to avoid 
> Unsafe.monitor* methods
> ---
>
> Key: IGNITE-6736
> URL: https://issues.apache.org/jira/browse/IGNITE-6736
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> {{GridCacheMapEntry}} class rely on {{synchronized}} on itself heavily. In 
> {{ATOMIC}} caches we lock multiple entries at once using 
> {{Unsafe.monitorEnter/Exit}} methods. Unfortunately these methods were 
> removed in Java 9. Recursion is not an option, as it would cause stack 
> overflow for {{putAll}} operations with multiple entries.
> Possible fixes:
> 1) Rework {{synchronized}} to {{ReentrantLock}}. Easy, but may cause 
> additional memory pressure.
> 2) Have different implementations for Java 8 ({{synchronzied}}) and Java 9 
> ({{ReentrantLock}}) - much more complex solution, because we will require 
> separate module for Java 8 and Java 9.
> 3) Rework {{ATOMIC}} caches, so that {{putAll}} operation updates entries 
> one-by-one. As a side effect it will eliminate deadlocks.



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

[jira] [Commented] (IGNITE-6736) Java 9: rework GridCacheMapEntry synchronization logic to avoid Unsafe.monitor* methods

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6736:
--

I've made a naïve benchmark to compare performance of {{ReentrantLock}} and 
Java monitor object synchronization in non-contended case. It was just a 
single-threaded loop incrementing long non-volatile field 10^9 times with 
various synchronizers. Results follow.

Java 8:
no sync: 1177ms
monitor/synchronized: 18804ms
monitor/unsafe: 64438ms
lock: 17103ms

Java 9:
no sync: 1183ms
monitor/synchronized: 18929ms
lock: 15193ms

I can't understand why {{ReentrantLock}} looks so good, but {{monitorEnter}} 
and {{monitorExit}} are definitely slow. Possibly, [1] describes a reason for 
this. Anyway, I'll change to locks with more confidence.

[1] 
http://jsr166-concurrency.10961.n7.nabble.com/synchronized-vs-Unsafe-monitorEnter-monitorExit-tp11764p11767.html

> Java 9: rework GridCacheMapEntry synchronization logic to avoid 
> Unsafe.monitor* methods
> ---
>
> Key: IGNITE-6736
> URL: https://issues.apache.org/jira/browse/IGNITE-6736
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> {{GridCacheMapEntry}} class rely on {{synchronized}} on itself heavily. In 
> {{ATOMIC}} caches we lock multiple entries at once using 
> {{Unsafe.monitorEnter/Exit}} methods. Unfortunately these methods were 
> removed in Java 9. Recursion is not an option, as it would cause stack 
> overflow for {{putAll}} operations with multiple entries.
> Possible fixes:
> 1) Rework {{synchronized}} to {{ReentrantLock}}. Easy, but may cause 
> additional memory pressure.
> 2) Have different implementations for Java 8 ({{synchronzied}}) and Java 9 
> ({{ReentrantLock}}) - much more complex solution, because we will require 
> separate module for Java 8 and Java 9.
> 3) Rework {{ATOMIC}} caches, so that {{putAll}} operation updates entries 
> one-by-one. As a side effect it will eliminate deadlocks.



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

[jira] [Commented] (IGNITE-6740) Java 9: rework DirectBuffer.address() usages

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6740:
--

[~ezhuravl], I think it's a good idea. And also we can get {{address}} field 
offset only once per JVM lifetime, right?

> Java 9: rework DirectBuffer.address() usages
> 
>
> Key: IGNITE-6740
> URL: https://issues.apache.org/jira/browse/IGNITE-6740
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> We have two usages of {{DirectBuffer.address()}} method which is no longer 
> accessible in Java 9: 
> 1) {{DirectByteBufferStreamImplV1}}
> 2) {{DirectByteBufferStreamImplV2}}
> Need to rework this code using reflection and/or {{Unsafe}}, so that it 
> compiles and work on all Java versions.



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

[jira] [Commented] (IGNITE-6743) Java 9: rework DirectBuffer.cleaner().clean() usage in GridNioServer

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6743:
--

[~ezhuravl], thanks for your note, I've really missed something. I think, we 
have two options here:
1. Create utility class right now.
2. For this very ticket, initialize reference to cleaning method in 
version-specific way at static initialization phase.
First one looks better but I still don't know how should that class look like.

> Java 9: rework DirectBuffer.cleaner().clean() usage in GridNioServer
> 
>
> Key: IGNITE-6743
> URL: https://issues.apache.org/jira/browse/IGNITE-6743
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> When session is closed we clean allocated {{DirectByteBuffer}}-s using 
> {{sun.misc.Cleaner}}. Need to rework this piece to reflection-based approach 
> which will work for supported Java versions.



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

[jira] [Created] (IGNITE-6940) Provide metric to monitor Thread Starvation

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-6940:


 Summary: Provide metric to monitor Thread Starvation
 Key: IGNITE-6940
 URL: https://issues.apache.org/jira/browse/IGNITE-6940
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Reporter: Andrey Kuznetsov


There is an existing code in {{IgniteKernal.start()}} that logs warnings when 
detects starvation. It should be improved to support more thread pools and 
update some metrics.



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

[jira] [Assigned] (IGNITE-6940) Provide metric to monitor Thread Starvation

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6940:


Assignee: Andrey Kuznetsov

> Provide metric to monitor Thread Starvation
> ---
>
> Key: IGNITE-6940
> URL: https://issues.apache.org/jira/browse/IGNITE-6940
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>  Labels: iep-7
>
> There is an existing code in {{IgniteKernal.start()}} that logs warnings when 
> detects starvation. It should be improved to support more thread pools and 
> update some metrics.



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

[jira] [Assigned] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6902:


Assignee: Andrey Kuznetsov

> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Bytes used per cache.
> - Size of checkpointing buffer.



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

[jira] [Created] (IGNITE-6963) TotalAllocatedPages metric does not match PhysicalMemoryPages when persistence is disabled

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-6963:


 Summary: TotalAllocatedPages metric does not match 
PhysicalMemoryPages when persistence is disabled
 Key: IGNITE-6963
 URL: https://issues.apache.org/jira/browse/IGNITE-6963
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.3
Reporter: Andrey Kuznetsov


As javadoc states for DataRegionMetrics#getPhysicalMemoryPages()

{noformat}
When persistence is disabled, this metric is equal to getTotalAllocatedPages()
{noformat}

and this seems to be sane requirement.



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

[jira] [Commented] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6711:
--

Even when I start with persistence enabled on empty db I still see strange 
values, e.g.

{noformat}
PhysycalMemoryPages = 4610
TotalAllocatedPages = 4063
{noformat}



> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Assigned] (IGNITE-6963) TotalAllocatedPages metric does not match PhysicalMemoryPages when persistence is disabled

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6963:


Assignee: Andrey Kuznetsov

> TotalAllocatedPages metric does not match PhysicalMemoryPages when 
> persistence is disabled
> --
>
> Key: IGNITE-6963
> URL: https://issues.apache.org/jira/browse/IGNITE-6963
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>
> As javadoc states for DataRegionMetrics#getPhysicalMemoryPages()
> {noformat}
> When persistence is disabled, this metric is equal to getTotalAllocatedPages()
> {noformat}
> and this seems to be sane requirement.



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

[jira] [Commented] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6711:
--

Derived metric will be incorrect as well

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Issue Comment Deleted] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6711:
-
Comment: was deleted

(was: Derived metric will be incorrect as well)

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Assigned] (IGNITE-6893) Provide metric to monitor Java Deadlocks

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6893:


Assignee: Andrey Kuznetsov

> Provide metric to monitor Java Deadlocks 
> -
>
> Key: IGNITE-6893
> URL: https://issues.apache.org/jira/browse/IGNITE-6893
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>  Labels: iep-7
>




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

[jira] [Issue Comment Deleted] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6902:
-
Comment: was deleted

(was: [~avinogradov], then my changes are ready for review, see issue links.)

> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Size of checkpointing buffer.



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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-5655:
--

I'd like to conduct more subtle investigation on impact of this change on some 
big enough data. Until this is done I won't suggest to merge such a significant 
change to master.

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



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

[jira] [Commented] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6902:
--

[~avinogradov], then my changes are ready for review, see issue links.

> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Size of checkpointing buffer.



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

[jira] [Comment Edited] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov edited comment on IGNITE-6711 at 12/8/17 10:50 AM:


Metric calculation is now fixed. There are some unfamiliar extra allocations at 
very first restart with PDS enabled, but in general the metric looks consistent.

[~avinogradov], could you please review the fix?


was (Author: andrey-kuznetsov):
[~avinogradov], could you please review the fix?

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Updated] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6902:
-
Description: 
These additional metrics and methods should be implemented:

- Bytes used per data region.
- Size of checkpointing buffer.

  was:
These additional metrics and methods should be implemented:

- Bytes used per data region.
- Bytes used per cache.
- Size of checkpointing buffer.


> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Size of checkpointing buffer.



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

[jira] [Commented] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6902:
--

"Bytes used per cache" metric looks hardly possible to implement since we can 
get data at cache group level, but not for individual cache.

Two other metrics are ready, see [1].

[1] https://github.com/apache/ignite/pull/3181

> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Bytes used per cache.
> - Size of checkpointing buffer.



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

[jira] [Assigned] (IGNITE-6728) Support Java 9

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6728:


Assignee: (was: Andrey Kuznetsov)

> Support Java 9
> --
>
> Key: IGNITE-6728
> URL: https://issues.apache.org/jira/browse/IGNITE-6728
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
> Fix For: 2.4
>
>
> Currently Ignite cannot be used with Java 9 because it relies on some JDK 
> internal API which is no longer accessible. We need to make sure that Ignite 
> can be used with Java 9. 
> This is an umbrella ticket for this activity.



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

[jira] [Assigned] (IGNITE-6729) Java 9: fix IgniteUtils#close(URLClassLoader, IgniteLogger)

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6729:


Assignee: Andrey Kuznetsov

> Java 9: fix IgniteUtils#close(URLClassLoader, IgniteLogger)
> ---
>
> Key: IGNITE-6729
> URL: https://issues.apache.org/jira/browse/IGNITE-6729
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> This method use some internal API which is no longer accessible to cleanup 
> {{URLCLassLoader}} properly. The only usage of this method is in 
> {{GridUriDeploymentFileProcessor}} class.



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

[jira] [Commented] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6711:
--

[~avinogradov], could you please review the fix?

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Commented] (IGNITE-821) [Test] IgniteCacheExpiryPolicyWithStoreAbstractTest # testReadThrough was disabled

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-821:
-

Fails again currently.

> [Test] IgniteCacheExpiryPolicyWithStoreAbstractTest # testReadThrough was 
> disabled
> --
>
> Key: IGNITE-821
> URL: https://issues.apache.org/jira/browse/IGNITE-821
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>  Labels: MakeTeamcityGreenAgain
>
> IgniteCacheExpiryPolicyWithStoreAbstractTest # testReadThrough was disabled. 
> It has to be fixed or removed.



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

[jira] [Updated] (IGNITE-821) [Test] IgniteCacheExpiryPolicyWithStoreAbstractTest # testReadThrough was disabled

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-821:

Labels: MakeTeamcityGreenAgain  (was: Muted_test)

> [Test] IgniteCacheExpiryPolicyWithStoreAbstractTest # testReadThrough was 
> disabled
> --
>
> Key: IGNITE-821
> URL: https://issues.apache.org/jira/browse/IGNITE-821
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>  Labels: MakeTeamcityGreenAgain
>
> IgniteCacheExpiryPolicyWithStoreAbstractTest # testReadThrough was disabled. 
> It has to be fixed or removed.



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

[jira] [Assigned] (IGNITE-6740) Java 9: rework DirectBuffer.address() usages

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6740:


Assignee: Andrey Kuznetsov

> Java 9: rework DirectBuffer.address() usages
> 
>
> Key: IGNITE-6740
> URL: https://issues.apache.org/jira/browse/IGNITE-6740
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> We have two usages of {{DirectBuffer.address()}} method which is no longer 
> accessible in Java 9: 
> 1) {{DirectByteBufferStreamImplV1}}
> 2) {{DirectByteBufferStreamImplV2}}
> Need to rework this code using reflection and/or {{Unsafe}}, so that it 
> compiles and work on all Java versions.



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

[jira] [Assigned] (IGNITE-6734) Java 9: do not use sun.misc.BASE64Encoder

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6734:


Assignee: Andrey Kuznetsov

> Java 9: do not use sun.misc.BASE64Encoder
> -
>
> Key: IGNITE-6734
> URL: https://issues.apache.org/jira/browse/IGNITE-6734
> Project: Ignite
>  Issue Type: Task
>  Components: general, rest
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> For some reason we use {{sun.misc.BASE64Encoder}} in several places:
> 1) {{jiraslurp.groovy}}
> 2) Several REST-related classes in {{ignite-clients}} module.
> Need to remove this usages and use {{Base64}}. Note that this class is 
> available since Java 8. Hopefully we will move to Java 8 in the same release. 
> Otherwise we will have to apply some reflection-based hacks, I think.



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

[jira] [Assigned] (IGNITE-6743) Java 9: rework DirectBuffer.cleaner().clean() usage in GridNioServer

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6743:


Assignee: Andrey Kuznetsov

> Java 9: rework DirectBuffer.cleaner().clean() usage in GridNioServer
> 
>
> Key: IGNITE-6743
> URL: https://issues.apache.org/jira/browse/IGNITE-6743
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> When session is closed we clean allocated {{DirectByteBuffer}}-s using 
> {{sun.misc.Cleaner}}. Need to rework this piece to reflection-based approach 
> which will work for supported Java versions.



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

[jira] [Assigned] (IGNITE-6731) Java 9: remove sun.misc.PerfCounter usages

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6731:


Assignee: Andrey Kuznetsov

> Java 9: remove sun.misc.PerfCounter usages
> --
>
> Key: IGNITE-6731
> URL: https://issues.apache.org/jira/browse/IGNITE-6731
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> This class is used in Hadoop module only:
> 1) {{HadoopClassLoader}}
> 2) {{HadoopTestClassLoader}}
> Need to understand whether it is safe to simply remove this calls. Most 
> probably - yes.



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

[jira] [Updated] (IGNITE-7171) .NET: Support additional Data Region metrics

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-7171:
-
Description: 
Issue [1] adds some new Data Region metrics. They should be added to .NET as 
well:
* totalAllocatedSize
* physicalMemorySize
* checkpointBufferSize

[1] https://issues.apache.org/jira/browse/IGNITE-6902

  was:
Issue [1] adds two new Data Region metrics. Both should be added to .NET as 
well.

[1] https://issues.apache.org/jira/browse/IGNITE-6902


> .NET: Support additional Data Region metrics
> 
>
> Key: IGNITE-7171
> URL: https://issues.apache.org/jira/browse/IGNITE-7171
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Andrey Kuznetsov
>  Labels: iep-6
> Fix For: 2.4
>
>
> Issue [1] adds some new Data Region metrics. They should be added to .NET as 
> well:
> * totalAllocatedSize
> * physicalMemorySize
> * checkpointBufferSize
> [1] https://issues.apache.org/jira/browse/IGNITE-6902



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

[jira] [Created] (IGNITE-7171) .NET: Support additional Data Region metrics

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-7171:


 Summary: .NET: Support additional Data Region metrics
 Key: IGNITE-7171
 URL: https://issues.apache.org/jira/browse/IGNITE-7171
 Project: Ignite
  Issue Type: New Feature
Reporter: Andrey Kuznetsov
 Fix For: 2.4


Issue [1] adds two new Data Region metrics. Both should be added to .NET as 
well.

[1] https://issues.apache.org/jira/browse/IGNITE-6902



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

[jira] [Commented] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6902:
--

[~ptupitsyn], thanks, I've created separate ticket for .NET counterpart, [1]

[1] https://issues.apache.org/jira/browse/IGNITE-7171

> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Size of checkpointing buffer.



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

[jira] [Commented] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-5553:
--

Indeed, we can put current set size into set header cache entry. This will fix 
size(), but we have broken iterator() implementation as well.

Currently, set implementation maintains plain Java sets on every node, see 
CacheDataStructuresManager.setDataMap. These sets duplicate backing-cache 
entries, both primary and backup. size() and iterator() calls issue distributed 
queries to collect/filter data from all setDataMap's. And setDataMaps remain 
empty after cluster is recovered from checkpoint.

Now I see the following options to fix the issue.

#1 - Naive. Iterate over all datastructure-backing caches entries during 
recover from checkpoint procedure, filter set-related entries and refill 
setDataMap's.
Pros: easy to implement
Cons: inpredictable time/memory overhead.

#2 - More realistic. Avoid node-local copies of cache data. Maintain linked 
list in datastructure-backing cache: key is set item, value is next set item. 
List head is stored in set header cache entry (this set item is youngest one). 
Iterators build on top of this structure are fail-fast.
Pros: less memory overhead, no need to maintain node-local mirrors of cache data
Cons: iterators are not fail-safe.

#3 - Option #2 modified. We can store reference counter and 'removed' flag 
along with next item reference. This allows to make iterators fail safe.
Pros: iterators are fail-safe
Cons: slightly more complicated implementation, may affect performance, also I 
see no way to handle active iterators on remote nodes failures.

[~sergey-chugunov], any thoughts? Or maybe we should discuss this on devlist?

> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Andrey Kuznetsov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



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

[jira] [Commented] (IGNITE-6734) Java 9: do not use sun.misc.BASE64Encoder

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6734:
--

This change is ready, just waits for changing to Java 8 project-wide.

> Java 9: do not use sun.misc.BASE64Encoder
> -
>
> Key: IGNITE-6734
> URL: https://issues.apache.org/jira/browse/IGNITE-6734
> Project: Ignite
>  Issue Type: Task
>  Components: general, rest
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> For some reason we use {{sun.misc.BASE64Encoder}} in several places:
> 1) {{jiraslurp.groovy}}
> 2) Several REST-related classes in {{ignite-clients}} module.
> Need to remove this usages and use {{Base64}}. Note that this class is 
> available since Java 8. Hopefully we will move to Java 8 in the same release. 
> Otherwise we will have to apply some reflection-based hacks, I think.



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

[jira] [Updated] (IGNITE-6587) Ignite watchdog service

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6587:
-
Description: 
As described in [1], each Ignite node has a number of system-critical threads. 
We should implement a periodic check that calls failure handler when one of the 
following conditions has been detected:
* Critical thread is not alive anymore.
* Critical thread 'hangs' for a long time, e.g. while executing a task 
extracted from task queue.

In case of failure condition, call stacks of all threads should be logged 
before invoking failure handler.

Actual list of system-critical threads can be found at [1].

Implementations based on separate diagnostic thread seem fragile, cause this 
thread become a vulnerable point with respect to thread termination and CPU 
resource starvation. So we are to use self-monitoring approach: critical 
threads themselves should monitor each other.

Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that fits 
best to store and track system critical threads. All of them should be 
refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each worker 
should periodically choose some subset of peer workers and check whether
* All of them are alive.
* All of them are actively running.

It's required to add a 'heartbeat' timestamp to worker in order to implement 
latter check. Additionally, infinite queue polls, waits on monitors or thread 
parks should be refactored to their timed equivalents in system critical 
threads.

Monitoring parameters (enable/disable, check interval, thread 'hang' threshold, 
etc.) are to be set via system properties.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling

  was:
As described in [1], each Ignite node has a number of system-critical threads. 
We should implement a periodic check that calls failure handler when one of the 
following conditions has been detected:
* Critical thread is not alive anymore.
* Critical thread 'hangs' for a long time, e.g. while executing a task 
extracted from task queue.

In case of failure condition, call stacks of all threads should be logged 
before invoking failure handler.

Actual list of system-critical threads can be found at [1].

Implementations based on separate diagnostic thread seem fragile, cause this 
thread become a vulnerable point with respect to thread termination and CPU 
resource starvation. So we are to use self-monitoring approach: critical 
threads themselves should monitor each other.

Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that fits 
best to store and track system critical threads. All of them should be 
refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each worker 
should periodically choose some subset of peer workers and check whether
* All of them are alive.
* All of them are actively running.

It's required to add a 'heartbeat' timestamp to worker in order to implement 
latter check. Additionally, infinite queue polls, waits on monitors or thread 
parks should be refactored to their timed equivalents in system critical 
threads.

Monitoring parameters (check interval, thread 'hang' threshold, etc.) are to be 
set via system properties.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling


> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: IEP-5
> Fix For: 2.6
>
> Attachments: watchdog.sh
>
>
> As described in [1], each Ignite node has a number of system-critical 
> threads. We should implement a periodic check that calls failure handler when 
> one of the following conditions has been detected:
> * Critical thread is not alive anymore.
> * Critical thread 'hangs' for a long time, e.g. while executing a task 
> extracted from task queue.
> In case of failure condition, call stacks of all threads should be logged 
> before invoking failure handler.
> Actual list of system-critical threads can be found at [1].
> Implementations based on separate diagnostic thread seem fragile, cause this 
> thread become a vulnerable point with respect to thread termination and CPU 
> resource starvation. So we are to use self-monitoring approach: critical 
> threads themselves should monitor each other.
> Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that 
> fits best to store and track system critical threads. All of them should be 
> refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each 
> worker should periodically 

[jira] [Commented] (IGNITE-6893) Java Deadlocks monitoring

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6893:
--

I've done some benchmarks for {{ThreadMXBean::findDeadlockedThreads}}, both on 
Linux and Windows, and the results are good enough. A program with 200 active 
threads continuously contending for 50 synchronization aids (monitors or locks) 
checks itself for deadlocks every 10ms. At worst, deadlock detection consumes 
0,1% of single hardware thread. So we can use it a separate thread in Ignite, 
by checking for deadlocks periodically and calling failure handler if necessary.

> Java Deadlocks monitoring
> -
>
> Key: IGNITE-6893
> URL: https://issues.apache.org/jira/browse/IGNITE-6893
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-7
> Fix For: 2.6
>
>
> Java Level Deadlocks
> Description
> This situation occurs if user or Ignite comes to a Java-level deadlock due to 
> a bug in code - reverse order synchronized(mux1) {synchronized (mux2) {}}  
> sections, reverse order reentrant locks, etc.
> Detection and Solution
> This most likely cannot be resolved automatically and will require JVM 
> restart.
> We can implement periodical threaddumps analysis and detect the deadlock. 
> Report
> Deadlock should be reported to the logs.
> Web Console should fire an alert on java deadlock detection and display a 
> warning on UI.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6893) Java Deadlocks monitoring

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6893:
--

{{ThreadMXBean::findDeadlockedThreads}} don't care whether lock acquisition has 
a timeout or not. In both cases any loop found will be reported as deadlock. We 
can analyze this report more thoroughly by using thread state information 
(WAITING vs TIMED_WAITING).

> Java Deadlocks monitoring
> -
>
> Key: IGNITE-6893
> URL: https://issues.apache.org/jira/browse/IGNITE-6893
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-7
> Fix For: 2.6
>
>
> Java Level Deadlocks
> Description
> This situation occurs if user or Ignite comes to a Java-level deadlock due to 
> a bug in code - reverse order synchronized(mux1) {synchronized (mux2) {}}  
> sections, reverse order reentrant locks, etc.
> Detection and Solution
> This most likely cannot be resolved automatically and will require JVM 
> restart.
> We can implement periodical threaddumps analysis and detect the deadlock. 
> Report
> Deadlock should be reported to the logs.
> Web Console should fire an alert on java deadlock detection and display a 
> warning on UI.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-8406:
--

[~syssoftsol], I like your idea of adding a note to javadoc about possibly 
unnotified listeners upon {{flush}} completion. Although this can be deduced 
from {{IgniteFuture::listen}} description, it's not obvious.

> Update IgniteDataStreamer.flush() javadoc
> -
>
> Key: IGNITE-8406
> URL: https://issues.apache.org/jira/browse/IGNITE-8406
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Priority: Minor
> Fix For: 2.6
>
>
> Current {{flush()}} implementation can throw {{CacheException}} if one or 
> more futures previously returned by {{addData()}} have been completed 
> exceptionally. This behavior should be described in {{IgniteDataStreamer}} 
> javadoc.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-8406:
-
Description: Current {{flush()}} implementation can throw 
{{CacheException}} if one or more futures previously returned by {{addData()}} 
have been completed exceptionally. This behavior should be described in 
{{IgniteDataStreamer}} javadoc. Also it's worth noting explicitly that all 
futures completion upon return from {{flush}} does not imply all those future 
listeners have been completed by this moment.  (was: Current {{flush()}} 
implementation can throw {{CacheException}} if one or more futures previously 
returned by {{addData()}} have been completed exceptionally. This behavior 
should be described in {{IgniteDataStreamer}} javadoc.)

> Update IgniteDataStreamer.flush() javadoc
> -
>
> Key: IGNITE-8406
> URL: https://issues.apache.org/jira/browse/IGNITE-8406
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Priority: Minor
> Fix For: 2.6
>
>
> Current {{flush()}} implementation can throw {{CacheException}} if one or 
> more futures previously returned by {{addData()}} have been completed 
> exceptionally. This behavior should be described in {{IgniteDataStreamer}} 
> javadoc. Also it's worth noting explicitly that all futures completion upon 
> return from {{flush}} does not imply all those future listeners have been 
> completed by this moment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-8406:
--

[~syssoftsol], I still deem the scenario you describe is not a subject for 
'fix'. {{flush()}} just ensures all pending operations have become completed 
(this may or may not throw). Completion status of all futures of interest 
should be tracked separately.

> Update IgniteDataStreamer.flush() javadoc
> -
>
> Key: IGNITE-8406
> URL: https://issues.apache.org/jira/browse/IGNITE-8406
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Priority: Minor
> Fix For: 2.6
>
>
> Current {{flush()}} implementation can throw {{CacheException}} if one or 
> more futures previously returned by {{addData()}} have been completed 
> exceptionally. This behavior should be described in {{IgniteDataStreamer}} 
> javadoc.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6587) Ignite watchdog service

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6587:
-
Description: 
As described in [1], each Ignite node has a number of system-critical threads. 
We should implement a periodic check that calls failure handler when one of the 
following conditions has been detected:
* Critical thread is not alive anymore.
* Critical thread 'hangs' for a long time, e.g. while executing a task 
extracted from task queue.

Actual list of system-critical threads can be found at [1].

Implementations based on separate diagnostic thread seem fragile, cause this 
thread become a vulnerable point with respect to thread termination and CPU 
resource starvation. So we are to use self-monitoring approach: critical 
threads themselves should monitor each other.

Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that fits 
best to store and track system critical threads. All of them should be 
refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each worker 
should periodically choose some subset of peer workers and check whether
* All of them are alive.
* All of them are actively running.

It's required to add a 'heartbeat' timestamp to worker in order to implement 
latter check. Additionally, infinite queue polls, waits on monitors or thread 
parks should be refactored to their timed equivalents in system critical 
threads.

Monitoring parameters (check interval, thread 'hang' threshold, etc.) are to be 
set via system properties.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling

  was:
As described in [1], each Ignite node has a number of system-critical threads. 
We should implement a periodic check that calls failure handler when one of the 
following conditions has been detected:
* Critical thread is not alive anymore.
* Critical thread 'hangs' for a long time, e.g. while executing a task 
extracted from task queue.

Actual list of system-critical threads can be found at [1].

Implementations based on separate diagnostic thread seem fragile, cause this 
thread become a vulnerable point with respect to thread termination and CPU 
resource starvation. So we are to use self-monitoring approach: critical 
threads themselves should monitor each other.

Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that fits 
best to store and track system critical threads. All of them should be 
refactored to be {{GridWorker}}s and added to {{WorkersRegistry}}. Each worker 
should periodically choose some subset of peer workers and check whether
* All of them are alive.
* All of them are actively running.

It's required to add a 'heartbeat' timestamp to worker in order to implement 
latter check. Additionally, infinite queue polls, waits on monitors or thread 
parks should be refactored to their timed equivalents in system critical 
threads.

Monitoring parameters (check interval, thread 'hang' threshold, etc.) are to be 
set via system properties.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling


> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: IEP-5
> Fix For: 2.6
>
> Attachments: watchdog.sh
>
>
> As described in [1], each Ignite node has a number of system-critical 
> threads. We should implement a periodic check that calls failure handler when 
> one of the following conditions has been detected:
> * Critical thread is not alive anymore.
> * Critical thread 'hangs' for a long time, e.g. while executing a task 
> extracted from task queue.
> Actual list of system-critical threads can be found at [1].
> Implementations based on separate diagnostic thread seem fragile, cause this 
> thread become a vulnerable point with respect to thread termination and CPU 
> resource starvation. So we are to use self-monitoring approach: critical 
> threads themselves should monitor each other.
> Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that 
> fits best to store and track system critical threads. All of them should be 
> refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each 
> worker should periodically choose some subset of peer workers and check 
> whether
> * All of them are alive.
> * All of them are actively running.
> It's required to add a 'heartbeat' timestamp to worker in order to implement 
> latter check. Additionally, infinite queue polls, waits on monitors or thread 
> parks should be refactored to their timed equivalents in system 

[jira] [Updated] (IGNITE-6587) Ignite watchdog service

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6587:
-
Description: 
As described in [1], each Ignite node has a number of system-critical threads. 
We should implement a periodic check that calls failure handler when one of the 
following conditions has been detected:
* Critical thread is not alive anymore.
* Critical thread 'hangs' for a long time, e.g. while executing a task 
extracted from task queue.
Actual list of system-critical threads can be found at [1].

Implementations based on separate diagnostic thread seem fragile, cause this 
thread become a vulnerable point with respect to thread termination and CPU 
resource starvation. So we are to use self-monitoring approach: critical 
threads themselves should monitor each other.

Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that fits 
best to store and track system critical threads. All of them should be 
refactored to be {{GridWorker}}s and added to {{WorkersRegistry}}. Each worker 
should periodically choose some subset of peer workers and check whether
* All of them are alive.
* All of them are actively running.
It's required to add a 'heartbeat' timestamp to worker in order to implement 
latter check. Additionally, infinite queue polls, waits on monitors or thread 
parks should be refactored to their timed equivalents in system critical 
threads.

Monitoring parameters (check interval, thread 'hang' threshold, etc.) are to be 
set via system properties.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling

  was:
As described in [1], each Ignite node has a number of system-critical threads. 
We should implement a periodic check that calls failure handler when one of the 
following conditions has been detected:
# Critical thread is not alive anymore.
# Critical thread 'hangs' for a long time, e.g. while executing a task 
extracted from task queue. 

Actual list of system-critical threads can be found at [1].

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling


> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: IEP-5
> Fix For: 2.6
>
> Attachments: watchdog.sh
>
>
> As described in [1], each Ignite node has a number of system-critical 
> threads. We should implement a periodic check that calls failure handler when 
> one of the following conditions has been detected:
> * Critical thread is not alive anymore.
> * Critical thread 'hangs' for a long time, e.g. while executing a task 
> extracted from task queue.
> Actual list of system-critical threads can be found at [1].
> Implementations based on separate diagnostic thread seem fragile, cause this 
> thread become a vulnerable point with respect to thread termination and CPU 
> resource starvation. So we are to use self-monitoring approach: critical 
> threads themselves should monitor each other.
> Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that 
> fits best to store and track system critical threads. All of them should be 
> refactored to be {{GridWorker}}s and added to {{WorkersRegistry}}. Each 
> worker should periodically choose some subset of peer workers and check 
> whether
> * All of them are alive.
> * All of them are actively running.
> It's required to add a 'heartbeat' timestamp to worker in order to implement 
> latter check. Additionally, infinite queue polls, waits on monitors or thread 
> parks should be refactored to their timed equivalents in system critical 
> threads.
> Monitoring parameters (check interval, thread 'hang' threshold, etc.) are to 
> be set via system properties.
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6587) Ignite watchdog service

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6587:
-
Description: 
As described in [1], each Ignite node has a number of system-critical threads. 
We should implement a periodic check that calls failure handler when one of the 
following conditions has been detected:
* Critical thread is not alive anymore.
* Critical thread 'hangs' for a long time, e.g. while executing a task 
extracted from task queue.

Actual list of system-critical threads can be found at [1].

Implementations based on separate diagnostic thread seem fragile, cause this 
thread become a vulnerable point with respect to thread termination and CPU 
resource starvation. So we are to use self-monitoring approach: critical 
threads themselves should monitor each other.

Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that fits 
best to store and track system critical threads. All of them should be 
refactored to be {{GridWorker}}s and added to {{WorkersRegistry}}. Each worker 
should periodically choose some subset of peer workers and check whether
* All of them are alive.
* All of them are actively running.

It's required to add a 'heartbeat' timestamp to worker in order to implement 
latter check. Additionally, infinite queue polls, waits on monitors or thread 
parks should be refactored to their timed equivalents in system critical 
threads.

Monitoring parameters (check interval, thread 'hang' threshold, etc.) are to be 
set via system properties.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling

  was:
As described in [1], each Ignite node has a number of system-critical threads. 
We should implement a periodic check that calls failure handler when one of the 
following conditions has been detected:
* Critical thread is not alive anymore.
* Critical thread 'hangs' for a long time, e.g. while executing a task 
extracted from task queue.
Actual list of system-critical threads can be found at [1].

Implementations based on separate diagnostic thread seem fragile, cause this 
thread become a vulnerable point with respect to thread termination and CPU 
resource starvation. So we are to use self-monitoring approach: critical 
threads themselves should monitor each other.

Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that fits 
best to store and track system critical threads. All of them should be 
refactored to be {{GridWorker}}s and added to {{WorkersRegistry}}. Each worker 
should periodically choose some subset of peer workers and check whether
* All of them are alive.
* All of them are actively running.
It's required to add a 'heartbeat' timestamp to worker in order to implement 
latter check. Additionally, infinite queue polls, waits on monitors or thread 
parks should be refactored to their timed equivalents in system critical 
threads.

Monitoring parameters (check interval, thread 'hang' threshold, etc.) are to be 
set via system properties.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling


> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: IEP-5
> Fix For: 2.6
>
> Attachments: watchdog.sh
>
>
> As described in [1], each Ignite node has a number of system-critical 
> threads. We should implement a periodic check that calls failure handler when 
> one of the following conditions has been detected:
> * Critical thread is not alive anymore.
> * Critical thread 'hangs' for a long time, e.g. while executing a task 
> extracted from task queue.
> Actual list of system-critical threads can be found at [1].
> Implementations based on separate diagnostic thread seem fragile, cause this 
> thread become a vulnerable point with respect to thread termination and CPU 
> resource starvation. So we are to use self-monitoring approach: critical 
> threads themselves should monitor each other.
> Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that 
> fits best to store and track system critical threads. All of them should be 
> refactored to be {{GridWorker}}s and added to {{WorkersRegistry}}. Each 
> worker should periodically choose some subset of peer workers and check 
> whether
> * All of them are alive.
> * All of them are actively running.
> It's required to add a 'heartbeat' timestamp to worker in order to implement 
> latter check. Additionally, infinite queue polls, waits on monitors or thread 
> parks should be refactored to their timed equivalents in system 

[jira] [Updated] (IGNITE-6587) Ignite watchdog service

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6587:
-
Description: 
As described in [1], each Ignite node has a number of system-critical threads. 
We should implement a periodic check that calls failure handler when one of the 
following conditions has been detected:
* Critical thread is not alive anymore.
* Critical thread 'hangs' for a long time, e.g. while executing a task 
extracted from task queue.

In case of failure condition, call stacks of all threads should be logged 
before invoking failure handler.

Actual list of system-critical threads can be found at [1].

Implementations based on separate diagnostic thread seem fragile, cause this 
thread become a vulnerable point with respect to thread termination and CPU 
resource starvation. So we are to use self-monitoring approach: critical 
threads themselves should monitor each other.

Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that fits 
best to store and track system critical threads. All of them should be 
refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each worker 
should periodically choose some subset of peer workers and check whether
* All of them are alive.
* All of them are actively running.

It's required to add a 'heartbeat' timestamp to worker in order to implement 
latter check. Additionally, infinite queue polls, waits on monitors or thread 
parks should be refactored to their timed equivalents in system critical 
threads.

Monitoring parameters (check interval, thread 'hang' threshold, etc.) are to be 
set via system properties.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling

  was:
As described in [1], each Ignite node has a number of system-critical threads. 
We should implement a periodic check that calls failure handler when one of the 
following conditions has been detected:
* Critical thread is not alive anymore.
* Critical thread 'hangs' for a long time, e.g. while executing a task 
extracted from task queue.

Actual list of system-critical threads can be found at [1].

Implementations based on separate diagnostic thread seem fragile, cause this 
thread become a vulnerable point with respect to thread termination and CPU 
resource starvation. So we are to use self-monitoring approach: critical 
threads themselves should monitor each other.

Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that fits 
best to store and track system critical threads. All of them should be 
refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each worker 
should periodically choose some subset of peer workers and check whether
* All of them are alive.
* All of them are actively running.

It's required to add a 'heartbeat' timestamp to worker in order to implement 
latter check. Additionally, infinite queue polls, waits on monitors or thread 
parks should be refactored to their timed equivalents in system critical 
threads.

Monitoring parameters (check interval, thread 'hang' threshold, etc.) are to be 
set via system properties.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling


> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: IEP-5
> Fix For: 2.6
>
> Attachments: watchdog.sh
>
>
> As described in [1], each Ignite node has a number of system-critical 
> threads. We should implement a periodic check that calls failure handler when 
> one of the following conditions has been detected:
> * Critical thread is not alive anymore.
> * Critical thread 'hangs' for a long time, e.g. while executing a task 
> extracted from task queue.
> In case of failure condition, call stacks of all threads should be logged 
> before invoking failure handler.
> Actual list of system-critical threads can be found at [1].
> Implementations based on separate diagnostic thread seem fragile, cause this 
> thread become a vulnerable point with respect to thread termination and CPU 
> resource starvation. So we are to use self-monitoring approach: critical 
> threads themselves should monitor each other.
> Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that 
> fits best to store and track system critical threads. All of them should be 
> refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each 
> worker should periodically choose some subset of peer workers and check 
> whether
> * All of them are alive.
> * All of them are actively running.
> It's 

[jira] [Created] (IGNITE-8562) Turn system-critical Ignite threads into GridWorkers

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-8562:


 Summary: Turn system-critical Ignite threads into GridWorkers
 Key: IGNITE-8562
 URL: https://issues.apache.org/jira/browse/IGNITE-8562
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
 Fix For: 2.6


The goal of the change is to make system-critical threads (in terms of IEP-14, 
[1]) available to {{WorkersControlMXBean}}.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6587) Ignite watchdog service

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6587:
--

Changing critical threads to {{GridWorkers}} has been brought to separate 
issue, since it has it's own value.

> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: IEP-5
> Fix For: 2.6
>
> Attachments: watchdog.sh
>
>
> As described in [1], each Ignite node has a number of system-critical 
> threads. We should implement a periodic check that calls failure handler when 
> one of the following conditions has been detected:
> * Critical thread is not alive anymore.
> * Critical thread 'hangs' for a long time, e.g. while executing a task 
> extracted from task queue.
> In case of failure condition, call stacks of all threads should be logged 
> before invoking failure handler.
> Actual list of system-critical threads can be found at [1].
> Implementations based on separate diagnostic thread seem fragile, cause this 
> thread become a vulnerable point with respect to thread termination and CPU 
> resource starvation. So we are to use self-monitoring approach: critical 
> threads themselves should monitor each other.
> Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that 
> fits best to store and track system critical threads. All of them should be 
> refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each 
> worker should periodically choose some subset of peer workers and check 
> whether
> * All of them are alive.
> * All of them are actively running.
> It's required to add a 'heartbeat' timestamp to worker in order to implement 
> latter check. Additionally, infinite queue polls, waits on monitors or thread 
> parks should be refactored to their timed equivalents in system critical 
> threads.
> Monitoring parameters (enable/disable, check interval, thread 'hang' 
> threshold, etc.) are to be set via system properties.
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8570) Create lighter version of GridStringLogger

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-8570:


 Summary: Create lighter version of GridStringLogger
 Key: IGNITE-8570
 URL: https://issues.apache.org/jira/browse/IGNITE-8570
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
 Fix For: 2.6


Most usages of {{GridStringLogger}} in test assumes the following scenario. 
First, it is set as a logger for some Ignite node. Then, after some activity on 
that node, log content is searched for some predefined strings. 
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to store 
log contents, older contents gets dropped on exaustion. Thus, changes that add 
more logging may damage some independent tests that use {{GridStringLogger}}.

The suggestion is to implement and use another test logger conforming to these 
requirements:
* It does not accumulate any logs.
* It allows to set the listener that fires when log message matches certain 
regular expression, {{Matcher}} can be passed to the listener.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8823) Incorrect transaction state in tx manager

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-8823:


Assignee: Andrey Kuznetsov

> Incorrect transaction state in tx manager
> -
>
> Key: IGNITE-8823
> URL: https://issues.apache.org/jira/browse/IGNITE-8823
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
>
> Reproducable by test 
> {{org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest#testCreateConsistencyMultithreaded}}:
> {noformat}
> 18:34:40,701][SEVERE][sys-stripe-0-#44%ignite%][GridCacheIoManager] Failed 
> processing message [senderId=e273c3f8-02ed-4201-9ac8-09f9ab6a1d31, 
> msg=GridNearTxPrepareResponse [pending=[], 
> futId=b4df8831461-9735f9d5-79a0-47a3-a951-e62a03af71ef, miniId=1, 
> dhtVer=GridCacheVersion [topVer=140816081, order=1529336085358, nodeOrder=3], 
> writeVer=GridCacheVersion [topVer=140816081, order=1529336085360, 
> nodeOrder=3], ownedVals=null, retVal=GridCacheReturn [v=null, cacheObj=null, 
> success=true, invokeRes=true, loc=true, cacheId=0], clientRemapVer=null, 
> super=GridDistributedTxPrepareResponse 
> [txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false], 
> part=-1, err=null, super=GridDistributedBaseMessage [ver=GridCacheVersion 
> [topVer=140816081, order=1529336085224, nodeOrder=1], committedVers=null, 
> rolledbackVers=null, cnt=0, super=GridCacheIdMessage [cacheId=0]
> java.lang.AssertionError: true instead of GridCacheReturnCompletableWrapper
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1098)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.ackBackup(GridNearTxFinishFuture.java:533)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:500)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3341)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:310)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:288)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:78)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture$MiniFuture.onResult(GridNearOptimisticTxPrepareFuture.java:1017)
>   at 
> 

[jira] [Comment Edited] (IGNITE-6587) Ignite watchdog service

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov edited comment on IGNITE-6587 at 5/29/18 7:17 PM:
---

Changing critical threads to {{GridWorkers}} has been brought to separate 
issue, since it has its own value.


was (Author: andrey-kuznetsov):
Changing critical threads to {{GridWorkers}} has been brought to separate 
issue, since it has it's own value.

> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: IEP-5
> Fix For: 2.6
>
> Attachments: watchdog.sh
>
>
> As described in [1], each Ignite node has a number of system-critical 
> threads. We should implement a periodic check that calls failure handler when 
> one of the following conditions has been detected:
> * Critical thread is not alive anymore.
> * Critical thread 'hangs' for a long time, e.g. while executing a task 
> extracted from task queue.
> In case of failure condition, call stacks of all threads should be logged 
> before invoking failure handler.
> Actual list of system-critical threads can be found at [1].
> Implementations based on separate diagnostic thread seem fragile, cause this 
> thread become a vulnerable point with respect to thread termination and CPU 
> resource starvation. So we are to use self-monitoring approach: critical 
> threads themselves should monitor each other.
> Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that 
> fits best to store and track system critical threads. All of them should be 
> refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each 
> worker should periodically choose some subset of peer workers and check 
> whether
> * All of them are alive.
> * All of them are actively running.
> It's required to add a 'heartbeat' timestamp to worker in order to implement 
> latter check. Additionally, infinite queue polls, waits on monitors or thread 
> parks should be refactored to their timed equivalents in system critical 
> threads.
> Monitoring parameters (enable/disable, check interval, thread 'hang' 
> threshold, etc.) are to be set via system properties.
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8642) Failure processor should dump state of all threads

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-8642:


Assignee: Andrey Kuznetsov

> Failure processor should dump state of all threads
> --
>
> Key: IGNITE-8642
> URL: https://issues.apache.org/jira/browse/IGNITE-8642
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.6
>
>
> Failure processor should dump state of all threads before failure processor 
> will be invoked.
> Use {{org.apache.ignite.internal.util.IgniteUtils#dumpThreads}} method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)