[jira] [Resolved] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM

2020-06-30 Thread Ilya Kasnacheev (Jira)


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

Ilya Kasnacheev resolved IGNITE-13005.
--
Fix Version/s: 2.9
 Release Note: 
Spring Data 2 - "JPA style" and working with multiple Ignite instances on same 
JVM

Support multiple Ignite instances on same JVM (@RepositoryConfig).
Support query tuning parameters in @Query annotation
Support projections
Support Page and Stream responses
Support Sql Fields Query resultset transformation into the domain entity
Support named parameters (:myParam) into SQL queries, declared using 
@Param("myParam")
Support advanced parameter binding and SpEL expressions into SQL queries:
Template variables:
  #entityName - the simple class name of the domain entity
Method parameter expressions: Parameters are exposed for indexed access 
([0] is the first query method's param) or via the name declared using @Param. 
The actual SpEL expression binding is triggered by ?#. Example: ?#{[0] or 
?#{#myParamName}
Advanced SpEL expressions: While advanced parameter binding is a very 
useful feature, the real power of SpEL stems from the fact, that the 
expressions can refer to framework abstractions or other application components 
through SpEL EvaluationContext extension model.
Support SpEL expressions into Text queries (TextQuery).
   Resolution: Fixed

Thank you for this contribution, [~mnusan], I have merged it to master, after a 
few stylistic fixes, removal of instantly deprecated methods, etc. Please make 
sure to document the changes or present them on developers list.

> Spring Data 2 - "JPA style" and working with multiple Ignite instances on 
> same JVM
> --
>
> Key: IGNITE-13005
> URL: https://issues.apache.org/jira/browse/IGNITE-13005
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.7.6, 2.8.1
>Reporter: Manuel Núñez
>Assignee: Manuel Núñez
>Priority: Major
>  Labels: spring-data
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some 
> interesting improvements.
> Code is 100% compatible with previous versions. 
> [https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
>  * Supports multiple ignite instances on same JVM (@RepositoryConfig).
>  * Supports query tuning parameters in {{@Query}} annotation
>  * Supports projections
>  * Supports {{Page}} and {{Stream}} responses
>  * Supports Sql Fields Query resultset transformation into the domain entity
>  * Supports named parameters ({{:myParam}}) into SQL queries, declared using 
> {{@Param("myParam")}}
>  * Supports advanced parameter binding and SpEL expressions into SQL queries:
>  ** *Template variables*:
>  *** {{#entityName}} - the simple class name of the domain entity
>  ** *Method parameter expressions*: Parameters are exposed for indexed access 
> ({{[0]}} is the first query method's param) or via the name declared using 
> {{@Param}}. The actual SpEL expression binding is triggered by {{?#}}. 
> Example: {{?#\{[0]\}} or {{?#\{#myParamName\}}}
>  ** *Advanced SpEL expressions*: While advanced parameter binding is a very 
> useful feature, the real power of SpEL stems from the fact, that the 
> expressions can refer to framework abstractions or other application 
> components through SpEL EvaluationContext extension model.
>  * Supports SpEL expressions into Text queries ({{TextQuery}}). 
> Some examples:
> {code:java}
> // Spring Data Repositories using different ignite instances on same JVM
> @RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
> public interface FlightRouteRepository extends IgniteRepository String> {
> ...
> }
> @RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
> public interface PoiRepository extends IgniteRepository {
> ...
> }
> {code}
> {code:java}
> // named parameter
> @Query(value = "SELECT * from #{#entityName} where email = :email")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // indexed parameters
> @Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city 
> = ?#{[1]}")
> List searchUsersByCity(@Param("country") String country, @Param("city") 
> String city, Pageable pageable);
> {code}
> {code:java}
> // ordered method parameters
> @Query(value = "SELECT * from #{#entityName} where email = ?")
> User searchUserByEmail(String email);
> {code}
> {code:java}
> // Advanced SpEL expressions
> @Query(value = "SELECT * from #{#entityName} where uuidCity = 
> ?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
> List searchUsersByCity(@Param("city") String city, Pageable pageable);
> 

[jira] [Updated] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM

2020-06-30 Thread Ilya Kasnacheev (Jira)


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

Ilya Kasnacheev updated IGNITE-13005:
-
Ignite Flags: Docs Required  (was: Docs Required,Release Notes Required)

> Spring Data 2 - "JPA style" and working with multiple Ignite instances on 
> same JVM
> --
>
> Key: IGNITE-13005
> URL: https://issues.apache.org/jira/browse/IGNITE-13005
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.7.6, 2.8.1
>Reporter: Manuel Núñez
>Assignee: Manuel Núñez
>Priority: Major
>  Labels: spring-data
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some 
> interesting improvements.
> Code is 100% compatible with previous versions. 
> [https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
>  * Supports multiple ignite instances on same JVM (@RepositoryConfig).
>  * Supports query tuning parameters in {{@Query}} annotation
>  * Supports projections
>  * Supports {{Page}} and {{Stream}} responses
>  * Supports Sql Fields Query resultset transformation into the domain entity
>  * Supports named parameters ({{:myParam}}) into SQL queries, declared using 
> {{@Param("myParam")}}
>  * Supports advanced parameter binding and SpEL expressions into SQL queries:
>  ** *Template variables*:
>  *** {{#entityName}} - the simple class name of the domain entity
>  ** *Method parameter expressions*: Parameters are exposed for indexed access 
> ({{[0]}} is the first query method's param) or via the name declared using 
> {{@Param}}. The actual SpEL expression binding is triggered by {{?#}}. 
> Example: {{?#\{[0]\}} or {{?#\{#myParamName\}}}
>  ** *Advanced SpEL expressions*: While advanced parameter binding is a very 
> useful feature, the real power of SpEL stems from the fact, that the 
> expressions can refer to framework abstractions or other application 
> components through SpEL EvaluationContext extension model.
>  * Supports SpEL expressions into Text queries ({{TextQuery}}). 
> Some examples:
> {code:java}
> // Spring Data Repositories using different ignite instances on same JVM
> @RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
> public interface FlightRouteRepository extends IgniteRepository String> {
> ...
> }
> @RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
> public interface PoiRepository extends IgniteRepository {
> ...
> }
> {code}
> {code:java}
> // named parameter
> @Query(value = "SELECT * from #{#entityName} where email = :email")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // indexed parameters
> @Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city 
> = ?#{[1]}")
> List searchUsersByCity(@Param("country") String country, @Param("city") 
> String city, Pageable pageable);
> {code}
> {code:java}
> // ordered method parameters
> @Query(value = "SELECT * from #{#entityName} where email = ?")
> User searchUserByEmail(String email);
> {code}
> {code:java}
> // Advanced SpEL expressions
> @Query(value = "SELECT * from #{#entityName} where uuidCity = 
> ?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
> List searchUsersByCity(@Param("city") String city, Pageable pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "email: #{#email}")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "#{#textToSearch}")
> List searchUsersByText(@Param("textToSearch") String text, Pageable 
> pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL indexed parameter
> @Query(textQuery = true, value = "#{[0]}")
> List searchUsersByText(String textToSearch, Pageable pageable);
> {code}
> {code:java}
> // Static Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e 
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled = 
> :disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
> List searchMerchantsByOrigin(@Param("origin") String origin, 
> @Param("disabled") boolean disabled);
> {code}
> {code:java}
> // Dynamic Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e 
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled = 
> :disabled GROUP BY m.id, 

[jira] [Commented] (IGNITE-13016) Fix backward checking of failed node.

2020-06-30 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-13016:


{panel:title=Branch: [pull/7838/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7838/head] Base: [master] : New Tests 
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=63e53550371-b7bbaed4-9174-4bd0-832e-86bb88791e4f, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=f8d1a9be-a5ec-4dee-8c71-dbb945007756, topVer=0, nodeId8=f8d1a9be, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593522216498]], 
val2=AffinityTopologyVersion [topVer=479273715644047619, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=d429993e-eff2-4659-bdf9-4bed09fca199, topVer=0, 
nodeId8=1eff0d87, msg=, type=NODE_JOINED, tstamp=1593522216498], 
val2=AffinityTopologyVersion [topVer=4418461583898486663, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=d429993e-eff2-4659-bdf9-4bed09fca199, topVer=0, 
nodeId8=1eff0d87, msg=, type=NODE_JOINED, tstamp=1593522216498], 
val2=AffinityTopologyVersion [topVer=4418461583898486663, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=63e53550371-b7bbaed4-9174-4bd0-832e-86bb88791e4f, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=f8d1a9be-a5ec-4dee-8c71-dbb945007756, topVer=0, nodeId8=f8d1a9be, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593522216498]], 
val2=AffinityTopologyVersion [topVer=479273715644047619, minorTopVer=0]]] - 
PASSED{color}

{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=ac7fbe8c-3709-480f-8a9b-a17e9cb4e307, topVer=0, 
nodeId8=5a4dfb3a, msg=, type=NODE_JOINED, tstamp=1593522268422], 
val2=AffinityTopologyVersion [topVer=1174591130455611368, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=ac7fbe8c-3709-480f-8a9b-a17e9cb4e307, topVer=0, 
nodeId8=5a4dfb3a, msg=, type=NODE_JOINED, tstamp=1593522268422], 
val2=AffinityTopologyVersion [topVer=1174591130455611368, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=d6a6e550371-c62106f4-0bc0-4061-b0c1-735533169ef7, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=90c60780-81e5-40b9-ae84-eb7166a59ae5, topVer=0, nodeId8=90c60780, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593522268422]], 
val2=AffinityTopologyVersion [topVer=110843890637889783, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=d6a6e550371-c62106f4-0bc0-4061-b0c1-735533169ef7, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=90c60780-81e5-40b9-ae84-eb7166a59ae5, topVer=0, nodeId8=90c60780, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593522268422]], 
val2=AffinityTopologyVersion [topVer=110843890637889783, minorTopVer=0]]] - 
PASSED{color}

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

> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Backward node connection checking looks wierd. What might be improved are:
> 1) Addresses checking could be done in 

[jira] [Commented] (IGNITE-13134) Fix connection recovery timout.

2020-06-30 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-13134:


{panel:title=Branch: [pull/7916/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7916/head] Base: [master] : New Tests 
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=6eb822a1-b32a-4149-9273-413eb92e664b, topVer=0, 
nodeId8=ec89e4e1, msg=, type=NODE_JOINED, tstamp=1593520533016], 
val2=AffinityTopologyVersion [topVer=-3343132531516557717, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=6eb822a1-b32a-4149-9273-413eb92e664b, topVer=0, 
nodeId8=ec89e4e1, msg=, type=NODE_JOINED, tstamp=1593520533016], 
val2=AffinityTopologyVersion [topVer=-3343132531516557717, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=c1ea9350371-706fbee6-06a9-4bae-a2ad-89af0b494fc8, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=3ea027fe-d4e3-4914-90b4-df290a5539d1, topVer=0, nodeId8=3ea027fe, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593520533016]], 
val2=AffinityTopologyVersion [topVer=-8369532400453870823, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=c1ea9350371-706fbee6-06a9-4bae-a2ad-89af0b494fc8, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=3ea027fe-d4e3-4914-90b4-df290a5539d1, topVer=0, nodeId8=3ea027fe, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593520533016]], 
val2=AffinityTopologyVersion [topVer=-8369532400453870823, minorTopVer=0]]] - 
PASSED{color}

{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=93d86e0e-0eab-4113-b634-aadb385bf295, topVer=0, 
nodeId8=20333a37, msg=, type=NODE_JOINED, tstamp=1593520463127], 
val2=AffinityTopologyVersion [topVer=7830610245344139312, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=93d86e0e-0eab-4113-b634-aadb385bf295, topVer=0, 
nodeId8=20333a37, msg=, type=NODE_JOINED, tstamp=1593520463127], 
val2=AffinityTopologyVersion [topVer=7830610245344139312, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=b1d98350371-56a1ba6c-ed7a-41c0-a88b-4d3cb2ad1757, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=719f2044-7c0d-4666-a0f0-dd3a63e0fcb5, topVer=0, nodeId8=719f2044, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593520463127]], 
val2=AffinityTopologyVersion [topVer=9172221598553400288, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=b1d98350371-56a1ba6c-ed7a-41c0-a88b-4d3cb2ad1757, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=719f2044-7c0d-4666-a0f0-dd3a63e0fcb5, topVer=0, nodeId8=719f2044, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593520463127]], 
val2=AffinityTopologyVersion [topVer=9172221598553400288, minorTopVer=0]]] - 
PASSED{color}

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

> Fix connection recovery timout.
> ---
>
> Key: IGNITE-13134
> URL: https://issues.apache.org/jira/browse/IGNITE-13134
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: IGNITE-130134-patch.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If node experiences connection issues it 

[jira] [Commented] (IGNITE-12620) Calcite integration. Index Nested Loop Join/Hash Join

2020-06-30 Thread Igor Seliverstov (Jira)


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

Igor Seliverstov commented on IGNITE-12620:
---

[~agoncharuk],[~amashenkov],[~korlov],[~tledkov-gridgain], guys, please look at

> Calcite integration. Index Nested Loop Join/Hash Join
> -
>
> Key: IGNITE-12620
> URL: https://issues.apache.org/jira/browse/IGNITE-12620
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We may implement the feature the next way:
>  # For each row from left node consume whole dataset from right node
>  # Pass join condition as an argument of request() method of the right node
>  # In case a data source at right is an index scan
>  ## If there is no cursor opened - create a new cursor using bounds from 
> request 
>  ## If there is an existing cursor - just check the cursor was opened using 
> the same condition as passed one.
>  ## After the right node signals EOD consume a next row from left and repeat 
> from p 2.
>  # In case a data source at right is a table scan with huge amount of rows
>  ## If there is no cursor opened - create a new cursor ignoring passed 
> condition
>  ## If there is an existing cursor - just check the cursor was opened using 
> the same condition as passed one.
>  ## After the right node signals EOD consume a next row from left and repeat 
> from p 2.
>  # In case a data source at right is remote / is a table scan with small 
> number of rows/ is a filter node with good enough selectivity
>  ## Create a hash index for a data source
>  ## If there is no cursor opened - create a new cursor using bounds from 
> request 
>  ## If there is an existing cursor - just check the cursor was opened using 
> the same condition as passed one.
>  ## After the right node signals EOD consume a next row from left and repeat 
> from p 2.
>  Consider implementation specifics at optimization time, choose the cheapest 
> variant



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13191) Public-facing API for "waiting for backups on shutdown"

2020-06-30 Thread Vladislav Pyatkov (Jira)


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

Vladislav Pyatkov updated IGNITE-13191:
---
Reviewer: Ivan Rakov

> Public-facing API for "waiting for backups on shutdown"
> ---
>
> Key: IGNITE-13191
> URL: https://issues.apache.org/jira/browse/IGNITE-13191
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We should introduce "should wait for backups on shutdown" flag in Ignition 
> and/or IgniteConfiguration.
> Maybe we should do the same to "cancel compute tasks" flag.
> Also make sure that we can shut down node explicitly, overriding this flag 
> but without JVM termination.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-13191) Public-facing API for "waiting for backups on shutdown"

