[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix

2019-06-17 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-10663:


{panel:title=-- Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Interceptor Cache (Full API Config Variations / Basic)*{color} 
[[tests 208|https://ci.ignite.apache.org/viewLog.html?buildId=4140360]]
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_24.testGetAndPutIfAbsent
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_0.testPutxIfAbsentAsyncNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_76.testPutxIfAbsentAsyncOldNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_48.testWithSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_24.testRemoveAllSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_62.testWithSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_76.testGetAndPutIfAbsent
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_52.testPutxIfAbsentAsyncNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_28.testWithSkipStoreRemoveAll
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_0.testPutxIfAbsentAsyncOldNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_17.testWithSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_76.testRemoveAllSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_0.testGetAndPutIfAbsent
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_52.testPutxIfAbsentAsyncOldNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_73.testWithSkipStoreRemoveAll
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_24.testWithSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_0.testRemoveAllSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_87.testWithSkipStoreRemoveAll
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_38.testWithSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_52.testGetAndPutIfAbsent
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_28.testPutxIfAbsentAsyncNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_4.testWithSkipStoreRemoveAll
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_76.testWithSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_52.testRemoveAllSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_28.testPutxIfAbsentAsyncOldNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_73.testPutxIfAbsentAsyncNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_49.testWithSkipStoreRemoveAll
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_0.testWithSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_87.testPutxIfAbsentAsyncNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_63.testWithSkipStoreRemoveAll
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_14.testWithSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_73.testRemoveAllSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_28.testGetAndPutIfAbsent
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_4.testPutxIfAbsentAsyncNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_52.testWithSkipStore
* InterceptorCacheConfigVariationsFullApiTestSuite: 
InterceptorCacheConfigVariationsFullApiTest_73.testPutxIfAbsentAsyncOldNoTx
* InterceptorCacheConfigVariationsFullApiTestSuite:

[jira] [Commented] (IGNITE-11916) reorder fields for GridQueryKillResponse and GridQueryKillRequest

2019-06-17 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-11916:


{panel:title=-- Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 TIMEOUT 
|https://ci.ignite.apache.org/viewLog.html?buildId=4140578]]

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4112673buildTypeId=IgniteTests24Java8_RunAll]

> reorder fields for GridQueryKillResponse and GridQueryKillRequest
> -
>
> Key: IGNITE-11916
> URL: https://issues.apache.org/jira/browse/IGNITE-11916
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> need to reorder all fields for GridQueryKillResponse and GridQueryKillRequest 
> messages using MessageCodeGenerator to have right order of fields to avoid 
> upgrade issues.



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

[jira] [Updated] (IGNITE-11932) Follow ASF crypto process, declare encryption software usages

2019-06-17 Thread Dmitriy Pavlov (JIRA) 


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

Dmitriy Pavlov updated IGNITE-11932:

Summary: Follow ASF crypto process, declare encryption software usages  
(was: Follow ASF crypto process, declare encryption software usaged)

> Follow ASF crypto process, declare encryption software usages
> -
>
> Key: IGNITE-11932
> URL: https://issues.apache.org/jira/browse/IGNITE-11932
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> https://www.apache.org/dev/crypto.html
> We need to update
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
> And inform users by including crypto notice



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

[jira] [Created] (IGNITE-11932) Follow ASF crypto process, declare encryption software usaged

2019-06-17 Thread Dmitriy Pavlov (JIRA) 
Dmitriy Pavlov created IGNITE-11932:
---

 Summary: Follow ASF crypto process, declare encryption software 
usaged
 Key: IGNITE-11932
 URL: https://issues.apache.org/jira/browse/IGNITE-11932
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


https://www.apache.org/dev/crypto.html

We need to update
https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml

And inform users by including crypto notice



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

[jira] [Commented] (IGNITE-11914) Failures to deserialize discovery data should be handled by a failure handler

2019-06-17 Thread Ivan Bessonov (JIRA) 


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

Ivan Bessonov commented on IGNITE-11914:


Hi [~dmekhanikov], you said that "Test is attached." but I see no attachments. 
Can you please provide one? Thank you!

> Failures to deserialize discovery data should be handled by a failure handler
> -
>
> Key: IGNITE-11914
> URL: https://issues.apache.org/jira/browse/IGNITE-11914
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7.5
>Reporter: Denis Mekhanikov
>Priority: Major
>
> When a node during join receives a discovery data packet, that it cannot 
> deserialize, then this error is printed to log and not handled in any way. It 
> leads to swallowing potentially important failures.
> For example, a failure to deserialize a continuous query remote filter should 
> be propagated to a failure handler, but it doesn't happen. Test is attached.
> Error message:
> {noformat}
> Failed to unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to find class with 
> given class loader for unmarshalling (make sure same versions of all classes 
> are available on all nodes or enable peer-class-loading) 
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2, 
> cls=org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory]
>   at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:146)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshalZip(IgniteUtils.java:10068)
>   at 
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:292)
>   at 
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalGridData(DiscoveryDataPacket.java:154)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2065)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4882)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2964)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2696)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7527)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2818)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7458)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:61)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8672)
>   at 
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
>   at 
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1863)
>   at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1746)
>   at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2037)
>   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
>   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.readExternal(CacheContinuousQueryHandlerV2.java:179)
>   at 
> java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2113)
>   at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2062)
>   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
>   at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2282)
>   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2206)
>   at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2064)
>   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
>   at

