[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov edited comment on IGNITE-12894 at 4/27/20, 11:31 PM:


Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is needed. The same is for 
[GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907].

Even if the behavior described above is considered valid, 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169]
 throws an exception that is not ignored in case no node for the service was 
found. So no repeated attempts will be made.

I see two approaches for now:

First: To make 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 wait infinitely if timeout equals to 0.
 It solves the following scenarios:
 * proxy obtaining method is called on node that did not receive service 
registration message
 * service is registered  but service initialization or coordinator full 
message awaiting was not completed

And helps to reuse current ProxyInvocationHandler.

But it blocks the user thread that calls the service method. In case of an 
invalid service name user thread will be blocked forever. Until user thread 
will be interrupted.

Second: To create service processor specific ProxyInvocationHandler. In this 
case, if demanded service was not registered at the moment of invokeMethod  
invocation, exception will be thrown. So we will wait only for already 
registered services  initialization and receiving full message from 
coordinator. If timeout equals 0, we will wait until service will

 be completely initialized or failed.

WDYT?


was (Author: petrovmikhail):
Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is 

[jira] [Created] (IGNITE-12960) Remove twitter module tests from Teamcity Streamers TestSuite

2020-04-27 Thread Saikat Maitra (Jira)
Saikat Maitra created IGNITE-12960:
--

 Summary: Remove twitter module tests from Teamcity Streamers 
TestSuite
 Key: IGNITE-12960
 URL: https://issues.apache.org/jira/browse/IGNITE-12960
 Project: Ignite
  Issue Type: Sub-task
  Components: streaming
Reporter: Saikat Maitra


Remove twitter module tests from Teamcity Streamers TestSuite

This issue is related to https://issues.apache.org/jira/browse/IGNITE-12357



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


[jira] [Resolved] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric

2020-04-27 Thread Nikolay Izhikov (Jira)


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

Nikolay Izhikov resolved IGNITE-12788.
--
Resolution: Fixed

merged to 2.8.1 branch