2020-06-30 Thread Vladislav Pyatkov (Jira)


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

Vladislav Pyatkov reassigned IGNITE-13191:
--

Assignee: Vladislav Pyatkov

> Public-facing API for "waiting for backups on shutdown"
> ---
>
> Key: IGNITE-13191
> URL: https://issues.apache.org/jira/browse/IGNITE-13191
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We should introduce "should wait for backups on shutdown" flag in Ignition 
> and/or IgniteConfiguration.
> Maybe we should do the same to "cancel compute tasks" flag.
> Also make sure that we can shut down node explicitly, overriding this flag 
> but without JVM termination.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-13191) Public-facing API for "waiting for backups on shutdown"

2020-06-30 Thread Vladislav Pyatkov (Jira)


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

Vladislav Pyatkov resolved IGNITE-13191.

Resolution: Fixed

> Public-facing API for "waiting for backups on shutdown"
> ---
>
> Key: IGNITE-13191
> URL: https://issues.apache.org/jira/browse/IGNITE-13191
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We should introduce "should wait for backups on shutdown" flag in Ignition 
> and/or IgniteConfiguration.
> Maybe we should do the same to "cancel compute tasks" flag.
> Also make sure that we can shut down node explicitly, overriding this flag 
> but without JVM termination.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13197) Add ImportOrder rule to checkstyle