[jira] [Resolved] (IGNITE-11930) TcpDiscoverySpi does not close bound server socket if discovery thread did not start

2019-06-17 Thread Alexey Goncharuk (JIRA) 


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

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

> TcpDiscoverySpi does not close bound server socket if discovery thread did 
> not start
> 
>
> Key: IGNITE-11930
> URL: https://issues.apache.org/jira/browse/IGNITE-11930
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> See {{ServerImpl.spiStop0(boolean)}}. If the worker did not start, 
> {{U.cancel()}} has no effect because runner field is not initialized, and 
> server socket is closed in {{onInterrupted()}} method, which is called from 
> the {{interrupt()}} method on the worker thread.
> This results in the server socket not being closed and may lead to tests 
> hang, for example, in .NET tests.



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

[jira] [Updated] (IGNITE-11918) extend test coverage for KILL QUERY

2019-06-17 Thread Pavel Kuznetsov (JIRA) 


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

Pavel Kuznetsov updated IGNITE-11918:
-
Component/s: sql

> extend test coverage for KILL QUERY
> ---
>
> Key: IGNITE-11918
> URL: https://issues.apache.org/jira/browse/IGNITE-11918
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have implemented KILL QUERY COMMAND. However not all cases 
> covered by tests and probably it doesn't work properly for all cases.
> On first look need to add following test scenarios for KILL QUERY command:
> 1) not stable topology - when node couldn't reserve partitions.
> 2) map and reduce parts
> 3) with concrete partition
> 4) when partition pruning is work.
> 5) local query
> 6) distributed joins.



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

[jira] [Updated] (IGNITE-11918) extend test coverage for KILL QUERY

2019-06-17 Thread Pavel Kuznetsov (JIRA) 


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

Pavel Kuznetsov updated IGNITE-11918:
-
Labels: test  (was: )

> extend test coverage for KILL QUERY
> ---
>
> Key: IGNITE-11918
> URL: https://issues.apache.org/jira/browse/IGNITE-11918
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: test
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have implemented KILL QUERY COMMAND. However not all cases 
> covered by tests and probably it doesn't work properly for all cases.
> On first look need to add following test scenarios for KILL QUERY command:
> 1) not stable topology - when node couldn't reserve partitions.
> 2) map and reduce parts
> 3) with concrete partition
> 4) when partition pruning is work.
> 5) local query
> 6) distributed joins.



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

[jira] [Commented] (IGNITE-11918) extend test coverage for KILL QUERY

2019-06-17 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-11918:


{panel:title=-- Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests 1 TIMEOUT 
|https://ci.ignite.apache.org/viewLog.html?buildId=4118701]]

{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=4118729]]

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4118730buildTypeId=IgniteTests24Java8_RunAll]

> extend test coverage for KILL QUERY
> ---
>
> Key: IGNITE-11918
> URL: https://issues.apache.org/jira/browse/IGNITE-11918
> Project: Ignite
>  Issue Type: Test
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have implemented KILL QUERY COMMAND. However not all cases 
> covered by tests and probably it doesn't work properly for all cases.
> On first look need to add following test scenarios for KILL QUERY command:
> 1) not stable topology - when node couldn't reserve partitions.
> 2) map and reduce parts
> 3) with concrete partition
> 4) when partition pruning is work.
> 5) local query
> 6) distributed joins.



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