> Cluster achieved fully rebalanced (PME-free ready) state metric
> ---
>
> Key: IGNITE-12788
> URL: https://issues.apache.org/jira/browse/IGNITE-12788
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Currently, there is no metric responsible for "PME-free ready state achieved" 
> delivery.
> {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such 
> metric.
> Seems, we should update metric on each 
> {{GridDhtPartitionsExchangeFuture#onDone}}.
> P.s. Late Affinity Assignment should always set {{true}} to metric value.



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


[jira] [Commented] (IGNITE-12925) Flaky tests for continuous query metrics.

2020-04-27 Thread Amelchev Nikita (Jira)


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

Amelchev Nikita commented on IGNITE-12925:
--

[~PetrovMikhail], LGTM.

> Flaky tests for continuous query metrics.
> -
>
> Key: IGNITE-12925
> URL: https://issues.apache.org/jira/browse/IGNITE-12925
> Project: Ignite
>  Issue Type: Test
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> It is needed to fix flaky tests:
> SystemViewSelfTest.testContinuousQuery test  – [TC 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead]
> SqlViewExporterSpiTest#testContinuousQuery – [TC 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-5486808152570919536=START_DATE_DESC_IgniteTests24Java8=pull%2F7622%2Fhead=50]
> JmxExporterSpiTest#testContinuousQuery – no failures so far but the same test 
> scenario is used as above.
> It seems that QueryCursor#close method 
>  gives no guarantees that CQ routine will be cleared from all nodes before 
> its returning. This behavior is due to StopRoutineDiscoveryMessage is 
> immutable and so StopRoutineAckDiscoveryMessage can be received 
> (QueryCoursor#close method returns) before 
> GridContinuousProcessor#processStopRequest completion on all nodes.



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


[jira] [Updated] (IGNITE-12958) Add licenses check to Travis configuration

2020-04-27 Thread Amelchev Nikita (Jira)


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

Amelchev Nikita updated IGNITE-12958:
-
Fix Version/s: 2.9

> Add licenses check to Travis configuration
> --
>
> Key: IGNITE-12958
> URL: https://issues.apache.org/jira/browse/IGNITE-12958
> Project: Ignite
>  Issue Type: Task
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 1. Add licenses check to Travis configuration
> 2. Make checks on the compile lifecycle



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


[jira] [Updated] (IGNITE-12959) Add support for GenericWhitespace to checkstyle rules

2020-04-27 Thread Amelchev Nikita (Jira)


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

Amelchev Nikita updated IGNITE-12959:
-
Fix Version/s: 2.9

> Add support for GenericWhitespace to checkstyle rules
> -
>
> Key: IGNITE-12959
> URL: https://issues.apache.org/jira/browse/IGNITE-12959
> Project: Ignite
>  Issue Type: Task
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add a new rule to checkstyle according to Apache Ignite Whitespaces and empty 
> lines conventions.
> 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines



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


[jira] [Updated] (IGNITE-12925) Flaky tests for continuous query metrics.

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov updated IGNITE-12925:

Summary: Flaky tests for continuous query metrics.  (was: Flaky test 
SystemViewSelfTest.testContinuousQuery.)

> Flaky tests for continuous query metrics.
> -
>
> Key: IGNITE-12925
> URL: https://issues.apache.org/jira/browse/IGNITE-12925
> Project: Ignite
>  Issue Type: Test
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> It is needed to fix flaky tests:
> SystemViewSelfTest.testContinuousQuery test  – [TC 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead]
> SqlViewExporterSpiTest#testContinuousQuery – [TC 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-5486808152570919536=START_DATE_DESC_IgniteTests24Java8=pull%2F7622%2Fhead=50]
> JmxExporterSpiTest#testContinuousQuery – no failures so far but the same test 
> scenario is used as above.
> It seems that QueryCursor#close method 
>  gives no guarantees that CQ routine will be cleared from all nodes before 
> its returning. This behavior is due to StopRoutineDiscoveryMessage is 
> immutable and so StopRoutineAckDiscoveryMessage can be received 
> (QueryCoursor#close method returns) before 
> GridContinuousProcessor#processStopRequest completion on all nodes.



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


[jira] [Updated] (IGNITE-12925) Flaky test SystemViewSelfTest.testContinuousQuery.

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov updated IGNITE-12925:

Description: 
It is needed to fix flaky tests:

SystemViewSelfTest.testContinuousQuery test  – [TC 
history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead]

SqlViewExporterSpiTest#testContinuousQuery – [TC 
history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-5486808152570919536=START_DATE_DESC_IgniteTests24Java8=pull%2F7622%2Fhead=50]

JmxExporterSpiTest#testContinuousQuery – no failures so far but the same test 
scenario is used as above.

It seems that QueryCursor#close method 
 gives no guarantees that CQ routine will be cleared from all nodes before its 
returning. This behavior is due to StopRoutineDiscoveryMessage is immutable and 
so StopRoutineAckDiscoveryMessage can be received (QueryCoursor#close method 
returns) before GridContinuousProcessor#processStopRequest completion on all 
nodes.

  was:
It is needed to fix SystemViewSelfTest.testContinuousQuery test, which is flaky 
– [TC 
history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead].

It seems that QueryCursor#close method 
 gives no guarantees that CQ routine will be cleared from all nodes before its 
returning. This behavior is due to StopRoutineDiscoveryMessage is immutable and 
so StopRoutineAckDiscoveryMessage can be received (QueryCoursor#close method 
returns) before GridContinuousProcessor#processStopRequest completion on all 
nodes.


> Flaky test SystemViewSelfTest.testContinuousQuery.
> --
>
> Key: IGNITE-12925
> URL: https://issues.apache.org/jira/browse/IGNITE-12925
> Project: Ignite
>  Issue Type: Test
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> It is needed to fix flaky tests:
> SystemViewSelfTest.testContinuousQuery test  – [TC 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead]
> SqlViewExporterSpiTest#testContinuousQuery – [TC 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-5486808152570919536=START_DATE_DESC_IgniteTests24Java8=pull%2F7622%2Fhead=50]
> JmxExporterSpiTest#testContinuousQuery – no failures so far but the same test 
> scenario is used as above.
> It seems that QueryCursor#close method 
>  gives no guarantees that CQ routine will be cleared from all nodes before 
> its returning. This behavior is due to StopRoutineDiscoveryMessage is 
> immutable and so StopRoutineAckDiscoveryMessage can be received 
> (QueryCoursor#close method returns) before 
> GridContinuousProcessor#processStopRequest completion on all nodes.



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


[jira] [Created] (IGNITE-12959) Add support for GenericWhitespace to checkstyle rules

2020-04-27 Thread Amelchev Nikita (Jira)
Amelchev Nikita created IGNITE-12959:


 Summary: Add support for GenericWhitespace to checkstyle rules
 Key: IGNITE-12959
 URL: https://issues.apache.org/jira/browse/IGNITE-12959
 Project: Ignite
  Issue Type: Task
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita


Add a new rule to checkstyle according to Apache Ignite Whitespaces and empty 
lines conventions.



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




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


[jira] [Assigned] (IGNITE-12925) Flaky test SystemViewSelfTest.testContinuousQuery.

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov reassigned IGNITE-12925:
---

Assignee: Mikhail Petrov

> Flaky test SystemViewSelfTest.testContinuousQuery.
> --
>
> Key: IGNITE-12925
> URL: https://issues.apache.org/jira/browse/IGNITE-12925
> Project: Ignite
>  Issue Type: Test
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
>
> It is needed to fix SystemViewSelfTest.testContinuousQuery test, which is 
> flaky – [TC 
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead].
> It seems that QueryCursor#close method 
>  gives no guarantees that CQ routine will be cleared from all nodes before 
> its returning. This behavior is due to StopRoutineDiscoveryMessage is 
> immutable and so StopRoutineAckDiscoveryMessage can be received 
> (QueryCoursor#close method returns) before 
> GridContinuousProcessor#processStopRequest completion on all nodes.



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


[jira] [Created] (IGNITE-12958) Add licenses check to Travis configuration

2020-04-27 Thread Amelchev Nikita (Jira)
Amelchev Nikita created IGNITE-12958:


 Summary: Add licenses check to Travis configuration
 Key: IGNITE-12958
 URL: https://issues.apache.org/jira/browse/IGNITE-12958
 Project: Ignite
  Issue Type: Task
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita


1. Add licenses check to Travis configuration
2. Make checks on the compile lifecycle



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


[jira] [Commented] (IGNITE-12902) Concurrent modification in time to iterate by events

2020-04-27 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk commented on IGNITE-12902:
---

Merged to master, thanks!

> Concurrent modification in time to iterate by events
> 
>
> Key: IGNITE-12902
> URL: https://issues.apache.org/jira/browse/IGNITE-12902
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {code:java}
> [10:20:37]W: [org.apache.ignite:ignite-core] [2020-02-20 
> 10:20:37,324][ERROR][main][CacheExchangeMergeTest9] Failed to pre-stop 
> processor: GridProcessorAdapter []
>  [10:20:37]W: [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
>  [10:20:37]W: [org.apache.ignite:ignite-core] at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
>  [10:20:37]W: [org.apache.ignite:ignite-core] at 
> java.util.ArrayList$Itr.next(ArrayList.java:859)
>  [10:20:37]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2302)
>  [10:20:37]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:142)
>  [10:20:37]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:464)
>  [10:20:37]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:821)
>  [10:20:37]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120)
>  [10:20:37]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:972){code}
> In that place we are going over event’s collection, looking for server 
> leave’s event:
> {code:java}
> for (DiscoveryEvent evt : evts.events()) {
> if (serverLeftEvent(evt)) {
> for (CacheGroupContext grp : cctx.cache().cacheGroups())
> grp.affinityFunction().removeNode(evt.eventNode().id());
> }
> }
> {code}



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


[jira] [Commented] (IGNITE-12957) .NET: Docs have unavailable resource logo3.png

2020-04-27 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn commented on IGNITE-12957:
-

Merged to master: b5857399a9dac671ddaadd0cabfa246393af6a43

> .NET: Docs have unavailable resource logo3.png
> --
>
> Key: IGNITE-12957
> URL: https://issues.apache.org/jira/browse/IGNITE-12957
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation, platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.9
>
>




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


[jira] [Resolved] (IGNITE-12957) .NET: Docs have unavailable resource logo3.png

2020-04-27 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn resolved IGNITE-12957.
-
Resolution: Fixed

> .NET: Docs have unavailable resource logo3.png
> --
>
> Key: IGNITE-12957
> URL: https://issues.apache.org/jira/browse/IGNITE-12957
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation, platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.9
>
>




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


[jira] [Created] (IGNITE-12957) .NET: Docs have unavailable resource logo3.png

2020-04-27 Thread Pavel Tupitsyn (Jira)
Pavel Tupitsyn created IGNITE-12957:
---

 Summary: .NET: Docs have unavailable resource logo3.png
 Key: IGNITE-12957
 URL: https://issues.apache.org/jira/browse/IGNITE-12957
 Project: Ignite
  Issue Type: New Feature
  Components: documentation, platforms
Affects Versions: 2.8
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.9






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


[jira] [Assigned] (IGNITE-12956) Fully prepared TX rolled back on recovery if TX coordinator failed and some primary has only reads

2020-04-27 Thread Anton Vinogradov (Jira)


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

Anton Vinogradov reassigned IGNITE-12956:
-

Assignee: Anton Vinogradov

> Fully prepared TX rolled back on recovery if TX coordinator failed and some 
> primary has only reads
> --
>
> Key: IGNITE-12956
> URL: https://issues.apache.org/jira/browse/IGNITE-12956
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
>
> We have 3 nodes with partitioned cache with 2 backups.
>  A - tx coordinator.
>  B and C - other nodes.
> Let's start tx from A and perform
> {noformat}
> cache.put(primaryKeyA, someVal);
> cache.get(primaryKeyB;
> tx.prepare();
> {noformat}
> then kill A.
> Expected: tx recovered and
> {noformat}
> cache.get(primaryKeyA)!=null
> {noformat}
> Actual: tx rolled back and
>  and
> {noformat}
> cache.get(primaryKeyA)==null
> {noformat}
> Reason: Node C has only 1 active transaction (because reads not propagated to 
> backup), but expect to have 2.



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


[jira] [Created] (IGNITE-12956) Fully prepared TX rolled back on recovery if TX coordinator failed and some primary has only reads

2020-04-27 Thread Anton Vinogradov (Jira)
Anton Vinogradov created IGNITE-12956:
-

 Summary: Fully prepared TX rolled back on recovery if TX 
coordinator failed and some primary has only reads
 Key: IGNITE-12956
 URL: https://issues.apache.org/jira/browse/IGNITE-12956
 Project: Ignite
  Issue Type: Task
Reporter: Anton Vinogradov


We have 3 nodes with partitioned cache with 2 backups.
 A - tx coordinator.
 B and C - other nodes.

Let's start tx from A and perform
{noformat}
cache.put(primaryKeyA, someVal);
cache.get(primaryKeyB;
tx.prepare();
{noformat}
then kill A.

Expected: tx recovered and
{noformat}
cache.get(primaryKeyA)!=null
{noformat}
Actual: tx rolled back and
 and
{noformat}
cache.get(primaryKeyA)==null
{noformat}
Reason: Node C has only 1 active transaction (because reads not propagated to 
backup), but expect to have 2.



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


[jira] [Commented] (IGNITE-12938) control.sh utility commands: IdleVerify and ValidateIndexes use eventual payload check.

2020-04-27 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12938:


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

> control.sh utility commands: IdleVerify and ValidateIndexes use eventual 
> payload check.
> ---
>
> Key: IGNITE-12938
> URL: https://issues.apache.org/jira/browse/IGNITE-12938
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.9
>
>
> "--cache idle_verify" and "--cache validate_indexes" commands of *control.sh* 
>  utility use eventual payload check during  execution. This can lead to 
> execution concurrently with active payload and no errors like : "Checkpoint 
> with dirty pages started! Cluster not idle"  will be triggered. Additionally 
> current functional miss check on caches without persistence.  Remove old 
> functionality from PageMemory and move it into update counters usage.



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


[jira] [Commented] (IGNITE-12954) Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser

2020-04-27 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov commented on IGNITE-12954:
--

[~zaleslaw]

Thank you, merged to the master branch.

> Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser
> --
>
> Key: IGNITE-12954
> URL: https://issues.apache.org/jira/browse/IGNITE-12954
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently, there are some redundant suppressions for the checkstyle rules 
> which can be removed:
> {code}
>  files="XGBoostModelLexer\.java|XGBoostModelParser\.java"/>
> {code}



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


[jira] [Commented] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov commented on IGNITE-12788:
-

[~nizhikov],

I have created PR with cherry-pick - [1]. TC bot report - [2].

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

[2] - 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull%2F7738%2Fhead=Latest=ignite-2.8.1]

> Cluster achieved fully rebalanced (PME-free ready) state metric
> ---
>
> Key: IGNITE-12788
> URL: https://issues.apache.org/jira/browse/IGNITE-12788
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Currently, there is no metric responsible for "PME-free ready state achieved" 
> delivery.
> {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such 
> metric.
> Seems, we should update metric on each 
> {{GridDhtPartitionsExchangeFuture#onDone}}.
> P.s. Late Affinity Assignment should always set {{true}} to metric value.



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


[jira] [Updated] (IGNITE-12954) Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser

2020-04-27 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov updated IGNITE-12954:
-
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser
> --
>
> Key: IGNITE-12954
> URL: https://issues.apache.org/jira/browse/IGNITE-12954
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently, there are some redundant suppressions for the checkstyle rules 
> which can be removed:
> {code}
>  files="XGBoostModelLexer\.java|XGBoostModelParser\.java"/>
> {code}



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


[jira] [Commented] (IGNITE-12954) Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser

2020-04-27 Thread Alexey Zinoviev (Jira)


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

Alexey Zinoviev commented on IGNITE-12954:
--

[~mmuzaf] Yes, looks good for me

> Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser
> --
>
> Key: IGNITE-12954
> URL: https://issues.apache.org/jira/browse/IGNITE-12954
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently, there are some redundant suppressions for the checkstyle rules 
> which can be removed:
> {code}
>  files="XGBoostModelLexer\.java|XGBoostModelParser\.java"/>
> {code}



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


[jira] [Commented] (IGNITE-12954) Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser

2020-04-27 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov commented on IGNITE-12954:
--

[~zaleslaw]

Hello, can you take a look at my changes?

> Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser
> --
>
> Key: IGNITE-12954
> URL: https://issues.apache.org/jira/browse/IGNITE-12954
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, there are some redundant suppressions for the checkstyle rules 
> which can be removed:
> {code}
>  files="XGBoostModelLexer\.java|XGBoostModelParser\.java"/>
> {code}



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


[jira] [Commented] (IGNITE-12954) Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser

2020-04-27 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12954:


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

> Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser
> --
>
> Key: IGNITE-12954
> URL: https://issues.apache.org/jira/browse/IGNITE-12954
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, there are some redundant suppressions for the checkstyle rules 
> which can be removed:
> {code}
>  files="XGBoostModelLexer\.java|XGBoostModelParser\.java"/>
> {code}



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


[jira] [Commented] (IGNITE-12911) B+Tree Corrupted exception when using a key extracted from a BinaryObject value object --- and SQL enabled.

2020-04-27 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12911:


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

> B+Tree Corrupted exception when using a key extracted from a BinaryObject 
> value object --- and SQL enabled.
> ---
>
> Key: IGNITE-12911
> URL: https://issues.apache.org/jira/browse/IGNITE-12911
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Reporter: Alexander Korenshteyn
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9
>
> Attachments: Employee.java, EmployeeId.java, ServerNode.java, 
> image-2020-04-21-17-10-55-797.png, image-2020-04-21-17-11-31-242.png, 
> image-2020-04-21-17-16-10-703.png, image-2020-04-21-17-16-29-107.png, 
> image-2020-04-21-17-16-46-381.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a key is part of the value like so:
>  class key \{ ... }
> class value
> { private Key key getKey() }
> cache = ignite.cache()*.withKeepBinary()*
> the following scenario yields a B+ Tree exception:
> 1. *Enable SQL via annotations or QueryEntities.*
> key1= new Key()
>  value1 = new Value(key1)
> cache.put(key1, value1)
> BinaryObject val2 = cache.get(key1)
>  BinaryObject key2 = val2.field("key")
>  
> *cache2.put(key2.toBuilder().build(), emp1); // OK!*
>  
> *cache.put(key2, emp1); // CRASH!!! CorruptedTreeException: B+Tree 
> iscorrupted ...*
> user list:
>  
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-crashes-with-CorruptedTreeException-quot-B-Tree-is-corrupted-quot-on-a-composite-BinaryObjecto-tc32032.html]
> *Reproducer – attached* 
>  
> his happens because:
> CacheRowAdapter.readFullRow() reads the length
> *int len = PageUtils.getInt(addr,off)*
> *it returns 0 when val2.field("key") is used*
>  
> *the data is written correctly in DataPageIO.writeDataPageIO():*
> !image-2020-04-21-17-16-46-381.png!
>  
> *but read incorrectly in CacheRowAdapter.readFullRow()*
>    !image-2020-04-21-17-16-29-107.png!
>  
>   
>  Exception:
> [2020-04-17 11:24:33,475][ERROR][main][root] Critical system error detected. 
> Will be handled accordingly to configured handler 
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, 
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet 
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], 
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class 
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is 
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742, 
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE, 
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key: 
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765, 
> departmentNumber=123], val: model.Employee [idHash=382762227, 
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId 
> [idHash=2021540695, hash=674030145, employeeNumber=65348765, 
> departmentNumber=123]] ][ John, Smith 
> class 
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
>  B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742, 
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE, 
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key: 
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765, 
> departmentNumber=123], val: model.Employee [idHash=382762227, 
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId 
> [idHash=2021540695, hash=674030145, employeeNumber=65348765, 
> departmentNumber=123]] ][ John, Smith ]]
> at 
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:836)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2447)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2394)
> at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:437)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:756)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:363)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2016)
> at 
> 

