[jira] [Assigned] (IGNITE-5965) Ignite Basic: Flaky failure of GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology

2018-05-12 Thread Andrew Medvedev (JIRA) 

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

Andrew Medvedev reassigned IGNITE-5965:
---

Assignee: Andrew Medvedev

> Ignite Basic: Flaky failure of  
> GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology
> --
>
> Key: IGNITE-5965
> URL: https://issues.apache.org/jira/browse/IGNITE-5965
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Andrew Medvedev
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Attachments: log.txt
>
>
> Test has 85% success rate in master:
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-2642357454043293898=testDetails_Ignite20Tests=%3Cdefault%3E
> Flaky failure is reproduced locally with similar success rate (24/30, Win 10).
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :4
> Actual   :5
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorAbstractSelfTest.checkCount(GridServiceProcessorAbstractSelfTest.java:765)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.checkDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:287)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:144)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Commented] (IGNITE-5965) Ignite Basic: Flaky failure of GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology

2018-05-12 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on IGNITE-5965:


GitHub user andrewmed opened a pull request:

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

IGNITE-5965 fix Flaky failure of GridServiceProcessorMultiNodeConfigS…

Test fixed by decreasing connection timeout. Now 
GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology 
that should have failed earlier because of topology not being updated on nodes 
exit (cause of failures), succeeds but runs > 10 sec. This fix gives 200/200 
success rate, but I am not really sure if the approach is right. Needs reviewing

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

$ git pull https://github.com/andrewmed/ignite IGNITE-5965

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

https://github.com/apache/ignite/pull/3988.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3988


commit 82cf7f21c6532c6d4daa586e77a914b7049ac13a
Author: AMedvedev 
Date:   2018-05-12T21:02:16Z

IGNITE-5965 fix Flaky failure of 
GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology




> Ignite Basic: Flaky failure of  
> GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology
> --
>
> Key: IGNITE-5965
> URL: https://issues.apache.org/jira/browse/IGNITE-5965
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Attachments: log.txt
>
>
> Test has 85% success rate in master:
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-2642357454043293898=testDetails_Ignite20Tests=%3Cdefault%3E
> Flaky failure is reproduced locally with similar success rate (24/30, Win 10).
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :4
> Actual   :5
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorAbstractSelfTest.checkCount(GridServiceProcessorAbstractSelfTest.java:765)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.checkDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:287)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:144)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

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

2018-05-12 Thread Andrew Medvedev (JIRA) 

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

Andrew Medvedev commented on IGNITE-5998:
-

In history its success rate is 98.4 - 99%

 

> 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-5998) Assertion during partition creation in tests

2018-05-12 Thread Andrew Medvedev (JIRA) 

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

Andrew Medvedev commented on IGNITE-5998:
-

Test does not fail.

Should it be set to resolved?

 