2020-06-30 Thread Nikolay Izhikov (Jira)


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

Nikolay Izhikov commented on IGNITE-13197:
--

https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite_IgniteTests24Java8=pull%2F7978%2Fhead=buildTypeStatusDiv

> Add ImportOrder rule to checkstyle
> --
>
> Key: IGNITE-13197
> URL: https://issues.apache.org/jira/browse/IGNITE-13197
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We should add automatic check for check for the import order as specified by 
> the coding guidelines
>  
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-PackageImporting



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13193) Implement fallback to full partition rebalancing in case historical supplier failed to read all necessary data updates from WAL

2020-06-30 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-13193:


{panel:title=Branch: [pull/7971/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7971/head] Base: [master] : New Tests 
(12)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Indexing){color} [tests 4]
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite: 
IgniteWalRebalanceTest.testSwitchHistoricalRebalanceToFullAndClientJoin - 
PASSED{color}
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite: 
IgniteWalRebalanceTest.testMultipleNodesFailHistoricalRebalance - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite: 
IgniteWalRebalanceTest.testSwitchHistoricalRebalanceToFullDueToFailOnCreatingWalIterator
 - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite: 
IgniteWalRebalanceTest.testSwitchHistoricalRebalanceToFullWhileIteratingOverWAL 
- PASSED{color}