[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov edited comment on IGNITE-12894 at 4/27/20, 3:12 PM:
---

Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is needed. The same is for 
[GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907].

Even if the behavior described above is considered valid, 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169]
 throws an exception that is not ignored in case no node for the service was 
found. So no repeated attempts will be made.

I see two approaches for now:

First: To make 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 wait infinitely if timeout equals to 0.
 It solves the following scenarios:
 * proxy obtaining method is called on node that did not receive service 
registration message
 * service is registered  but service initialization or coordinator full 
message awaiting was not completed

And helps to reuse current ProxyInvocationHandler.

But it blocks the user thread that calls the service method. In case of an 
invalid service name user thread will be blocked forever. Until user thread 
will be interrupted.

Second: To create service specific ProxyInvocationHandler. In this case, if 
demanded service was not registered at the moment of invokeMethod  invocation, 
exception will be thrown. So we will wait only for already registered services  
initialization and receiving full message from coordinator. If timeout equals 
0, we will wait until service will

 be completely initialized or failed.

WDYT?


was (Author: petrovmikhail):
Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is needed. The 

[jira] [Commented] (IGNITE-12953) Add support for SingleSpaceSeparator to checkstyle rules

2020-04-27 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov commented on IGNITE-12953:
--

[~NSAmelchev]