[jira] [Commented] (IGNITE-11918) extend test coverage for KILL QUERY

2019-06-17 Thread Pavel Kuznetsov (JIRA) 


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

Pavel Kuznetsov commented on IGNITE-11918:
--

updated code style https://ci.ignite.apache.org/viewLog.html?buildId=4140336;

> extend test coverage for KILL QUERY
> ---
>
> Key: IGNITE-11918
> URL: https://issues.apache.org/jira/browse/IGNITE-11918
> Project: Ignite
>  Issue Type: Test
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have implemented KILL QUERY COMMAND. However not all cases 
> covered by tests and probably it doesn't work properly for all cases.
> On first look need to add following test scenarios for KILL QUERY command:
> 1) not stable topology - when node couldn't reserve partitions.
> 2) map and reduce parts
> 3) with concrete partition
> 4) when partition pruning is work.
> 5) local query
> 6) distributed joins.



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

[jira] [Commented] (IGNITE-11930) TcpDiscoverySpi does not close bound server socket if discovery thread did not start

2019-06-17 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-11930:


{panel:title=-- Run :: All: No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4138760buildTypeId=IgniteTests24Java8_RunAll]

> TcpDiscoverySpi does not close bound server socket if discovery thread did 
> not start
> 
>
> Key: IGNITE-11930
> URL: https://issues.apache.org/jira/browse/IGNITE-11930
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> See {{ServerImpl.spiStop0(boolean)}}. If the worker did not start, 
> {{U.cancel()}} has no effect because runner field is not initialized, and 
> server socket is closed in {{onInterrupted()}} method, which is called from 
> the {{interrupt()}} method on the worker thread.
> This results in the server socket not being closed and may lead to tests 
> hang, for example, in .NET tests.



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

[jira] [Updated] (IGNITE-11931) Rewrite @WithSystemProperty handling using JUnit rules.

2019-06-17 Thread Ivan Bessonov (JIRA) 


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

Ivan Bessonov updated IGNITE-11931:
---
Description: @WithSystemProperty can only be used in classes that inherit 
GridAbstractTest. This should be changed.

> Rewrite @WithSystemProperty handling using JUnit rules.
> ---
>
> Key: IGNITE-11931
> URL: https://issues.apache.org/jira/browse/IGNITE-11931
> Project: Ignite
>  Issue Type: Test
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 3.0
>
>
> @WithSystemProperty can only be used in classes that inherit 
> GridAbstractTest. This should be changed.



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

[jira] [Created] (IGNITE-11931) Rewrite @WithSystemProperty handling using JUnit rules.

2019-06-17 Thread Ivan Bessonov (JIRA) 
Ivan Bessonov created IGNITE-11931:
--

 Summary: Rewrite @WithSystemProperty handling using JUnit rules.
 Key: IGNITE-11931
 URL: https://issues.apache.org/jira/browse/IGNITE-11931
 Project: Ignite
  Issue Type: Test
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
 Fix For: 3.0






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

[jira] [Assigned] (IGNITE-9949) MVCC TX: Scan query can return wrong result on unstable topology

2019-06-17 Thread Andrew Mashenkov (JIRA) 


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

Andrew Mashenkov reassigned IGNITE-9949:


Assignee: (was: Andrew Mashenkov)