[https://ci.ignite.apache.org/viewLog.html?buildId=1042848=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1040706=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1037913=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1037068=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1036008=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1034959=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1034879=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1032870=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1030282=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1026715=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1026882=IgniteTests20_IgniteQueries2=testsInfo]

[https://ci.ignite.apache.org/viewLog.html?buildId=1025906=IgniteTests20_IgniteQueries2=testsInfo]

 

 

> 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): 
>

[jira] [Comment Edited] (IGNITE-5965) Ignite Basic: Flaky failure of GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology

2018-05-12 Thread Andrew Medvedev (JIRA) 

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

Andrew Medvedev edited comment on IGNITE-5965 at 5/12/18 2:39 PM:
--

Failing tests are related to messaging layer. All failing tests have "connect 
timed out" and "failed to send event notification" messages, so we get larger 
set of ServiceDescriptors for nodes, than there are actual nodes and topology 
does not get updated for all "Node left topology" events

 
{quote}[2018-05-12 
16:55:54,072][ERROR][utility-#20468%service.GridServiceProcessorMultiNodeConfigSelfTest2%|#20468%service.GridServiceProcessorMultiNodeConfigSelfTest2%][query]
 Failed to send event notification to node: cd8be305-ed5c-4f38-baad-64817296
 class org.apache.ignite.IgniteCheckedException: Failed to send message (node 
may have left the grid or TCP connection cannot be established due to firewall 
issues) [node=TcpDiscoveryNode [id=cd8be305-ed5c-4f38-baad-64817296, 
addrs=[127.0.0.1, 192.168.3.235, 192.168.43.79], sockAddrs=[/127.0.0.1:0, 
/192.168.3.235:0, /192.168.43.79:0], discPort=0, order=31, intOrder=19, 
lastExchangeTime=1526133351915, loc=false, ver=2.4.0#19700101-sha1:, 
isClient=true], topic=T4 [topic=TOPIC_CACHE, 
id1=5dc785b4-dd3d-3c3b-b270-c5fe2d7ed9a2, 
id2=cd8be305-ed5c-4f38-baad-64817296, id3=1], msg=GridContinuousMessage 
[type=MSG_EVT_NOTIFICATION, routineId=a1034d59-1476-4e44-8811-d498b65f450c, 
data=null, futId=null], policy=2]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1650)
 
{quote}
 

 


was (Author: andmed):
Failing tests are related to messaging layer. All failing tests have connect 
timed out and failed to send event notification messages, so we get larger set 
of ServiceDescriptors for nodes, than there are actual nodes.

 
{quote}[2018-05-12 
16:55:54,072][ERROR][utility-#20468%service.GridServiceProcessorMultiNodeConfigSelfTest2%][query]
 Failed to send event notification to node: cd8be305-ed5c-4f38-baad-64817296
class org.apache.ignite.IgniteCheckedException: Failed to send message (node 
may have left the grid or TCP connection cannot be established due to firewall 
issues) [node=TcpDiscoveryNode [id=cd8be305-ed5c-4f38-baad-64817296, 
addrs=[127.0.0.1, 192.168.3.235, 192.168.43.79], sockAddrs=[/127.0.0.1:0, 
/192.168.3.235:0, /192.168.43.79:0], discPort=0, order=31, intOrder=19, 
lastExchangeTime=1526133351915, loc=false, ver=2.4.0#19700101-sha1:, 
isClient=true], topic=T4 [topic=TOPIC_CACHE, 
id1=5dc785b4-dd3d-3c3b-b270-c5fe2d7ed9a2, 
id2=cd8be305-ed5c-4f38-baad-64817296, id3=1], msg=GridContinuousMessage 
[type=MSG_EVT_NOTIFICATION, routineId=a1034d59-1476-4e44-8811-d498b65f450c, 
data=null, futId=null], policy=2]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1650)
 {quote}
 

 

> Ignite Basic: Flaky failure of  
> GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology
> --
>
> Key: IGNITE-5965
> URL: https://issues.apache.org/jira/browse/IGNITE-5965
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Attachments: log.txt
>
>
> Test has 85% success rate in master:
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-2642357454043293898=testDetails_Ignite20Tests=%3Cdefault%3E
> Flaky failure is reproduced locally with similar success rate (24/30, Win 10).
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :4
> Actual   :5
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorAbstractSelfTest.checkCount(GridServiceProcessorAbstractSelfTest.java:765)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.checkDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:287)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:144)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
>

[jira] [Commented] (IGNITE-5965) Ignite Basic: Flaky failure of GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology

2018-05-12 Thread Andrew Medvedev (JIRA) 

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

Andrew Medvedev commented on IGNITE-5965:
-