LGTM, Merged to the master branch. Thank you for your contribution.

> Add support for SingleSpaceSeparator to checkstyle rules
> 
>
> Key: IGNITE-12953
> URL: https://issues.apache.org/jira/browse/IGNITE-12953
> Project: Ignite
>  Issue Type: Task
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add a new rule to checkstyle according to Apache Ignite Whitespaces and empty 
> lines conventions.
> 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines



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


[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov edited comment on IGNITE-12894 at 4/27/20, 2:52 PM:
---

Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is needed. The same is for 
[GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907].

Even if the behavior described above is considered valid, 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169]
 throws an exception that is not ignored in case no node for the service was 
found. So no repeated attempts will be made.

I see two approaches for now:

First: To make 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 wait infinitely if timeout equals to 0.
 It solves the following scenarios:
 * proxy obtaining method is called on node that did not receive service 
registration message
 * service is registered  but service initialization or coordinator full 
message awaiting was not completed

And helps to reuse current ProxyInvocationHandler.

But it blocks the user thread that calls the service method. In case of an 
invalid service name user thread will be blocked forever. Until user thread 
will be interrupted.

Second: To create service specific ProxyInvocationHandler with described by you 
logic. In this case, if demanded service was not registered at the moment of 
invokeMethod  invocation, exception will be thrown. So we will wait only for 
already registered services  initialization and receiving full message from 
coordinator.

WDYT?


was (Author: petrovmikhail):
Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is needed. The same is for 

[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov edited comment on IGNITE-12894 at 4/27/20, 2:51 PM:
---

Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is needed. The same is for 
[GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907].

Even if the behavior described above is considered valid, 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169]
 throws an exception that is not ignored in case no node for the service was 
found. So no repeated attempts will be made.

I see two approaches for now:

First: To make 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 wait infinitely if timeout equals to 0.
It solves the following scenarios:
 * proxy obtaining method is called on node that did not receive service 
registration message
 * service is registered  but service initialization or coordinator full 
message awaiting was not completed

And helps to reuse current ProxyInvocationHandler.

But it blocks the user thread that calls the service method. In case of an 
invalid service name user thread will be blocked forever. Until user thread 
will be interrupted.

Second: To create service specific ProxyInvocationHandler with described by you 
logic. In this case, if demanded service was not registered on the moment of 
invokeMethod  invocation, exception will be thrown. So we will wait only for 
already registered services  initialization and receiving full message from 
coordinator.

WDYT?


was (Author: petrovmikhail):
Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is needed. The same is for 

[jira] [Resolved] (IGNITE-12936) .NET inspections fail on master

2020-04-27 Thread Igor Sapego (Jira)


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

Igor Sapego resolved IGNITE-12936.
--
Resolution: Duplicate

Fixed by IGNITE-12940

> .NET inspections fail on master
> ---
>
> Key: IGNITE-12936
> URL: https://issues.apache.org/jira/browse/IGNITE-12936
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The following suites are failing:
> [Platform .NET (NuGet) 
> |https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetNuGet?branch=%3Cdefault%3E]
> [Platform .NET (Inspections) 
> |https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetInspections?branch=%3Cdefault%3E]



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


[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov edited comment on IGNITE-12894 at 4/27/20, 1:29 PM:
---

Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is needed. The same is for 
[GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907].

Even if the behavior described above is considered valid, 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169]
 throws an exception that is not ignored in case no node for the service was 
found. So no repeated attempts will be made.

So I propose to make 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 wait infinitely if timeout equals to 0.
 In case of using IgniteServiceProcessor, it helps to avoid using busy-wait 
loop for topology obtaining. And solves the following scenarios:
 * proxy obtaining method is called on node that did not receive service 
registration message
 * service is registered  but service initialization or coordinator full 
message awaiting was not completed

But it blocks the user thread that calls the service method. In case of an 
invalid service name user thread will be blocked forever. Until user thread 
will be interrupted.

WDYT?


was (Author: petrovmikhail):
Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is needed. The same is for 
[GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907].

Even if the behavior described above is considered valid, 

[jira] [Created] (IGNITE-12955) Document a new command control.sh --cache check_index_inline_sizes

2020-04-27 Thread Sergey Antonov (Jira)
Sergey Antonov created IGNITE-12955:
---

 Summary: Document a new command control.sh --cache 
check_index_inline_sizes
 Key: IGNITE-12955
 URL: https://issues.apache.org/jira/browse/IGNITE-12955
 Project: Ignite
  Issue Type: New Feature
  Components: documentation