> MVCC TX: Scan query can return wrong result on unstable topology
> 
>
> Key: IGNITE-9949
> URL: https://issues.apache.org/jira/browse/IGNITE-9949
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
>  Labels: mvcc_stability, transactions
> Fix For: 2.8
>
>
> Scan query map nodes do not take into account topology version when filtering 
> primary partitions. See method {{GridCacheQueryManager#scanIterator}} - each 
> node takes it's current topology version. This causes wrong partition 
> filtering results.
> To fix this problem the single topology version should be taken on reduce 
> node propagated to map nodes.



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

[jira] [Assigned] (IGNITE-10550) MVCC: rework IgniteWalFlush* tests for mvcc.

2019-06-17 Thread Andrew Mashenkov (JIRA) 


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

Andrew Mashenkov reassigned IGNITE-10550:
-

Assignee: (was: Andrew Mashenkov)

> MVCC: rework IgniteWalFlush* tests for mvcc.
> 
>
> Key: IGNITE-10550
> URL: https://issues.apache.org/jira/browse/IGNITE-10550
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, mvcc
>Reporter: Andrew Mashenkov
>Priority: Major
>  Labels: WAL
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Next tests failed in mvcc mode, most likely due to different MVCC tx semantic:
>  * IgniteWalFlushBackgroundSelfTest
>  * IgniteWalFlushBackgroundWithMmapBufferSelfTest
>  * IgniteWalFlushFsyncSelfTest
>  * IgniteWalFlushFsyncWithDedicatedWorkerSelfTest
>  * IgniteWalFlushFsyncWithMmapBufferSelfTest
>  * IgniteWalFlushLogOnlySelfTest
>  * IgniteWalFlushLogOnlyWithMmapBufferSelfTest
> We have to create similar tests for mvcc mode.



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

[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-06-17 Thread Ivan Pavlukhin (JIRA) 


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

Ivan Pavlukhin commented on IGNITE-10973:
-

[~ivanan.fed], yes TC bot needs several runs to accumulate statistics for 
unknown tests. Such behavior can be observed when some test class moves to 
another package. It is very likely that merging your branch with fresh master 
will help here.

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



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

[jira] [Comment Edited] (IGNITE-11584) Implement batch insertion of new cache entries in FreeList to improve rebalancing

2019-06-17 Thread Pavel Pereslegin (JIRA) 


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

Pavel Pereslegin edited comment on IGNITE-11584 at 6/17/19 9:40 AM:


Results of microbenchmarks.
Environment: Linux, 16Gb Ram, Core i7 8700
Config: memory page size - 4096 bytes.

1.{{CacheFreeList.insertDataRow()}} vs {{CacheFreeList.insertDataRows()}}.
Source code: 
[https://github.com/apache/ignite/blob/b266bba3d1ae9d39b4b39ef38f4c56d1319da063/modules/benchmarks/src/main/java/org/apache/ignite/internal/benchmarks/jmh/pagemem/JmhCacheFreelistBenchmark.java]
Benchmark measures the time required to insert 100 data rows of different sizes 
(the size does not include object overhead ~40 bytes).
||size (bytes)|*4 - 64*|*100-300*|*300-700*|*700 - 1200*|*1200 - 3000*| 
|*1000 - 8000*|*4000 - 16000*|*100 - 32000*|
||single (μs)|162.3 ^± 4.2^|140.7  ^± 1.2^|159.9  ^± 4.6^|175.2  ^± 1.6^|239.8  
^± 2.3^| |422.3  ^± 5.7^|867.9  ^± 89.3^|1287.0  ^± 55.8^|
||batch (μs)|28.0  ^± 0.9^|43.4  ^± 0.4^|74.6  ^± 0.7^|115.8  ^± 2.0^|232.9  ^± 
5.7^| |398.5  ^± 8.6^|794.6  ^± 8.7^|1209.0  ^± 20.9^|

2. Comparison of preloading performance (master branch vs patch branch).
Source code: 
[https://gist.github.com/xtern/4a4699efd06f147df2b7b342169aee0d#file-jmhbatchupdatesinpreloadbenchmark-java]
Benchmark measures the time required for handling one supply message with 100 
objects of different sizes (the size does not include object overhead ~40 
bytes).
||size (bytes)|*4 - 64*|*100-300*|*300-700*|*700 - 1200*|*1200 - 3000*| 
|*1000 - 8000*|*4000 - 16000*| *100 - 32000*|
||master(μs)|198.7  ^± 7.2^|205.7  ^± 10.0^|213.3  ^± 17.4^|243.4  ^± 
31.7^|261.2  ^± 10.6^| |371.8  ^± 13.5^|639.5  ^± 36.4^|914.5  ^± 85.5^|
||patch (μs)|121.9  ^± 4.1^|141.3  ^± 23.0^|155.3  ^± 15.8^|178.7  ^± 
21.4^|241.2  ^± 6.3^| |359.1  ^± 31.3^|637.3  ^± 145.7^|898.6  ^± 81.6^|

Free list benchmark shows that performance increases in cases when the memory 
page has enough free space to store more than one object.
The performance boost in preloading is significantly lower since this process 
involves more overhead. Real life rebalancing speedup will be even less.


was (Author: xtern):
Results of microbenchmarks.
Environment: Linux, 16Gb Ram, Core i7 8700
Config: memory page size - 4096 bytes.

1.{{CacheFreeList.insertDataRow()}} vs {{CacheFreeList.insertDataRows()}}.
Source code: 
[https://github.com/apache/ignite/blob/b266bba3d1ae9d39b4b39ef38f4c56d1319da063/modules/benchmarks/src/main/java/org/apache/ignite/internal/benchmarks/jmh/pagemem/JmhCacheFreelistBenchmark.java]
Benchmark measures the time required to insert 100 data rows of different sizes 
(the size does not include object overhead ~40 bytes).
||size (bytes)|*4 - 64*|*100-300*|*300-700*|*700 - 1200*|*1200 - 3000*| 
|*1000 - 8000*|*4000 - 16000*|*100 - 32000*|
||single (μs)|162.3 ^± 4.2^|140.7  ^± 1.2^|159.9  ^± 4.6^|175.2  ^± 1.6^|239.8  
^± 2.3^| |422.3  ^± 5.7^|867.9  ^± 89.3^|1287.0  ^± 55.8^|
||batch (μs)|28.0  ^± 0.9^|43.4  ^± 0.4^|74.6  ^± 0.7^|115.8  ^± 2.0^|232.9  ^± 
5.7^| |398.5  ^± 8.6^|794.6  ^± 8.7^|1209.0  ^± 20.9^|

Performance increases in cases where we can write multiple objects at once to 
one memory page. Those. in cases where free space on the memory page allows to 
store more than one object.

2. Comparison of preloading performance (master branch vs patch branch).
Source code: 
[https://gist.github.com/xtern/4a4699efd06f147df2b7b342169aee0d#file-jmhbatchupdatesinpreloadbenchmark-java]
Benchmark measures the time required for handling one supply message with 100 
objects of different sizes (the size does not include object overhead ~40 
bytes).
||size (bytes)|*4 - 64*|*100-300*|*300-700*|*700 - 1200*|*1200 - 3000*| 
|*1000 - 8000*|*4000 - 16000*| *100 - 32000*|
||master(μs)|198.7  ^± 7.2^|205.7  ^± 10.0^|213.3  ^± 17.4^|243.4  ^± 
31.7^|261.2  ^± 10.6^| |371.8  ^± 13.5^|639.5  ^± 36.4^|914.5  ^± 85.5^|
||patch (μs)|121.9  ^± 4.1^|141.3  ^± 23.0^|155.3  ^± 15.8^|178.7  ^± 
21.4^|241.2  ^± 6.3^| |359.1  ^± 31.3^|637.3  ^± 145.7^|898.6  ^± 81.6^|


> Implement batch insertion of new cache entries in FreeList to improve 
> rebalancing
> -
>
> Key: IGNITE-11584
> URL: https://issues.apache.org/jira/browse/IGNITE-11584
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-32
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Main goals:
>  * Implement batch insert operation into FreeList - insert several data rows 
> at once
>  * Use batch insertion in the preloader
>   
> Implementation

[jira] [Resolved] (IGNITE-6809) Use MPSC queue in striped pool

2019-06-17 Thread Igor Seliverstov (JIRA) 


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

Igor Seliverstov resolved IGNITE-6809.
--
Resolution: Won't Do

The ticket is closed since several MPSC queue implementations in striped pools 
don't bring expected performance improvements.

Unlike JMH microbenchmarks show 2 times better throughput the overall picture 
is even worse because MPSC queues bring improvements only on massive tasks 
stream when the stripe acts almost without parking, that's really rare case. On 
sparse workload (usual case) the MPSC queue works almost the same way as jdk's 
concurrent linked queue but with additional parkings (there is no spin as it 
did in current stripes implementations).

Seems the change is premature and it makes sense to put efforts into 
improvement of other system parts.



> Use MPSC queue in striped pool
> --
>
> Key: IGNITE-6809
> URL: https://issues.apache.org/jira/browse/IGNITE-6809
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
>  Labels: performance
> Attachments: [IGNITE-6809]_Use_MPSC_queue_in_striped_pool_.patch
>
>
> Use MPSC queue in striped pool
> Let's start from [MP-SC concurrent linked queue implementation based on 
> Dmitry 
> Vyukov's|http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue]



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

[jira] [Comment Edited] (IGNITE-11584) Implement batch insertion of new cache entries in FreeList to improve rebalancing

2019-06-17 Thread Pavel Pereslegin (JIRA) 


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

Pavel Pereslegin edited comment on IGNITE-11584 at 6/17/19 9:02 AM:


Results of microbenchmarks.
Environment: Linux, 16Gb Ram, Core i7 8700
Config: memory page size - 4096 bytes.

1.{{CacheFreeList.insertDataRow()}} vs {{CacheFreeList.insertDataRows()}}.
Source code: 
[https://github.com/apache/ignite/blob/b266bba3d1ae9d39b4b39ef38f4c56d1319da063/modules/benchmarks/src/main/java/org/apache/ignite/internal/benchmarks/jmh/pagemem/JmhCacheFreelistBenchmark.java]
Benchmark measures the time required to insert 100 data rows of different sizes 
(the size does not include object overhead ~40 bytes).
||size (bytes)|*4 - 64*|*100-300*|*300-700*|*700 - 1200*|*1200 - 3000*| 
|*1000 - 8000*|*4000 - 16000*|*100 - 32000*|
||single (μs)|162.3 ^± 4.2^|140.7  ^± 1.2^|159.9  ^± 4.6^|175.2  ^± 1.6^|239.8  
^± 2.3^| |422.3  ^± 5.7^|867.9  ^± 89.3^|1287.0  ^± 55.8^|
||batch (μs)|28.0  ^± 0.9^|43.4  ^± 0.4^|74.6  ^± 0.7^|115.8  ^± 2.0^|232.9  ^± 
5.7^| |398.5  ^± 8.6^|794.6  ^± 8.7^|1209.0  ^± 20.9^|

Performance increases in cases where we can write multiple objects at once to 
one memory page. Those. in cases where free space on the memory page allows to 
store more than one object.

2. Comparison of preloading performance (master branch vs patch branch).
Source code: 
[https://gist.github.com/xtern/4a4699efd06f147df2b7b342169aee0d#file-jmhbatchupdatesinpreloadbenchmark-java]
Benchmark measures the time required for handling one supply message with 100 
objects of different sizes (the size does not include object overhead ~40 
bytes).
||size (bytes)|*4 - 64*|*100-300*|*300-700*|*700 - 1200*|*1200 - 3000*| 
|*1000 - 8000*|*4000 - 16000*| *100 - 32000*|
||master(μs)|198.7  ^± 7.2^|205.7  ^± 10.0^|213.3  ^± 17.4^|243.4  ^± 
31.7^|261.2  ^± 10.6^| |371.8  ^± 13.5^|639.5  ^± 36.4^|914.5  ^± 85.5^|
||patch (μs)|121.9  ^± 4.1^|141.3  ^± 23.0^|155.3  ^± 15.8^|178.7  ^± 
21.4^|241.2  ^± 6.3^| |359.1  ^± 31.3^|637.3  ^± 145.7^|898.6  ^± 81.6^|



was (Author: xtern):
Results of microbenchmarking.
 Environment: Linux, 16Gb Ram, Core i7 8700
 Config: 4096 bytes page size.

1.{{CacheFreeList.insertDataRow()}} vs {{CacheFreeList.insertDataRows()}}.
 Source code: 
[https://github.com/apache/ignite/blob/b266bba3d1ae9d39b4b39ef38f4c56d1319da063/modules/benchmarks/src/main/java/org/apache/ignite/internal/benchmarks/jmh/pagemem/JmhCacheFreelistBenchmark.java]
 Benchmark measures the time required to insert 100 data rows of different 
sizes (the size does not include object overhead ~40 bytes).
||size (bytes)|*4 - 64*|*100-300*|*300-700*|*700 - 1200*|*1200 - 3000*| 
|*1000 - 8000*|*4000 - 16000*|*100 - 32000*|
||single (μs)|162.3 ^± 4.2^|140.7  ^± 1.2^|159.9  ^± 4.6^|175.2  ^± 1.6^|239.8  
^± 2.3^| |422.3  ^± 5.7^|867.9  ^± 89.3^|1287.0  ^± 55.8^|
||batch (μs)|28.0  ^± 0.9^|43.4  ^± 0.4^|74.6  ^± 0.7^|115.8  ^± 2.0^|232.9  ^± 
5.7^| |398.5  ^± 8.6^|794.6  ^± 8.7^|1209.0  ^± 20.9^|

2. Comparison of preloading performance (master branch vs patch branch).
 Source code: 
[https://gist.github.com/xtern/4a4699efd06f147df2b7b342169aee0d#file-jmhbatchupdatesinpreloadbenchmark-java]
 Benchmark measures the time required for handling one supply message with 100 
objects of different sizes (the size does not include object overhead ~40 
bytes).
||size (bytes)|*4 - 64*|*100-300*|*300-700*|*700 - 1200*|*1200 - 3000*| 
|*1000 - 8000*|*4000 - 16000*| *100 - 32000*|
||master(μs)|198.7  ^± 7.2^|205.7  ^± 10.0^|213.3  ^± 17.4^|243.4  ^± 
31.7^|261.2  ^± 10.6^| |371.8  ^± 13.5^|639.5  ^± 36.4^|914.5  ^± 85.5^|
||patch (μs)|121.9  ^± 4.1^|141.3  ^± 23.0^|155.3  ^± 15.8^|178.7  ^± 
21.4^|241.2  ^± 6.3^| |359.1  ^± 31.3^|637.3  ^± 145.7^|898.6  ^± 81.6^|

> Implement batch insertion of new cache entries in FreeList to improve 
> rebalancing
> -
>
> Key: IGNITE-11584
> URL: https://issues.apache.org/jira/browse/IGNITE-11584
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-32
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Main goals:
>  * Implement batch insert operation into FreeList - insert several data rows 
> at once
>  * Use batch insertion in the preloader
>   
> Implementation notes:
>  # Preloader cannot lock multiple cache entries at once, because this may 
> lead to a deadlock with concurrent batch updates. Therefore, it pre-creates 
> batch of data rows in the page memory, and then sequentially initializes the 
> cache entries one by one.
>  # Batch writing of

[jira] [Commented] (IGNITE-11623) MVCC: testRebalancingDuringLoad_N tests are flacky in master

2019-06-17 Thread Andrew Mashenkov (JIRA) 


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

Andrew Mashenkov commented on IGNITE-11623:
---

Single-threaded tests (like testRebalancingDuringLoad_**_1_1 )  looks ok.
But multi-threaded tests (like testRebalancingDuringLoad_**_8_16) are broken 
and fails on master.
 
Possible reasons:
* Race b/w transactions. New transaction starts before previous one update it's 
state in TxLog.
* Race in Mvcc coordinator. Somehow, vacuum get cleanup version too early.
* Missed TxLog WAL record.
* Vacuum didn't clear rolled back version.


> MVCC: testRebalancingDuringLoad_N tests are flacky in master
> 
>
> Key: IGNITE-11623
> URL: https://issues.apache.org/jira/browse/IGNITE-11623
> Project: Ignite
>  Issue Type: Bug
>Reporter: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> The following tests are flacky in master: 
> IgnitePdsMvccTestSuite3: 
> IgnitePdsContinuousRestartTest.testRebalancingDuringLoad_10_10_1_1 ( [Test 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5373044394008664141=%3Cdefault%3E=testDetails]
>  )
> testRebalancingDuringLoad_1000_2_8_16 ( [Test 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=8776582252343254845=TEST_STATUS_DESC_IgniteTests24Java8=%3Cdefault%3E=50])
> testRebalancingDuringLoad_1000_500_8_1 ([Test 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4172157337542230771=%3Cdefault%3E=testDetails])
> IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
>  ([Test 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4619901385813836807=%3Cdefault%3E=testDetails])
> According to the logs, the cause of the fall: 
> *IgniteTxUnexpectedStateCheckedException: Unexpected state*
> {noformat}
> java.lang.AssertionError: Unexpected exception: javax.cache.CacheException: 
> class org.apache.ignite.transactions.TransactionRollbackException: 
> Transaction has been rolled back: 
> be9b08fa961--09d4-4a7d--0001
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1318)
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2064)
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAll(IgniteCacheProxyImpl.java:1371)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:866)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:280)
>  at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> Caused by: class org.apache.ignite.transactions.TransactionRollbackException: 
> Transaction has been rolled back: 
> be9b08fa961--09d4-4a7d--0001
>  at org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:935)
>  at org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:933)
>  ... 6 more
> Caused by: class 
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException: 
> Transaction has been rolled back: 
> be9b08fa961--09d4-4a7d--0001
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4297)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll0(GridCacheAdapter.java:3000)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2989)
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAll(IgniteCacheProxyImpl.java:1368)
>  ... 3 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
> backup node: [localNodeId=44bb5db4-5317-4ab1-8379-16f3b923, 
> remoteNodeId=08a44c02-ebe8-46e8-a7ca-890c6251]
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:999)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2350)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
>  at 
>

[jira] [Comment Edited] (IGNITE-11908) OOM in MVCC PDS4

2019-06-17 Thread Ivan Pavlukhin (JIRA) 


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

Ivan Pavlukhin edited comment on IGNITE-11908 at 6/17/19 8:32 AM:
--

OOM was stil reproducing after fixing 
{{IgnitePdsCacheWalDisabledOnRebalancingTest.testRebalancedPartitionsOwningWithConcurrentAffinityChange}}
 in scheduled TC RunAll runs. After that it was observed in logs that 
{{IgnitePdsStartWIthEmptyArchive.test}} had been the last test before OOM. It 
was ignored and OOM did not occur after a couple of TC runs.


was (Author: pavlukhin):
OOM was stil reproducing after fixing 
`IgnitePdsCacheWalDisabledOnRebalancingTest.testRebalancedPartitionsOwningWithConcurrentAffinityChange`
 in scheduled TC RunAll runs. After that it was observed in logs that 
`IgnitePdsStartWIthEmptyArchive.test` had been the last test before OOM. It was 
ignored and OOM did not occur after a couple of TC runs.

> OOM in MVCC PDS4 
> -
>
> Key: IGNITE-11908
> URL: https://issues.apache.org/jira/browse/IGNITE-11908
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Almost every time [MVCC PDS 
> 4|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_MvccPds4_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv]
>  fails with OOM. Regular [PDS 
> 4|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds4=buildTypeStatusDiv_IgniteTests24Java8=%3Cdefault%3E]
>  fails as well. Sometimes timeout occurs instead of OOM.



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

[jira] [Updated] (IGNITE-11930) TcpDiscoverySpi does not close bound server socket if discovery thread did not start

2019-06-17 Thread Alexey Goncharuk (JIRA) 


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

Alexey Goncharuk updated IGNITE-11930:
--
Ignite Flags:   (was: Docs Required)

> TcpDiscoverySpi does not close bound server socket if discovery thread did 
> not start
> 
>
> Key: IGNITE-11930
> URL: https://issues.apache.org/jira/browse/IGNITE-11930
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
>
> See {{ServerImpl.spiStop0(boolean)}}. If the worker did not start, 
> {{U.cancel()}} has no effect because runner field is not initialized, and 
> server socket is closed in {{onInterrupted()}} method, which is called from 
> the {{interrupt()}} method on the worker thread.
> This results in the server socket not being closed and may lead to tests 
> hang, for example, in .NET tests.



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

[jira] [Created] (IGNITE-11930) TcpDiscoverySpi does not close bound server socket if discovery thread did not start

2019-06-17 Thread Alexey Goncharuk (JIRA) 
Alexey Goncharuk created IGNITE-11930:
-

 Summary: TcpDiscoverySpi does not close bound server socket if 
discovery thread did not start
 Key: IGNITE-11930
 URL: https://issues.apache.org/jira/browse/IGNITE-11930
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.8


See {{ServerImpl.spiStop0(boolean)}}. If the worker did not start, 
{{U.cancel()}} has no effect because runner field is not initialized, and 
server socket is closed in {{onInterrupted()}} method, which is called from the 
{{interrupt()}} method on the worker thread.

This results in the server socket not being closed and may lead to tests hang, 
for example, in .NET tests.



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