{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=d4fb8cb4-f5b4-40c5-aa31-78a86f176a39, topVer=0, 
nodeId8=988d3ef2, msg=, type=NODE_JOINED, tstamp=1593484888764], 
val2=AffinityTopologyVersion [topVer=2250924009422792828, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=d4fb8cb4-f5b4-40c5-aa31-78a86f176a39, topVer=0, 
nodeId8=988d3ef2, msg=, type=NODE_JOINED, tstamp=1593484888764], 
val2=AffinityTopologyVersion [topVer=2250924009422792828, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=0cac9130371-e91bd767-ce93-405f-8c4c-e65a6af284f1, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=f96e45f8-ee71-45c8-b086-4f12b58b4e47, topVer=0, nodeId8=f96e45f8, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593484888764]], 
val2=AffinityTopologyVersion [topVer=6194541553269355410, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=0cac9130371-e91bd767-ce93-405f-8c4c-e65a6af284f1, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=f96e45f8-ee71-45c8-b086-4f12b58b4e47, topVer=0, nodeId8=f96e45f8, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593484888764]], 
val2=AffinityTopologyVersion [topVer=6194541553269355410, minorTopVer=0]]] - 
PASSED{color}

{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=7edce5fc-46de-4493-a2cf-e515e4a06cb3, topVer=0, 
nodeId8=dae95a9e, msg=, type=NODE_JOINED, tstamp=1593485037885], 
val2=AffinityTopologyVersion [topVer=-5513012272294030853, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=7edce5fc-46de-4493-a2cf-e515e4a06cb3, topVer=0, 
nodeId8=dae95a9e, msg=, type=NODE_JOINED, tstamp=1593485037885], 
val2=AffinityTopologyVersion [topVer=-5513012272294030853, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=f9156230371-9f284914-20cf-402c-a951-de72c3dce064, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=3c1ef5dc-b557-424e-84c4-ef739a37e3fb, topVer=0, nodeId8=3c1ef5dc, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593485037885]], 
val2=AffinityTopologyVersion [topVer=4163126190682535866, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=f9156230371-9f284914-20cf-402c-a951-de72c3dce064, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=3c1ef5dc-b557-424e-84c4-ef739a37e3fb, topVer=0, nodeId8=3c1ef5dc, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593485037885]], 
val2=AffinityTopologyVersion [topVer=4163126190682535866, minorTopVer=0]]] - 
PASSED{color}

{panel}
[TeamCity *-- Run :: All* 

[jira] [Updated] (IGNITE-12843) TDE Phase-3. Cache key rotation.

2020-06-30 Thread Pavel Pereslegin (Jira)


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

Pavel Pereslegin updated IGNITE-12843:
--
Description: 
Add the ability to rotate (change) the cache group encryption key.

The design is described here: 
[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription]
h3. Additional notes about binary format changes.
h4. PageMetaIO and PagePartitionMetaIO format

Reencryption status requires an additional 8 bytes on the meta page of each 
partition.
 Index partition uses PageMetaIO to read/write meta information.
 Each other partition uses PagePartitionMetaIO to read/write meta information.

Partition meta starts just after the end of the page meta.
 To store additional 8 bytes partition meta shifted by 8 bytes.

WAL delta records have also been modified to store reencryption status.
h4. Encrypted page format

Each encrypted page has reserved free space to store CRC of encrypted data.
 The size of this free space depends on the size of the encryption block, but 
cannot be less than 8 bytes (Ignite default encryption implementation 
(KeystoreEncryptionSpi) uses AES with 16 bytes block size).

Added 1 byte for encryption key ID on each encrypted page (after CRC).
 (WAL records ENCRYPTED_RECORD and ENCRYPTED_DATA_RECORD have been changed 
accordingly)

  was:
Add the ability to rotate (change) the cache group encryption key.

The design is described here: 
[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription]
h3. Additional notes about binary format changes.
h4. PageMetaIO and PagePartitionMetaIO format

Reencryption status requires an additional 8 bytes on the meta page of each 
partition.
 Index partition uses PageMetaIO to read/write meta information.
 Each other partition uses PagePartitionMetaIO to read/write meta information.

Partition meta starts just after the end of the page meta.
 To store additional 8 bytes partition meta shifted by 8 bytes.

WAL delta records have also been modified to store reencryption status.
h4. Encrypted page format

Each encrypted page has reserved free space to store encrypted page CRC.
 The size of this free space depends on the size of the encryption block, but 
cannot be less than 8 bytes (Ignite default encryption implementation 
(KeystoreEncryptionSpi) uses AES with 16 bytes block size).

Added 1 byte for encryption key ID on each encrypted page (after CRC).
 (WAL records ENCRYPTED_RECORD and ENCRYPTED_DATA_RECORD have been changed 
accordingly)


> TDE Phase-3. Cache key rotation.
> 
>
> Key: IGNITE-12843
> URL: https://issues.apache.org/jira/browse/IGNITE-12843
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: IEP-18
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add the ability to rotate (change) the cache group encryption key.
> The design is described here: 
> [https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription]
> h3. Additional notes about binary format changes.
> h4. PageMetaIO and PagePartitionMetaIO format
> Reencryption status requires an additional 8 bytes on the meta page of each 
> partition.
>  Index partition uses PageMetaIO to read/write meta information.
>  Each other partition uses PagePartitionMetaIO to read/write meta information.
> Partition meta starts just after the end of the page meta.
>  To store additional 8 bytes partition meta shifted by 8 bytes.
> WAL delta records have also been modified to store reencryption status.
> h4. Encrypted page format
> Each encrypted page has reserved free space to store CRC of encrypted data.
>  The size of this free space depends on the size of the encryption block, but 
> cannot be less than 8 bytes (Ignite default encryption implementation 
> (KeystoreEncryptionSpi) uses AES with 16 bytes block size).
> Added 1 byte for encryption key ID on each encrypted page (after CRC).
>  (WAL records ENCRYPTED_RECORD and ENCRYPTED_DATA_RECORD have been changed 
> accordingly)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12843) TDE Phase-3. Cache key rotation.

2020-06-30 Thread Pavel Pereslegin (Jira)


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

Pavel Pereslegin updated IGNITE-12843:
--
Description: 
Add the ability to rotate (change) the cache group encryption key.

The design is described here: 
[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription]
h3. Additional notes about binary format changes.
h4. PageMetaIO and PagePartitionMetaIO format

Reencryption status requires an additional 8 bytes on the meta page of each 
partition.
 Index partition uses PageMetaIO to read/write meta information.
 Each other partition uses PagePartitionMetaIO to read/write meta information.

Partition meta starts just after the end of the page meta.
 To store additional 8 bytes partition meta shifted by 8 bytes.