Reporter: Sergey Antonov
 Fix For: 2.9


Please look at IGNITE-12942 and devlist discussion linked to IGNITE-12942 for 
all information.



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


[jira] [Commented] (IGNITE-12953) Add support for SingleSpaceSeparator to checkstyle rules

2020-04-27 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12953:


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

> Add support for SingleSpaceSeparator to checkstyle rules
> 
>
> Key: IGNITE-12953
> URL: https://issues.apache.org/jira/browse/IGNITE-12953
> Project: Ignite
>  Issue Type: Task
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add a new rule to checkstyle according to Apache Ignite Whitespaces and empty 
> lines conventions.
> 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines



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


[jira] [Updated] (IGNITE-12898) Server node with CacheStore fails to re-join the cluster: Cannot enable read-through (loader or store is not provided) for cache

2020-04-27 Thread Ivan Daschinskiy (Jira)


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

Ivan Daschinskiy updated IGNITE-12898:
--
Fix Version/s: 2.9

> Server node with CacheStore fails to re-join the cluster: Cannot enable 
> read-through (loader or store is not provided) for cache
> 
>
> Key: IGNITE-12898
> URL: https://issues.apache.org/jira/browse/IGNITE-12898
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
>  Labels: sbcf
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a cache with external persistence is dynamically created on a non-affinity 
> node then the cache affinity node cannot join the cluster after restart.
> h2. Repro Steps
>  # Run an "empty" Ignite node where no cache is going to be started
>  # Run a cache affinity node having the "ROLE" attribute set to "DATA"
>  # Create the cache from the "empty" node and use a Node Filter to limit the 
> cache to the "data" node. External persistence is configured for the cache.
>  # Restart the "data" node
> h3. Actual Result
> {{IgniteCheckedException: Cannot enable read-through (loader or store is not 
> provided) for cache}}
> h2. Reproducer
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> @Test
> public void test() throws Exception {
> final String DB_URL = "jdbc:h2:mem:test";
> final String ENTITY_NAME = "Person";
> Function igniteCfgFactory = instanceName 
> ->
> new IgniteConfiguration()
> .setIgniteInstanceName(instanceName)
> .setDiscoverySpi(new TcpDiscoverySpi()
> .setIpFinder(new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> // 1. Run an "empty" Ignite node where no cache is going to be started
> try (Connection dbConn = DriverManager.getConnection(DB_URL, "sa", 
> "");
>  Statement dbStmt = dbConn.createStatement();
>  Ignite emptyNode = 
> Ignition.start(igniteCfgFactory.apply("emptyyNode"))) {
> // 2. Run a "Person" cache affinity node having the "ROLE" 
> attribute set to "DATA"
> Map dataNodeAttrs = new HashMap<>(1);
> dataNodeAttrs.put(DataNodeFilter.ATTR_NAME, 
> DataNodeFilter.ATTR_VAL);
> Ignite dataNode = 
> Ignition.start(igniteCfgFactory.apply("dataNode").setUserAttributes(dataNodeAttrs));
> // 3. Create the "Person" cache from the "empty" node and use a 
> Node Filter to limit the cache to the
> // "data" node. External persistence to the "Person" table in H2 
> DB is configured for the cache.
> dbStmt.execute("CREATE TABLE " + ENTITY_NAME + " (id int PRIMARY 
> KEY, name varchar)");
> CacheJdbcPojoStoreFactory 
> igniteStoreFactory = new CacheJdbcPojoStoreFactory<>();
> igniteStoreFactory.setDataSourceFactory(() -> 
> JdbcConnectionPool.create(DB_URL, "sa", ""))
> .setTypes(
> new JdbcType()
> .setCacheName(ENTITY_NAME)
> .setDatabaseTable(ENTITY_NAME)
> .setKeyType(Integer.class)
> .setValueType(ENTITY_NAME)
> .setKeyFields(new 
> JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"))
> .setValueFields(
> new JdbcTypeField(java.sql.Types.INTEGER, "id", 
> Integer.class, "id"),
> new JdbcTypeField(java.sql.Types.VARCHAR, "name", 
> String.class, "name")
> )
> );
> CacheConfiguration cacheCfg =
> new CacheConfiguration(ENTITY_NAME)
> .setCacheMode(CacheMode.REPLICATED)
> .setCacheStoreFactory(igniteStoreFactory)
> .setWriteThrough(true)
> .setReadThrough(true)
> .setNodeFilter(new DataNodeFilter());
> emptyNode.createCache(cacheCfg).withKeepBinary();
> // 4. Restart the "data" node
> dataNode.close();
> dataNode = 
> Ignition.start(igniteCfgFactory.apply("node2").setUserAttributes(dataNodeAttrs));
> dataNode.close();
> }
> }
> private static class DataNodeFilter implements 
> IgnitePredicate {
> public static final String ATTR_NAME = "ROLE";
> public static final String ATTR_VAL = "DATA";
> @Override public boolean apply(ClusterNode node) {
> Object role = 

[jira] [Updated] (IGNITE-12583) Parametrization of JdbcThinBulkLoadAbstractSelfTest

2020-04-27 Thread Nikolay Izhikov (Jira)


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

Nikolay Izhikov updated IGNITE-12583:
-
Fix Version/s: 2.9

> Parametrization of JdbcThinBulkLoadAbstractSelfTest
> ---
>
> Key: IGNITE-12583
> URL: https://issues.apache.org/jira/browse/IGNITE-12583
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Fix For: 2.9
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> org.apache.ignite.jdbc.thin.JdbcThinBulkLoadAbstractSelfTest is extended 
> several times using just parameter-assigning-getters like 
> {code:java}
> protected CacheMode cacheMode() { return CacheMode.REPLICATED; }
> protected CacheAtomicityMode atomicityMode() { return 
> CacheAtomicityMode.TRANSACTIONAL;}
> protected boolean nearCache() { return false; }
> {code}
> Should go with params instead.
>  



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


[jira] [Commented] (IGNITE-12583) Parametrization of JdbcThinBulkLoadAbstractSelfTest

2020-04-27 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk commented on IGNITE-12583:
---

[~vladsz83] [~nizhikov] can you update the fixVersion?

> Parametrization of JdbcThinBulkLoadAbstractSelfTest
> ---
>
> Key: IGNITE-12583
> URL: https://issues.apache.org/jira/browse/IGNITE-12583
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> org.apache.ignite.jdbc.thin.JdbcThinBulkLoadAbstractSelfTest is extended 
> several times using just parameter-assigning-getters like 
> {code:java}
> protected CacheMode cacheMode() { return CacheMode.REPLICATED; }
> protected CacheAtomicityMode atomicityMode() { return 
> CacheAtomicityMode.TRANSACTIONAL;}
> protected boolean nearCache() { return false; }
> {code}
> Should go with params instead.
>  



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


[jira] [Commented] (IGNITE-12917) SQL: print warning log message when query's result is big

2020-04-27 Thread Andrey Mashenkov (Jira)


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

Andrey Mashenkov commented on IGNITE-12917:
---

[~tledkov-gridgain], lgtm, merges to master.

> SQL: print warning log message when query's result is big
> -
>
> Key: IGNITE-12917
> URL: https://issues.apache.org/jira/browse/IGNITE-12917
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We have to track queries with big result set.
> Print warning log message when query's result is bigger than threshold 
> specified by JMX.



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


[jira] [Commented] (IGNITE-7276) .NET: Enable/disable cache statistics in runtime

2020-04-27 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn commented on IGNITE-7276:


[~agoncharuk] done, this will be in the next non-patch release, likely 2.9 

> .NET: Enable/disable cache statistics in runtime
> 
>
> Key: IGNITE-7276
> URL: https://issues.apache.org/jira/browse/IGNITE-7276
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
>  Labels: .NET, newbie
> Fix For: 2.9
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {{ICache.EnableStatistics}}, {{ICluster.EnableStatistics}}.
> See IGNITE-369.



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


[jira] [Updated] (IGNITE-7276) .NET: Enable/disable cache statistics in runtime

2020-04-27 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn updated IGNITE-7276:
---
Fix Version/s: 2.9

> .NET: Enable/disable cache statistics in runtime
> 
>
> Key: IGNITE-7276
> URL: https://issues.apache.org/jira/browse/IGNITE-7276
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
>  Labels: .NET, newbie
> Fix For: 2.9
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {{ICache.EnableStatistics}}, {{ICluster.EnableStatistics}}.
> See IGNITE-369.



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


[jira] [Updated] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases

2020-04-27 Thread Ilya Kasnacheev (Jira)


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

Ilya Kasnacheev updated IGNITE-10940:
-
Release Note: C++ platform no longer requires autotools to build.

> Supply pre-built ./configure with Apache Ignite releases
> 
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
>  Issue Type: Improvement
>  Components: build, platforms
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>  Labels: c++
> Fix For: 2.9
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first 
> step already done. ./configure should be pre-built and libtoolize, etc, are 
> already ran since you should not force user to install them, and the process 
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's 
> first step will be ./configure.



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


[jira] [Updated] (IGNITE-7828) Adopt yardstick tests for the new version of kNN regression algorithm

2020-04-27 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk updated IGNITE-7828:
-
Fix Version/s: (was: 2.8)

> Adopt yardstick tests for the new version of kNN regression algorithm
> -
>
> Key: IGNITE-7828
> URL: https://issues.apache.org/jira/browse/IGNITE-7828
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Alexey Zinoviev
>Assignee: Alexey Zinoviev
>Priority: Major
>




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


[jira] [Updated] (IGNITE-7828) Adopt yardstick tests for the new version of kNN regression algorithm

2020-04-27 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk updated IGNITE-7828:
-
Fix Version/s: 2.8

> Adopt yardstick tests for the new version of kNN regression algorithm
> -
>
> Key: IGNITE-7828
> URL: https://issues.apache.org/jira/browse/IGNITE-7828
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Alexey Zinoviev
>Assignee: Alexey Zinoviev
>Priority: Major
> Fix For: 2.8
>
>




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


[jira] [Commented] (IGNITE-7276) .NET: Enable/disable cache statistics in runtime

2020-04-27 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk commented on IGNITE-7276:
--

[~ptupitsyn] Can you please update the fixVersion? Which release will this 
improvement get in?

> .NET: Enable/disable cache statistics in runtime
> 
>
> Key: IGNITE-7276
> URL: https://issues.apache.org/jira/browse/IGNITE-7276
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
>  Labels: .NET, newbie
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {{ICache.EnableStatistics}}, {{ICluster.EnableStatistics}}.
> See IGNITE-369.



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


[jira] [Assigned] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov reassigned IGNITE-12788:
---

Assignee: Mikhail Petrov  (was: Nikolay Izhikov)

> Cluster achieved fully rebalanced (PME-free ready) state metric
> ---
>
> Key: IGNITE-12788
> URL: https://issues.apache.org/jira/browse/IGNITE-12788
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Currently, there is no metric responsible for "PME-free ready state achieved" 
> delivery.
> {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such 
> metric.
> Seems, we should update metric on each 
> {{GridDhtPartitionsExchangeFuture#onDone}}.
> P.s. Late Affinity Assignment should always set {{true}} to metric value.



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


[jira] [Commented] (IGNITE-12806) Incorret usage of Class.isAssignableFrom in SystemViewLocal and SystemViewMBean classes

2020-04-27 Thread Nikolay Izhikov (Jira)


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

Nikolay Izhikov commented on IGNITE-12806:
--

Hello, [~YAMolochkov].

It seems to me like a minor issue.
I will move it to 2.9 release, because, 2.8.1 is a bugfix release.

> Incorret usage of Class.isAssignableFrom in SystemViewLocal and 
> SystemViewMBean classes
> ---
>
> Key: IGNITE-12806
> URL: https://issues.apache.org/jira/browse/IGNITE-12806
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Yaroslav Molochkov
>Priority: Major
>  Labels: IEP-35
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Classes {{SystemViewLocal}} and {{SystemViewMBean}} uses method 
> {{Class.isAssignableFrom}} in incorrect manner. I given cases relation is 
> inverted and doesn't have any sense. In most cases usages of 
> {{Class.isAssignableFrom}} could be avoided.
> See creation of {{AttributeVisitor}} and {{AttributeWithValueVisitor}} 
> instance in mentioned classes.



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


[jira] [Updated] (IGNITE-12806) Incorret usage of Class.isAssignableFrom in SystemViewLocal and SystemViewMBean classes

2020-04-27 Thread Nikolay Izhikov (Jira)


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

Nikolay Izhikov updated IGNITE-12806:
-
Fix Version/s: (was: 2.8.1)
   2.9

> Incorret usage of Class.isAssignableFrom in SystemViewLocal and 
> SystemViewMBean classes
> ---
>
> Key: IGNITE-12806
> URL: https://issues.apache.org/jira/browse/IGNITE-12806
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Yaroslav Molochkov
>Priority: Minor
>  Labels: IEP-35
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Classes {{SystemViewLocal}} and {{SystemViewMBean}} uses method 
> {{Class.isAssignableFrom}} in incorrect manner. I given cases relation is 
> inverted and doesn't have any sense. In most cases usages of 
> {{Class.isAssignableFrom}} could be avoided.
> See creation of {{AttributeVisitor}} and {{AttributeWithValueVisitor}} 
> instance in mentioned classes.



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


[jira] [Updated] (IGNITE-12806) Incorret usage of Class.isAssignableFrom in SystemViewLocal and SystemViewMBean classes

2020-04-27 Thread Nikolay Izhikov (Jira)


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

Nikolay Izhikov updated IGNITE-12806:
-
Priority: Minor  (was: Major)

> Incorret usage of Class.isAssignableFrom in SystemViewLocal and 
> SystemViewMBean classes
> ---
>
> Key: IGNITE-12806
> URL: https://issues.apache.org/jira/browse/IGNITE-12806
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Yaroslav Molochkov
>Priority: Minor
>  Labels: IEP-35
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Classes {{SystemViewLocal}} and {{SystemViewMBean}} uses method 
> {{Class.isAssignableFrom}} in incorrect manner. I given cases relation is 
> inverted and doesn't have any sense. In most cases usages of 
> {{Class.isAssignableFrom}} could be avoided.
> See creation of {{AttributeVisitor}} and {{AttributeWithValueVisitor}} 
> instance in mentioned classes.



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


[jira] [Assigned] (IGNITE-12911) B+Tree Corrupted exception when using a key extracted from a BinaryObject value object --- and SQL enabled.

2020-04-27 Thread Anton Kalashnikov (Jira)


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

Anton Kalashnikov reassigned IGNITE-12911:
--

Assignee: Anton Kalashnikov

> B+Tree Corrupted exception when using a key extracted from a BinaryObject 
> value object --- and SQL enabled.
> ---
>
> Key: IGNITE-12911
> URL: https://issues.apache.org/jira/browse/IGNITE-12911
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Reporter: Alexander Korenshteyn
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9
>
> Attachments: Employee.java, EmployeeId.java, ServerNode.java, 
> image-2020-04-21-17-10-55-797.png, image-2020-04-21-17-11-31-242.png, 
> image-2020-04-21-17-16-10-703.png, image-2020-04-21-17-16-29-107.png, 
> image-2020-04-21-17-16-46-381.png
>
>
> If a key is part of the value like so:
>  class key \{ ... }
> class value
> { private Key key getKey() }
> cache = ignite.cache()*.withKeepBinary()*
> the following scenario yields a B+ Tree exception:
> 1. *Enable SQL via annotations or QueryEntities.*
> key1= new Key()
>  value1 = new Value(key1)
> cache.put(key1, value1)
> BinaryObject val2 = cache.get(key1)
>  BinaryObject key2 = val2.field("key")
>  
> *cache2.put(key2.toBuilder().build(), emp1); // OK!*
>  
> *cache.put(key2, emp1); // CRASH!!! CorruptedTreeException: B+Tree 
> iscorrupted ...*
> user list:
>  
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-crashes-with-CorruptedTreeException-quot-B-Tree-is-corrupted-quot-on-a-composite-BinaryObjecto-tc32032.html]
> *Reproducer – attached* 
>  
> his happens because:
> CacheRowAdapter.readFullRow() reads the length
> *int len = PageUtils.getInt(addr,off)*
> *it returns 0 when val2.field("key") is used*
>  
> *the data is written correctly in DataPageIO.writeDataPageIO():*
> !image-2020-04-21-17-16-46-381.png!
>  
> *but read incorrectly in CacheRowAdapter.readFullRow()*
>    !image-2020-04-21-17-16-29-107.png!
>  
>   
>  Exception:
> [2020-04-17 11:24:33,475][ERROR][main][root] Critical system error detected. 
> Will be handled accordingly to configured handler 
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, 
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet 
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], 
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class 
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is 
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742, 
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE, 
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key: 
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765, 
> departmentNumber=123], val: model.Employee [idHash=382762227, 
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId 
> [idHash=2021540695, hash=674030145, employeeNumber=65348765, 
> departmentNumber=123]] ][ John, Smith 
> class 
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
>  B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742, 
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE, 
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key: 
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765, 
> departmentNumber=123], val: model.Employee [idHash=382762227, 
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId 
> [idHash=2021540695, hash=674030145, employeeNumber=65348765, 
> departmentNumber=123]] ][ John, Smith ]]
> at 
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:836)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2447)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2394)
> at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:437)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:756)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:363)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2016)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:401)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2555)
> at 
> 