Failing tests are related to messaging layer. All failing tests have connect 
timed out and failed to send event notification messages, so we get larger set 
of ServiceDescriptors for nodes, than there are actual nodes.

 
{quote}[2018-05-12 
16:55:54,072][ERROR][utility-#20468%service.GridServiceProcessorMultiNodeConfigSelfTest2%][query]
 Failed to send event notification to node: cd8be305-ed5c-4f38-baad-64817296
class org.apache.ignite.IgniteCheckedException: Failed to send message (node 
may have left the grid or TCP connection cannot be established due to firewall 
issues) [node=TcpDiscoveryNode [id=cd8be305-ed5c-4f38-baad-64817296, 
addrs=[127.0.0.1, 192.168.3.235, 192.168.43.79], sockAddrs=[/127.0.0.1:0, 
/192.168.3.235:0, /192.168.43.79:0], discPort=0, order=31, intOrder=19, 
lastExchangeTime=1526133351915, loc=false, ver=2.4.0#19700101-sha1:, 
isClient=true], topic=T4 [topic=TOPIC_CACHE, 
id1=5dc785b4-dd3d-3c3b-b270-c5fe2d7ed9a2, 
id2=cd8be305-ed5c-4f38-baad-64817296, id3=1], msg=GridContinuousMessage 
[type=MSG_EVT_NOTIFICATION, routineId=a1034d59-1476-4e44-8811-d498b65f450c, 
data=null, futId=null], policy=2]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1650)
 {quote}
 

 

> Ignite Basic: Flaky failure of  
> GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology
> --
>
> Key: IGNITE-5965
> URL: https://issues.apache.org/jira/browse/IGNITE-5965
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Attachments: log.txt
>
>
> Test has 85% success rate in master:
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-2642357454043293898=testDetails_Ignite20Tests=%3Cdefault%3E
> Flaky failure is reproduced locally with similar success rate (24/30, Win 10).
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :4
> Actual   :5
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorAbstractSelfTest.checkCount(GridServiceProcessorAbstractSelfTest.java:765)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.checkDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:287)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:144)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Updated] (IGNITE-5965) Ignite Basic: Flaky failure of GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology

2018-05-12 Thread Andrew Medvedev (JIRA) 

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

Andrew Medvedev updated IGNITE-5965:

Attachment: log.txt

> Ignite Basic: Flaky failure of  
> GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology
> --
>
> Key: IGNITE-5965
> URL: https://issues.apache.org/jira/browse/IGNITE-5965
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Attachments: log.txt
>
>
> Test has 85% success rate in master:
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-2642357454043293898=testDetails_Ignite20Tests=%3Cdefault%3E
> Flaky failure is reproduced locally with similar success rate (24/30, Win 10).
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :4
> Actual   :5
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorAbstractSelfTest.checkCount(GridServiceProcessorAbstractSelfTest.java:765)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.checkDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:287)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:144)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Updated] (IGNITE-6677) Collect QueryDetailMetrics for cache-less SQL queries

2018-05-12 Thread Dmitriy Setrakyan (JIRA) 

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

Dmitriy Setrakyan updated IGNITE-6677:
--
Fix Version/s: 2.6

> Collect QueryDetailMetrics for cache-less SQL queries
> -
>
> Key: IGNITE-6677
> URL: https://issues.apache.org/jira/browse/IGNITE-6677
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.2
>Reporter: Alexey Kuznetsov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> We have logic that collect query history per caches.
> We need:
> # Add history size param on IgniteConfiguration
> # Implement logic that will collect history for SQL queries executed directly.



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

[jira] [Comment Edited] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky

2018-05-12 Thread Alexey Kuznetsov (JIRA) 

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

Alexey Kuznetsov edited comment on IGNITE-5960 at 5/12/18 1:08 PM:
---

[~agoncharuk] 
 > Note that it would be cleaner to acquire the listeners map after the 
 > partition update counter is incremented, however, the listeners map is used 
 > in the needVal flag evaluation.

Yeah, I tried to acquire the listeners map *after* the partition update counter 
is incremented:
 To do so, we firstly need to move _needVal_ and _readFromStore_ flags 
evaluation after update counter is incremented.
 But _readFromStore_ flag must be evaluated strongly *before* partition counter 
is incremented, see _GridCacheMapEntry.AtomicCacheUpdateClosure#call_ where we 
load data from store.

So, we cannot acquire the listeners map *after* the partition update counter is 
incremented.

 

> Currently it is possible that {{evtOldVal}} will be {{null}} if we read 
>{{null}} from {{updateListeners}} in the first place.

In my fix, query entry must be filtered out  if we read {{null}} from 
{{updateListeners}} in the first place(this fixes the essential bug).