WAL delta records have also been modified to store reencryption status.
h4. Encrypted page format

Each encrypted page has reserved free space to store encrypted page CRC.
 The size of this free space depends on the size of the encryption block, but 
cannot be less than 8 bytes (Ignite default encryption implementation 
(KeystoreEncryptionSpi) uses AES with 16 bytes block size).

Added 1 byte for encryption key ID on each encrypted page (after CRC).
 (WAL records ENCRYPTED_RECORD and ENCRYPTED_DATA_RECORD have been changed 
accordingly)

  was:
Add the ability to rotate (change) the cache encryption key.

Design described here: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription


> TDE Phase-3. Cache key rotation.
> 
>
> Key: IGNITE-12843
> URL: https://issues.apache.org/jira/browse/IGNITE-12843
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: IEP-18
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add the ability to rotate (change) the cache group encryption key.
> The design is described here: 
> [https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription]
> h3. Additional notes about binary format changes.
> h4. PageMetaIO and PagePartitionMetaIO format
> Reencryption status requires an additional 8 bytes on the meta page of each 
> partition.
>  Index partition uses PageMetaIO to read/write meta information.
>  Each other partition uses PagePartitionMetaIO to read/write meta information.
> Partition meta starts just after the end of the page meta.
>  To store additional 8 bytes partition meta shifted by 8 bytes.
> WAL delta records have also been modified to store reencryption status.
> h4. Encrypted page format
> Each encrypted page has reserved free space to store encrypted page CRC.
>  The size of this free space depends on the size of the encryption block, but 
> cannot be less than 8 bytes (Ignite default encryption implementation 
> (KeystoreEncryptionSpi) uses AES with 16 bytes block size).
> Added 1 byte for encryption key ID on each encrypted page (after CRC).
>  (WAL records ENCRYPTED_RECORD and ENCRYPTED_DATA_RECORD have been changed 
> accordingly)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12843) TDE Phase-3. Cache key rotation.

2020-06-30 Thread Pavel Pereslegin (Jira)


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

Pavel Pereslegin updated IGNITE-12843:
--
Description: 
Add the ability to rotate (change) the cache encryption key.

Design described here: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription

  was:
Add the ability to rotate (change) the cache encryption key.

Initial design: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription


> TDE Phase-3. Cache key rotation.
> 
>
> Key: IGNITE-12843
> URL: https://issues.apache.org/jira/browse/IGNITE-12843
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: IEP-18
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add the ability to rotate (change) the cache encryption key.
> Design described here: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM

2020-06-30 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-13005:


{panel:title=Branch: [pull/7953/head] Base: [master] : Possible Blockers 
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Javadoc]{color} [[tests 0 BuildFailureOnMessage 
|https://ci.ignite.apache.org/viewLog.html?buildId=5429379]]

{panel}
{panel:title=Branch: [pull/7953/head] Base: [master] : New Tests 
(40)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=c445da3a-8244-4fbf-9186-3b4764875704, topVer=0, 
nodeId8=72d54c25, msg=, type=NODE_JOINED, tstamp=1593510964131], 
val2=AffinityTopologyVersion [topVer=1510705476752092510, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=dbce1b40371-0a49957f-5490-4ebf-a115-113aec46a950, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=c1e7260b-ee31-4ad0-9e81-49e1f73f6352, topVer=0, nodeId8=c1e7260b, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593510964131]], 
val2=AffinityTopologyVersion [topVer=-8014184632670024084, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=dbce1b40371-0a49957f-5490-4ebf-a115-113aec46a950, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=c1e7260b-ee31-4ad0-9e81-49e1f73f6352, topVer=0, nodeId8=c1e7260b, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593510964131]], 
val2=AffinityTopologyVersion [topVer=-8014184632670024084, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=c445da3a-8244-4fbf-9186-3b4764875704, topVer=0, 
nodeId8=72d54c25, msg=, type=NODE_JOINED, tstamp=1593510964131], 
val2=AffinityTopologyVersion [topVer=1510705476752092510, minorTopVer=0]]] - 
PASSED{color}

{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=a6911711-fbfb-4be9-adf8-ef6fefbee40f, topVer=0, 
nodeId8=0950ddc5, msg=, type=NODE_JOINED, tstamp=1593510952640], 
val2=AffinityTopologyVersion [topVer=-3553699451018057005, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryEvent [evtNode=a6911711-fbfb-4be9-adf8-ef6fefbee40f, topVer=0, 
nodeId8=0950ddc5, msg=, type=NODE_JOINED, tstamp=1593510952640], 
val2=AffinityTopologyVersion [topVer=-3553699451018057005, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=0fc81b40371-35487610-cab8-4b97-ba20-7cead8a07eaa, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=5b03295a-19bb-40f8-b02f-198ae6b7b19c, topVer=0, nodeId8=5b03295a, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593510952640]], 
val2=AffinityTopologyVersion [topVer=2725426480401865449, minorTopVer=0]]] - 
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite: 
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple 
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest 
[id=0fc81b40371-35487610-cab8-4b97-ba20-7cead8a07eaa, reqs=SingletonList 
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent 
[evtNode=5b03295a-19bb-40f8-b02f-198ae6b7b19c, topVer=0, nodeId8=5b03295a, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593510952640]], 
val2=AffinityTopologyVersion [topVer=2725426480401865449, minorTopVer=0]]] - 
PASSED{color}