[jira] [Commented] (IGNITE-12933) Node failed after put incorrect key class for indexed type to transactional cache

2020-04-27 Thread Sergey Kalashnikov (Jira)


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

Sergey Kalashnikov commented on IGNITE-12933:
-

[~alex_pl], I've reviewed your changes, LGTM.

> Node failed after put incorrect key class for indexed type to transactional 
> cache
> -
>
> Key: IGNITE-12933
> URL: https://issues.apache.org/jira/browse/IGNITE-12933
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Node failed after put incorrect key class for indexed type to the 
> transactional cache when indexing is enabled.
> Reproducer:
> {code:java}
> public class IndexedTypesTest extends GridCommonAbstractTest {
> private boolean failed;
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler((ignite, ctx) -> failed = true)
> .setCacheConfiguration(new 
> CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setAtomicityMode(TRANSACTIONAL)
> .setIndexedTypes(String.class, String.class));
> }
> @Test
> public void testPutIndexedType() throws Exception {
> Ignite ignite = startGrids(2);
> for (int i = 0; i < 10; i++) {
> try {
> ignite.cache(DEFAULT_CACHE_NAME).put(i, "val" + i);
> }
> catch (Exception ignore) {
> }
> }
> assertFalse(failed);
> }
> }
> {code}
> Node failed with exception:
> {noformat}
> [2020-04-22 
> 17:05:34,524][ERROR][sys-stripe-11-#76%cache.IndexedTypesTest1%][IgniteTestResources]
>  Critical system error detected. Will be handled accordingly to configured 
> handler 
> [hnd=o.a.i.i.processors.cache.IndexedTypesTest$$Lambda$115/0x00080024d040@147237db,
>  failureCtx=FailureContext [type=CRITICAL_ERROR, err=class 
> o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a 
> transaction has produced runtime exception]]
> class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Committing a transaction has produced runtime exception
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
> at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838)
> at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1502)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1233)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:229)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
> index, incorrect key class [expCls=java.lang.String, 
> actualCls=java.lang.Integer]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:2223)
> at 
> 