To filter out entry, _newVal_ and _oldVal_ must be passed as nulls to 
_cctx.continuousQueries().onEntryUpdated_ ,
 see _CacheContinuousQueryManager#onEntryUpdated_ , 
_CacheContinuousQueryManager#skipUpdateEvent_ .

Let's consider again the scenario:

1) T1 updates E1 (updateCounter gets incremented to 1);
 2) T2 updates E2 (updateCounter gets incremented to 2);
 3) T2 finishes update and exits GridCacheMapEntry::innerUpdate method; In this 
point we have CacheContinuousQueryEventBuffer#currentPartitionCounter equals 2
 4) user adds continuous query listener;
 5) T1 proceeds, picks up listener (not null thanks to the fix) and notifies 
listener; Batch#startCntr equals 2 (currentPartitionCounter() returns 2) so 
 entry E1 would be filtered out of Batch (E1 update counter would be smaller 
than Batch#startCntr)
 PS E1 also can be sent to remote node(if we have remote listener installed) 
and processed in CacheContinuousQueryPartitionRecovery#collectEntries,
 but it would be filtered out there.
 6) T3 updates E3 (updateCounter gets incremented to 3) and notifies listener;

After 6) user's listener would be notified only once by key 3.

After listener is set by user, entry E1 must be filtered out.

 

Are you agree with such changes ?


was (Author: alexey kuznetsov):
[~agoncharuk] 
 > Note that it would be cleaner to acquire the listeners map after the 
 > partition update counter is incremented, however, the listeners map is used 
 > in the needVal flag evaluation.

Yeah, I tried to acquire the listeners map *after* the partition update counter 
is incremented:
To do so, we firstly need to move _needVal_ and _readFromStore_ flags 
evaluation after update counter is incremented.
But _readFromStore_ flag must be evaluated strongly *before* partition counter 
is incremented, see _GridCacheMapEntry.AtomicCacheUpdateClosure#call_ where we 
load data from store.

So, we cannot acquire the listeners map *after* the partition update counter is 
incremented.

> Currently it is possible that {{evtOldVal}} will be {{null}} if we read 
>{{null}} from {{updateListeners}} in the first place.

In my fix, query entry must be filtered out  if we read {{null}} from 
{{updateListeners}} in the first place(this fixes the essential bug).

To filter out entry, _newVal_ and _oldVal_ must be passed as nulls to 
_cctx.continuousQueries().onEntryUpdated_ ,
see _CacheContinuousQueryManager#onEntryUpdated_ , 
_CacheContinuousQueryManager#skipUpdateEvent_ .

Let's consider again the scenario:

1) T1 updates E1 (updateCounter gets incremented to 1);
 2) T2 updates E2 (updateCounter gets incremented to 2);
 3) T2 finishes update and exits GridCacheMapEntry::innerUpdate method; In this 
point we have CacheContinuousQueryEventBuffer#currentPartitionCounter equals 2
 4) user adds continuous query listener;
 5) T1 proceeds, picks up listener (not null thanks to the fix) and notifies 
listener; Batch#startCntr equals 2 (currentPartitionCounter() returns 2) so 
 entry E1 would be filtered out of Batch (E1 update counter would be smaller 
than Batch#startCntr)
 PS E1 also can be sent to remote node(if we have remote listener installed) 
and processed in CacheContinuousQueryPartitionRecovery#collectEntries,
 but it would be filtered out there.
 6) T3 updates E3 (updateCounter gets incremented to 3) and notifies listener;

After 6) user's listener would be notified only once by key 3.

After listener is set by user, entry E1 must be filtered out.

 

Are you agree with such changes ?

> Ignite Continuous Query (Queries 3): 
> CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic
>  is flaky
>

[jira] [Updated] (IGNITE-8475) Create new cache adapter with fair async methonds

2018-05-12 Thread Dmitriy Govorukhin (JIRA) 

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

Dmitriy Govorukhin updated IGNITE-8475:
---
Description: 
GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async operation 
completed. 

This means all async operation in one thread will be executed one by one but 
not in parallel. Async operation is not async. 

Example for atomic cache 