{color:#8b}Spring (Data){color} [tests 32]
* {color:#013220}IgniteSpringData22TestSuite: 
IgniteSpringDataCrudSelfTest.testUpdateQueryMixedCaseProjectionIndexedParameter 
- PASSED{color}
* {color:#013220}IgniteSpringData22TestSuite: 
IgniteSpringDataCrudSelfTest.testUpdateQueryOneMixedCaseDynamicProjectionNamedParameter
 - PASSED{color}
* {color:#013220}IgniteSpringData22TestSuite: 
IgniteSpringDataCrudSelfTest.testUpdateQueryMixedCaseDynamicProjectionNamedParameter
 - PASSED{color}
* {color:#013220}IgniteSpringData22TestSuite: 

[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin updated IGNITE-13016:
--
Description: 
Backward node connection checking looks wierd. What might be improved are:

1) Addresses checking could be done in parrallel, not serializably
{code:java}
for (InetSocketAddress addr : nodeAddrs) {
// Connection refused may be got if node doesn't listen
// (or blocked by firewall, but anyway assume it is dead).
if (!isConnectionRefused(addr)) {
liveAddr = addr;

break;
}
}
{code}

2) Any io-exception should be considered as failed connection, not only 
connection-refused:
{code:java}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}
{code}

3) Timeout on connection checking should not be constand or hardcoced:
{code:java}
sock.connect(addr, 100);
{code}

4) Decision to check connection should rely on configured exchange timeout, no 
on the ping interval

{code:java}
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + U.millisToNanos(connCheckInterval) * 2 >= now;
{code}





  was:
Backward node connection checking looks wierd. What might be improved are:

1) Addresses checking could be done in parrallel, not serializably
{code:java}
for (InetSocketAddress addr : nodeAddrs) {
// Connection refused may be got if node doesn't listen
// (or blocked by firewall, but anyway assume it is dead).
if (!isConnectionRefused(addr)) {
liveAddr = addr;

break;
}
}
{code}

2) Any io-exception should be considered as failed connection, not only 
connection-refused:
{code:java}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}
{code}

3) Timeout on connection checking should not be constand or hardcoced:
{code:java}
sock.connect(addr, 100);
{code}





> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Backward node connection checking looks wierd. What might be improved are:
> 1) Addresses checking could be done in parrallel, not serializably
> {code:java}
> for (InetSocketAddress addr : nodeAddrs) {
> // Connection refused may be got if node doesn't listen
> // (or blocked by firewall, but anyway assume it is dead).
> if (!isConnectionRefused(addr)) {
> liveAddr = addr;
> break;
> }
> }
> {code}
> 2) Any io-exception should be considered as failed connection, not only 
> connection-refused:
> {code:java}
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> {code}
> 3) Timeout on connection checking should not be constand or hardcoced:
> {code:java}
> sock.connect(addr, 100);
> {code}
> 4) Decision to check connection should rely on configured exchange timeout, 
> no on the ping interval
> {code:java}
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + U.millisToNanos(connCheckInterval) * 2 >= now;
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12843) TDE Phase-3. Cache key rotation.

2020-06-30 Thread Pavel Pereslegin (Jira)


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

Pavel Pereslegin updated IGNITE-12843:
--
Description: 
Add the ability to rotate (change) the cache encryption key.

Initial design: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription

  was:
Add the ability to rotate (change) the cache encryption key.

Initial design: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384


> TDE Phase-3. Cache key rotation.
> 
>
> Key: IGNITE-12843
> URL: https://issues.apache.org/jira/browse/IGNITE-12843
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: IEP-18
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add the ability to rotate (change) the cache encryption key.
> Initial design: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin updated IGNITE-13016:
--
Description: 
Backward node connection checking looks wierd. What might be improved are:

1) Addresses checking could be done in parrallel, not serializably
{code:java}
for (InetSocketAddress addr : nodeAddrs) {
// Connection refused may be got if node doesn't listen
// (or blocked by firewall, but anyway assume it is dead).
if (!isConnectionRefused(addr)) {
liveAddr = addr;

break;
}
}
{code}

2) Any io-exception should be considered as failed connection, not only 
connection-refused:
{code:java}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}
{code}

3) Timeout on connection checking should not be constand or hardcoced:
{code:java}
sock.connect(addr, 100);
{code}




  was:
We should fix several drawbacks in the backward checking of failed node. They 
prolong node failure detection upto: 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. 

See:
* ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch' 
which emulates long answears on a failed node and measures failure detection 
delays.
* '_FailureDetectionResearch.txt_' - results of the test.
* '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
* '_WostCaseStepByStep.txt_' - description how the worst case happens.


*Suggestions:*

1) We should replace hardcoded timeout 100ms with a parameter like 
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
sock.connect(addr, 100); // Make it rely on failureDetectionTimeout.
   ...
}
{code}

2) Any negative result of the connection checking should be considered as node 
failed. Currently, we look only at refused connection. Any other exceptions, 
including a timeout, are treated as living connection: 

{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
   catch (ConnectException e) {
  return true;
   }
   catch (IOException e) {
  return false; // Make any error mean lost connection.
   }

   return false;
}
{code}

3) Maximal interval to check previous node should rely on actual failure 
detection timeout:
{code:java}
   TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
   ...
   // We got message from previous in less than double connection check 
interval.
   boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a 
timeout of failure detection.

   if (ok) {
  // Check case when previous node suddenly died. This will speed up
  // node failing.
  ...
}

res.previousNodeAlive(ok);
{code}



> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Backward node connection checking looks wierd. What might be improved are:
> 1) Addresses checking could be done in parrallel, not serializably
> {code:java}
> for (InetSocketAddress addr : nodeAddrs) {
> // Connection refused may be got if node doesn't listen
> // (or blocked by firewall, but anyway assume it is dead).
> if (!isConnectionRefused(addr)) {
> liveAddr = addr;
> break;
> }
> }
> {code}
> 2) Any io-exception should be considered as failed connection, not only 
> connection-refused:
> {code:java}
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> {code}
> 3) Timeout on connection checking should not be constand or hardcoced:
> {code:java}
> sock.connect(addr, 100);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin updated IGNITE-13016:
--
Attachment: (was: WostCaseStepByStep.txt)

> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They 
> prolong node failure detection upto: 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout + 300ms. 
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch' 
> which emulates long answears on a failed node and measures failure detection 
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestions:*
> 1) We should replace hardcoded timeout 100ms with a parameter like 
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it rely on failureDetectionTimeout.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as 
> node failed. Currently, we look only at refused connection. Any other 
> exceptions, including a timeout, are treated as living connection: 
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
>   return true;
>}
>catch (IOException e) {
>   return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure 
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check 
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a 
> timeout of failure detection.
>if (ok) {
>   // Check case when previous node suddenly died. This will speed up
>   // node failing.
>   ...
> }
> res.previousNodeAlive(ok);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin updated IGNITE-13016:
--
Attachment: (was: FailureDetectionResearch.txt)

> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: WostCaseStepByStep.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They 
> prolong node failure detection upto: 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout + 300ms. 
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch' 
> which emulates long answears on a failed node and measures failure detection 
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestions:*
> 1) We should replace hardcoded timeout 100ms with a parameter like 
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it rely on failureDetectionTimeout.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as 
> node failed. Currently, we look only at refused connection. Any other 
> exceptions, including a timeout, are treated as living connection: 
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
>   return true;
>}
>catch (IOException e) {
>   return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure 
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check 
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a 
> timeout of failure detection.
>if (ok) {
>   // Check case when previous node suddenly died. This will speed up
>   // node failing.
>   ...
> }
> res.previousNodeAlive(ok);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin updated IGNITE-13016:
--
Attachment: (was: FailureDetectionResearch.patch)

> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: WostCaseStepByStep.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They 
> prolong node failure detection upto: 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout + 300ms. 
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch' 
> which emulates long answears on a failed node and measures failure detection 
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestions:*
> 1) We should replace hardcoded timeout 100ms with a parameter like 
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it rely on failureDetectionTimeout.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as 
> node failed. Currently, we look only at refused connection. Any other 
> exceptions, including a timeout, are treated as living connection: 
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
>   return true;
>}
>catch (IOException e) {
>   return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure 
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check 
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a 
> timeout of failure detection.
>if (ok) {
>   // Check case when previous node suddenly died. This will speed up
>   // node failing.
>   ...
> }
> res.previousNodeAlive(ok);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin updated IGNITE-13016:
--
Attachment: (was: FailureDetectionResearch_fixed.txt)

> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: WostCaseStepByStep.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They 
> prolong node failure detection upto: 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout + 300ms. 
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch' 
> which emulates long answears on a failed node and measures failure detection 
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestions:*
> 1) We should replace hardcoded timeout 100ms with a parameter like 
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it rely on failureDetectionTimeout.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as 
> node failed. Currently, we look only at refused connection. Any other 
> exceptions, including a timeout, are treated as living connection: 
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
>   return true;
>}
>catch (IOException e) {
>   return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure 
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check 
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a 
> timeout of failure detection.
>if (ok) {
>   // Check case when previous node suddenly died. This will speed up
>   // node failing.
>   ...
> }
> res.previousNodeAlive(ok);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13134) Fix connection recovery timout.

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin commented on IGNITE-13134:
---

The patch creates 
{code:java}
JmhNodeFailureDetection
{code}
and
{code:java}
TcpDiscoveryNetworkIssuesTest.testConnectionRecoveryTimeoutSmallValues()
TcpDiscoveryNetworkIssuesTest.testConnectionRecoveryTimeoutMediumValues()
TcpDiscoveryNetworkIssuesTest.testConnectionRecoveryTimeoutLongValues()
{code}

The benchmark shows delay on node segmentation. Expected: 
failureDetectionTimeout + connRecoveryTimeout. 
You can find in the output (example):
Master: Detection delay: *1923*. Failure detection timeout: 1000, connection 
recovery timeout: 500
Fixed: Detection delay: 1408. Failure detection timeout: 1000, connection 
recovery timeout: 500

> Fix connection recovery timout.
> ---
>
> Key: IGNITE-13134
> URL: https://issues.apache.org/jira/browse/IGNITE-13134
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: IGNITE-130134-patch.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If node experiences connection issues it must establish new connection or 
> fail within failureDetectionTimeout + connectionRecoveryTimout.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13134) Fix connection recovery timout.

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin updated IGNITE-13134:
--
Ignite Flags:   (was: Release Notes Required)

> Fix connection recovery timout.
> ---
>
> Key: IGNITE-13134
> URL: https://issues.apache.org/jira/browse/IGNITE-13134
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: IGNITE-130134-patch.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If node experiences connection issues it must establish new connection or 
> fail within failureDetectionTimeout + connectionRecoveryTimout.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13176) C++: Remove autotools build after merging CMake

2020-06-30 Thread Igor Sapego (Jira)


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

Igor Sapego commented on IGNITE-13176:
--

Overall looks good. I added a minor comment in PR though - please take a look

> C++: Remove autotools build after merging CMake
> ---
>
> Key: IGNITE-13176
> URL: https://issues.apache.org/jira/browse/IGNITE-13176
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Trivial
> Fix For: 2.9
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Old autotools build scripts and release steps in {{pom.xml}} should be 
> removed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13191) Public-facing API for "waiting for backups on shutdown"

2020-06-30 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-13191:


{panel:title=Branch: [pull/7970/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7970/head] Base: [master] : New Tests 
(131)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 4{color} [tests 2]
* {color:#013220}IgnitePdsTestSuite4: CircledRebalanceTest.testTwoNodesRestart 
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: CircledRebalanceTest.testOneNodeRestart - 
PASSED{color}

{color:#8b}MVCC Cache 7{color} [tests 39]
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testRollingRestartEmulationWithOnlyHalfNodesInBaseline - 
PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testSimultaneousSafeShutdown - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testReplicatedNodeLeavesImmediately - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testThatItsPossibleToStopNodeIfExludedNodeListWithinMetastoreIsntEmpty
 - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testThatItsNotPossibleToStopLastNodeInBaselineIfThereAreStilNonBaselineNodesInCluster
 - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testTwoNodesWithDifferenConfuguration - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testRestartWithDynamicConfiguredPolicy - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testRestartWithStaticConfiguredPolicy - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testSimultaneousSafeShutdownWithReplicatedCache - 
PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testNodeOnInactiveClusterShouldStopImmediately - 
PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7: 
GracefulShutdownTest.testNodeForceShutdown - PASSED{color}
... and 28 tests blockers

{color:#8b}MVCC PDS 4{color} [tests 2]
* {color:#013220}IgnitePdsMvccTestSuite4: 
CircledRebalanceTest.testTwoNodesRestart - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4: 
CircledRebalanceTest.testOneNodeRestart - PASSED{color}

{color:#8b}ZooKeeper (Discovery) 2{color} [tests 2]
* {color:#013220}ZookeeperDiscoverySpiTestSuite2: 
GridCommandHandlerTest.testShutdownPolicy - PASSED{color}
* {color:#013220}ZookeeperDiscoverySpiTestSuite2: 
GridCommandHandlerTest.testShutdownPolicyChange - PASSED{color}

{color:#8b}Cache 7{color} [tests 39]
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testClientNodeShouldStopImmediately - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testNodeLeavesRebalanceCompletesAtomicReplicated - 
PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testSimultaneousSafeShutdownWithReplicatedCache - 
PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testNodeOnInactiveClusterShouldStopImmediately - 
PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testNodeForceShutdown - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testRollingRestartEmulation - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testNodeLeavesRebalanceCompletesClientNode - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testNodeLeavesRebalanceCompletesTransactionalPartitioned - 
PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testShutdownWithoutBackups - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testThatItsNotPossibleToStopLastOwnerIfAnotherOwnerIsStopping
 - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: 
GracefulShutdownTest.testRestartWithDynamicConfiguredPolicy - PASSED{color}
... and 28 tests blockers

{color:#8b}Cache 2{color} [tests 17]
* {color:#013220}IgniteCacheTestSuite2: 
GridCacheDhtPreloadWaitForBackupsTest.testReplicatedNodeLeavesImmediately - 
PASSED{color}
* {color:#013220}IgniteCacheTestSuite2: 
GridCacheDhtPreloadWaitForBackupsTest.testThatItsNotPossibleToStopLastOwnerIfAnotherOwnerIsStopping
 - PASSED{color}
* {color:#013220}IgniteCacheTestSuite2: 
GridCacheDhtPreloadWaitForBackupsTest.testThatExcludedNodeListWithinMetastoreCleanedUpAfterUpdatingFullMap
 - PASSED{color}
* {color:#013220}IgniteCacheTestSuite2: 
GridCacheDhtPreloadWaitForBackupsTest.testThatItsPossibleToStopNodeIfExludedNodeListWithinMetastoreIsntEmpty
 - PASSED{color}
* {color:#013220}IgniteCacheTestSuite2: 
GridCacheDhtPreloadWaitForBackupsTest.testRollingRestartEmulationReplicatedCache
 - PASSED{color}
* {color:#013220}IgniteCacheTestSuite2: 

[jira] [Updated] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin updated IGNITE-13194:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13194:
---

[~vladsz83], merged to 
[master|https://github.com/apache/ignite/commit/0e385f8883a98c0a9a9e03b715c10363198c8999]

> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13176) C++: Remove autotools build after merging CMake

2020-06-30 Thread Ilya Kasnacheev (Jira)


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

Ilya Kasnacheev commented on IGNITE-13176:
--

[~ivandasch] OK, it looks good from my side, but I'd wait for [~isapego]'s 
opinion.

> C++: Remove autotools build after merging CMake
> ---
>
> Key: IGNITE-13176
> URL: https://issues.apache.org/jira/browse/IGNITE-13176
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Trivial
> Fix For: 2.9
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Old autotools build scripts and release steps in {{pom.xml}} should be 
> removed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-13194 at 6/30/20, 10:17 AM:
--

[~vladsz83], thanks a lot for your patch. I've missed this test.
The patch is OK with me. May be the last *typeId* should be placed according 
with previous parameters (with String.format)


was (Author: tledkov-gridgain):
[~vladsz83], thanks a lot for your patch. I've missed this test.
The patch is OK with me. May me the last *typeId* should be placed according 
with previous parameters (with String.format)

> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13194:
---

[~vladsz83], thanks a lot for your patch. I've missed this test.
The patch is OK with me. May me the last *typeId* should be placed according 
with previous parameters (with String.format)

> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin edited comment on IGNITE-13194 at 6/30/20, 9:29 AM:
-

[~tledkov-gridgain], looks like IGNITE-13154 raised this one. Could you, 
please, take a look. Is the fix correct?


was (Author: vladsz83):
[~tledkov-gridgain], could you, please, take a look. Is the fix correct?

> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin commented on IGNITE-13194:
---

[~tledkov-gridgain], could you, please, take a look. Is the fix correct?

> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin updated IGNITE-13194:
--
Description: 
Test
{code:java}
IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
{code}
fails in master. Changed error message is incorrectly checked in the test. 
Became incorrect in IGNITE-13154.


  was:
Test
{code:java}
IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
{code}
fails in master. Changed error message is incorrectly checked in the test. 
Became incorrect in IGNITE-13154.

[~tledkov-gridgain], could you, please, take a look. Is the fix correct?


> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Vladimir Steshin (Jira)


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

Vladimir Steshin updated IGNITE-13194:
--
Description: 
Test
{code:java}
IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
{code}
fails in master. Changed error message is incorrectly checked in the test. 
Became incorrect in IGNITE-13154.

[~tledkov-gridgain], could you, please, take a look. Is the fix correct?

  was:
Test
{code:java}
IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
{code}
fails in master. Changed error message is incorrectly checked in the test.



> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.
> [~tledkov-gridgain], could you, please, take a look. Is the fix correct?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Anton Vinogradov (Jira)


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

Anton Vinogradov updated IGNITE-13194:
--
Fix Version/s: 2.9

> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-13197) Add ImportOrder rule to checkstyle

2020-06-30 Thread Nikolay Izhikov (Jira)
Nikolay Izhikov created IGNITE-13197:


 Summary: Add ImportOrder rule to checkstyle
 Key: IGNITE-13197
 URL: https://issues.apache.org/jira/browse/IGNITE-13197
 Project: Ignite
  Issue Type: Bug
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov


We should add automatic check for check for the import order as specified by 
the coding guidelines

 

https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-PackageImporting



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13123) Move control.sh to a separate module

2020-06-30 Thread Kirill Tkalenko (Jira)


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

Kirill Tkalenko updated IGNITE-13123:
-
Reviewer: Alexey Goncharuk  (was: Anton Kalashnikov)

> Move control.sh to a separate module
> 
>
> Key: IGNITE-13123
> URL: https://issues.apache.org/jira/browse/IGNITE-13123
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Move [1] and its associated classes to a separate "ignite-control-utility" 
> module.
> [1] - org.apache.ignite.internal.commandline.CommandHandler



--
This message was sent by Atlassian Jira
(v8.3.4#803005)