[jira] [Commented] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric

2020-04-27 Thread Nikolay Izhikov (Jira)


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

Nikolay Izhikov commented on IGNITE-12788:
--

Hello, [~PetrovMikhail]

Can you, please, cherry-pick your fix for this issue [1] and create a PR to 
ignite-2.8.1 branch with it?



> Cluster achieved fully rebalanced (PME-free ready) state metric
> ---
>
> Key: IGNITE-12788
> URL: https://issues.apache.org/jira/browse/IGNITE-12788
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Currently, there is no metric responsible for "PME-free ready state achieved" 
> delivery.
> {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such 
> metric.
> Seems, we should update metric on each 
> {{GridDhtPartitionsExchangeFuture#onDone}}.
> P.s. Late Affinity Assignment should always set {{true}} to metric value.



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


[jira] [Assigned] (IGNITE-12933) Node failed after put incorrect key class for indexed type to transactional cache

2020-04-27 Thread Aleksey Plekhanov (Jira)


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

Aleksey Plekhanov reassigned IGNITE-12933:
--

Assignee: Aleksey Plekhanov

> Node failed after put incorrect key class for indexed type to transactional 
> cache
> -
>
> Key: IGNITE-12933
> URL: https://issues.apache.org/jira/browse/IGNITE-12933
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Node failed after put incorrect key class for indexed type to the 
> transactional cache when indexing is enabled.
> Reproducer:
> {code:java}
> public class IndexedTypesTest extends GridCommonAbstractTest {
> private boolean failed;
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler((ignite, ctx) -> failed = true)
> .setCacheConfiguration(new 
> CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setAtomicityMode(TRANSACTIONAL)
> .setIndexedTypes(String.class, String.class));
> }
> @Test
> public void testPutIndexedType() throws Exception {
> Ignite ignite = startGrids(2);
> for (int i = 0; i < 10; i++) {
> try {
> ignite.cache(DEFAULT_CACHE_NAME).put(i, "val" + i);
> }
> catch (Exception ignore) {
> }
> }
> assertFalse(failed);
> }
> }
> {code}
> Node failed with exception:
> {noformat}
> [2020-04-22 
> 17:05:34,524][ERROR][sys-stripe-11-#76%cache.IndexedTypesTest1%][IgniteTestResources]
>  Critical system error detected. Will be handled accordingly to configured 
> handler 
> [hnd=o.a.i.i.processors.cache.IndexedTypesTest$$Lambda$115/0x00080024d040@147237db,
>  failureCtx=FailureContext [type=CRITICAL_ERROR, err=class 
> o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a 
> transaction has produced runtime exception]]
> class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Committing a transaction has produced runtime exception
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
> at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838)
> at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1502)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1233)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:229)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
> index, incorrect key class [expCls=java.lang.String, 
> actualCls=java.lang.Integer]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:2223)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2092)
> at 
> 