f1=cache.getAsync(key1); 
f2=cache.getAsync(key2); 

f1 always will be complete before f2. 

Need to create a new cache adapter with fair async operations. (internal use)

[dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/async-operation-is-not-fair-async-td30364.html]

  was:
GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async operation 
completed. 

This means all async operation in one thread will be executed one by one but 
not in parallel. Async operation is not async. 

Example for atomic cache 

f1=cache.getAsync(key1); 
f2=cache.getAsync(key2); 

f1 always will be complete before f2. 

Need to create a new cache adapter with fair async operations. Only for 
internal purose 

[dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/async-operation-is-not-fair-async-td30364.html]


> Create new cache adapter with fair async methonds
> -
>
> Key: IGNITE-8475
> URL: https://issues.apache.org/jira/browse/IGNITE-8475
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Dmitriy Govorukhin
>Priority: Major
>
> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async 
> operation completed. 
> This means all async operation in one thread will be executed one by one but 
> not in parallel. Async operation is not async. 
> Example for atomic cache 
> f1=cache.getAsync(key1); 
> f2=cache.getAsync(key2); 
> f1 always will be complete before f2. 
> Need to create a new cache adapter with fair async operations. (internal use)
> [dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/async-operation-is-not-fair-async-td30364.html]



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

[jira] [Updated] (IGNITE-8475) Create new cache adapter with fair async methonds

2018-05-12 Thread Dmitriy Govorukhin (JIRA) 

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

Dmitriy Govorukhin updated IGNITE-8475:
---
Description: 
GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async operation 
completed. 

This means all async operation in one thread will be executed one by one but 
not in parallel. Async operation is not async. 

Example for atomic cache 

f1=cache.getAsync(key1); 
f2=cache.getAsync(key2); 

f1 always will be complete before f2. 

Need to create a new cache adapter with fair async operations. Only for 
internal purose 

[dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/async-operation-is-not-fair-async-td30364.html]

  was:
GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async operation 
completed. 

This means all async operation in one thread will be executed one by one but 
not in parallel. Async operation is not async. 

Example for atomic cache 

f1=cache.getAsync(key1); 
 f2=cache.getAsync(key2); 

f1 always will be complete before f2. 

Need to create a new decorator for IgniteCache, and return IgniteCache proxy 
with fair async operations.

IgniteCache.withFairAsync()

[dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/async-operation-is-not-fair-async-td30364.html]


> Create new cache adapter with fair async methonds
> -
>
> Key: IGNITE-8475
> URL: https://issues.apache.org/jira/browse/IGNITE-8475
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Dmitriy Govorukhin
>Priority: Major
>
> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async 
> operation completed. 
> This means all async operation in one thread will be executed one by one but 
> not in parallel. Async operation is not async. 
> Example for atomic cache 
> f1=cache.getAsync(key1); 
> f2=cache.getAsync(key2); 
> f1 always will be complete before f2. 
> Need to create a new cache adapter with fair async operations. Only for 
> internal purose 
> [dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/async-operation-is-not-fair-async-td30364.html]



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

[jira] [Updated] (IGNITE-8475) Create new cache adapter with fair async methonds

2018-05-12 Thread Dmitriy Govorukhin (JIRA) 

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

Dmitriy Govorukhin updated IGNITE-8475:
---
Summary: Create new cache adapter with fair async methonds  (was: Create 
new IgniteCache decorator with fair async methonds)

> Create new cache adapter with fair async methonds
> -
>
> Key: IGNITE-8475
> URL: https://issues.apache.org/jira/browse/IGNITE-8475
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Dmitriy Govorukhin
>Priority: Major
>
> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async 
> operation completed. 
> This means all async operation in one thread will be executed one by one but 
> not in parallel. Async operation is not async. 
> Example for atomic cache 
> f1=cache.getAsync(key1); 
>  f2=cache.getAsync(key2); 
> f1 always will be complete before f2. 
> Need to create a new decorator for IgniteCache, and return IgniteCache proxy 
> with fair async operations.
> IgniteCache.withFairAsync()
> [dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/async-operation-is-not-fair-async-td30364.html]



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