[jira] [Commented] (IGNITE-12933) Node failed after put incorrect key class for indexed type to transactional cache

2020-04-27 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12933:


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

> Node failed after put incorrect key class for indexed type to transactional 
> cache
> -
>
> Key: IGNITE-12933
> URL: https://issues.apache.org/jira/browse/IGNITE-12933
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Node failed after put incorrect key class for indexed type to the 
> transactional cache when indexing is enabled.
> Reproducer:
> {code:java}
> public class IndexedTypesTest extends GridCommonAbstractTest {
> private boolean failed;
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler((ignite, ctx) -> failed = true)
> .setCacheConfiguration(new 
> CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setAtomicityMode(TRANSACTIONAL)
> .setIndexedTypes(String.class, String.class));
> }
> @Test
> public void testPutIndexedType() throws Exception {
> Ignite ignite = startGrids(2);
> for (int i = 0; i < 10; i++) {
> try {
> ignite.cache(DEFAULT_CACHE_NAME).put(i, "val" + i);
> }
> catch (Exception ignore) {
> }
> }
> assertFalse(failed);
> }
> }
> {code}
> Node failed with exception:
> {noformat}
> [2020-04-22 
> 17:05:34,524][ERROR][sys-stripe-11-#76%cache.IndexedTypesTest1%][IgniteTestResources]
>  Critical system error detected. Will be handled accordingly to configured 
> handler 
> [hnd=o.a.i.i.processors.cache.IndexedTypesTest$$Lambda$115/0x00080024d040@147237db,
>  failureCtx=FailureContext [type=CRITICAL_ERROR, err=class 
> o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a 
> transaction has produced runtime exception]]
> class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Committing a transaction has produced runtime exception
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
> at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838)
> at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1502)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1233)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:229)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
> index, incorrect key class [expCls=java.lang.String, 
> actualCls=java.lang.Integer]
> at 
> 

[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-27 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov commented on IGNITE-12894:
-

Hi,  [~daradurvs]. Thank you for clarification.

After some researches, I found that 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 already has a similar mechanism as you mentioned.
 But it doesn't work correctly for the time being.

[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149]
 assumes that if 
[GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93]
 equals 0 (e.g. we use 
[IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592]
 for proxy obtaining) then waiting time is not limited at all.
 But at the same time, 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 assumes that if timeout argument equals 0 then NO waiting
 is needed. The same is for 
[GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907].

Even if the behavior described above is considered valid, 
[GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169]
 throws an exception that is not ignored in case no node for the service was 
found. So no repeated attempts will be made.

So I propose to make 
[IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807]
 wait infinitely if timeout equals to 0.
 In case of using IgniteServiceProcessor, it helps to avoid using busy-wait 
loop for topology obtaining. And solves the following scenarios:
 * proxy obtaining method is called on node that did not receive service 
registration message
 * service is registered  but service initialization or coordinator full 
message awaiting was not completed

WDYT?

> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
>  Labels: sbcf
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in 
> discovery-based service deployment mode. 
>  Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to 
> switch to the discovery-based service deployment mode.
>  * Create a service initializing an {{IgniteAtomicService}} in method 
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
>  * Start an Ignite node with the service specified in the IgniteConfiguration
>  * Invoke the service's business method on the Ignite node
> h3. Actual Result
> h4. In Default Service Deployment Mode
> Deadlock on the business method invocation
> h4. In Discovery-Based Service Deployment Mode
> The method invocation fails with {{IgniteException: Failed to find deployed 
> service: IgniteTestService}}
> h2. Reproducer
> h3. Test.java
> {code:java}
> public interface Test {
> String sayHello(String name);
> }
> {code}
> h3. IgniteTestService.java
> {code:java}
> public class IgniteTestService implements Test, Service {
> private @IgniteInstanceResource Ignite ignite;
> private IgniteAtomicSequence seq;
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) throws 
> InterruptedException {
> seq = ignite.atomicSequence("TestSeq", 0, true);
> }
> @Override public void execute(ServiceContext ctx) {
> }
> @Override public String sayHello(String name) {
> return "Hello, " + name + "! #" + seq.getAndIncrement();
> }
> }
> {code}
> h3. 

[jira] [Updated] (IGNITE-12938) control.sh utility commands: IdleVerify and ValidateIndexes use eventual payload check.

2020-04-27 Thread Stanilovsky Evgeny (Jira)


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

Stanilovsky Evgeny updated IGNITE-12938:

Description: "--cache idle_verify" and "--cache validate_indexes" commands 
of *control.sh*  utility use eventual payload check during  execution. This can 
lead to execution concurrently with active payload and no errors like : 
"Checkpoint with dirty pages started! Cluster not idle"  will be triggered. 
Additionally current functional miss check on caches without persistence.  
Remove old functionality from PageMemory and move it into update counters 
usage.  (was: "Checkpoint with dirty pages started! Cluster not idle" - not 
idle detection command, but mechanism for check payload during commands 
execution. Additionally current functional miss check on caches without 
persistence.  Remove old functionality from PageMemory and move it into update 
counters usage.)

> control.sh utility commands: IdleVerify and ValidateIndexes use eventual 
> payload check.
> ---
>
> Key: IGNITE-12938
> URL: https://issues.apache.org/jira/browse/IGNITE-12938
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.9
>
>
> "--cache idle_verify" and "--cache validate_indexes" commands of *control.sh* 
>  utility use eventual payload check during  execution. This can lead to 
> execution concurrently with active payload and no errors like : "Checkpoint 
> with dirty pages started! Cluster not idle"  will be triggered. Additionally 
> current functional miss check on caches without persistence.  Remove old 
> functionality from PageMemory and move it into update counters usage.



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