date:20190422



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

Ignite TC Bot commented on IGNITE-11776:


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

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

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

> IgnitePdsStartWIthEmptyArchive is flaky
> ---
>
> Key: IGNITE-11776
> URL: https://issues.apache.org/jira/browse/IGNITE-11776
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It looks like the root cause of the issue is late registration of the 
> listener. It should be done statically via {{IgniteConfiguration}} I think.



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

[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-22 Thread Ivan Pavlukhin (JIRA)



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

Ivan Pavlukhin commented on IGNITE-11412:
-

[~ivanan.fed], yes, looks good.

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Refactor JUnit3TestLegacySupport class and remove, if it is possible.



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

[jira] [Commented] (IGNITE-11775) IgnitePdsWithTtlTest is flaky



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

Ignite TC Bot commented on IGNITE-11775:


{panel:title=--> Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=3672865]]

{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=3672868]]

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

> IgnitePdsWithTtlTest is flaky
> -
>
> Key: IGNITE-11775
> URL: https://issues.apache.org/jira/browse/IGNITE-11775
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It seems the reason for test failure is the fact that TTL manager cannot 
> clean up all entries because of TTL throttling (see 
> {{GridCacheTtlManager#expire}} and 
> {{GridCacheOffheapManager.GridCacheDataStore#purgeExpired}}). It does not 
> seem a bug/problem, it just required to set the 
> {{IgniteSystemProperties.IGNITE_UNWIND_THROTTLING_TIMEOUT}} to a smaller 
> value.



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

[jira] [Commented] (IGNITE-11277) Use maven plugin as default code style checker for project

2019-04-22 Thread Vyacheslav Daradur (JIRA)



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

Vyacheslav Daradur commented on IGNITE-11277:
-

[~Mmuzaf], the changes merged to master. 
Please mark this issue as resolved and announce on dev-list.
Thank you for contribution!

> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: inspections
> Fix For: 2.8
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough. 
> The suite has a {{FAILED}} status for more than 2 months due to some issues 
> on TeamCity application [2]. It confuses most of the members of the Apache 
> Ignite community. 
> Moreover, this suite is no longer checks configured rules. For instance, in 
> the master branch, 11 {{Unused imports}} can be found (e.g. for 
> {{IgniteCachePutAllRestartTest} 
>  [3]).
> I think the maven-checkstyle-plugin should be used as the default code style 
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1] 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29



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

[jira] [Updated] (IGNITE-11792) Web console agent throws NullPointerException if node endpoint is incorrect

2019-04-22 Thread Denis Mekhanikov (JIRA)



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

Denis Mekhanikov updated IGNITE-11792:
--
Ignite Flags:   (was: Docs Required)

> Web console agent throws NullPointerException if node endpoint is incorrect
> ---
>
> Key: IGNITE-11792
> URL: https://issues.apache.org/jira/browse/IGNITE-11792
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Priority: Major
>  Labels: web-console
>
> Starting web agent using the following command: 
> {code:bash}
> ./ignite-web-agent.sh -n localhost:8080 -s https://console.gridgain.com/
> {code}
> Note, that {{localhost:8080}} is specified without the {{http://}} part. It 
> leads to the following exception:
> {noformat}
> [ERROR][pool-1-thread-1][ClusterListener] WatchTask failed
> java.lang.NullPointerException
>   at 
> org.apache.ignite.console.agent.rest.RestExecutor.sendRequest(RestExecutor.java:185)
>   at 
> org.apache.ignite.console.agent.rest.RestExecutor.sendRequest(RestExecutor.java:237)
>   at 
> org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.restCommand(ClusterListener.java:421)
>   at 
> org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.topology(ClusterListener.java:457)
>   at 
> org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.run(ClusterListener.java:506)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The {{localhost:8080}} format should either be supported or a reasonable 
> error message should be printed.



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

[jira] [Created] (IGNITE-11792) Web console agent throws NullPointerException if node endpoint is incorrect

2019-04-22 Thread Denis Mekhanikov (JIRA)

Denis Mekhanikov created IGNITE-11792:
-

 Summary: Web console agent throws NullPointerException if node 
endpoint is incorrect
 Key: IGNITE-11792
 URL: https://issues.apache.org/jira/browse/IGNITE-11792
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Denis Mekhanikov


Starting web agent using the following command: 
{code:bash}
./ignite-web-agent.sh -n localhost:8080 -s https://console.gridgain.com/
{code}

Note, that {{localhost:8080}} is specified without the {{http://}} part. It 
leads to the following exception:
{noformat}
[ERROR][pool-1-thread-1][ClusterListener] WatchTask failed
java.lang.NullPointerException
at 
org.apache.ignite.console.agent.rest.RestExecutor.sendRequest(RestExecutor.java:185)
at 
org.apache.ignite.console.agent.rest.RestExecutor.sendRequest(RestExecutor.java:237)
at 
org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.restCommand(ClusterListener.java:421)
at 
org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.topology(ClusterListener.java:457)
at 
org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.run(ClusterListener.java:506)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}

The {{localhost:8080}} format should either be supported or a reasonable error 
message should be printed.



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

[jira] [Commented] (IGNITE-11277) Use maven plugin as default code style checker for project



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

Maxim Muzafarov commented on IGNITE-11277:
--

[~daradurvs]

I've merged the latest changes from the master branch and re-run Apache Ignite 
Build suite -- 
https://ci.ignite.apache.org/viewLog.html?buildId=3670777&buildTypeId=IgniteTests24Java8_BuildApacheIgnite

It seems to me that everything works right. Can you look at my changes again?

> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: inspections
> Fix For: 2.8
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough. 
> The suite has a {{FAILED}} status for more than 2 months due to some issues 
> on TeamCity application [2]. It confuses most of the members of the Apache 
> Ignite community. 
> Moreover, this suite is no longer checks configured rules. For instance, in 
> the master branch, 11 {{Unused imports}} can be found (e.g. for 
> {{IgniteCachePutAllRestartTest} 
>  [3]).
> I think the maven-checkstyle-plugin should be used as the default code style 
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1] 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29



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

[jira] [Commented] (IGNITE-11277) Use maven plugin as default code style checker for project



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

Maxim Muzafarov commented on IGNITE-11277:
--

[~daradurvs]

1. The {{maven-checkstyle-plugin}} has {{6.18}} by default and for some of the 
configured rules, it is work now exactly right as it expects. For instance, 
this import of EventListener is used only in Javadoc description 
[ContinuousQuery.java#L26|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/query/ContinuousQuery.java#L26]
 and is marked by this version of the plugin as {{unused}} what is not right. 
The current behaviour has been fixed 
https://github.com/checkstyle/checkstyle/issues/4606 since 8.1 version, so for 
the dependency {{com.puppycrawl.tools}} you mentioned before I've set (the 
{{latest}}) 8.19 version.

2. The plugin configuration is used in the separate profile for two common 
reasons: to speed up the local build for developers (rules checking is time 
consuming operation) and not to add an unswitchable features to the Ignites 
project code. 

> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: inspections
> Fix For: 2.8
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough. 
> The suite has a {{FAILED}} status for more than 2 months due to some issues 
> on TeamCity application [2]. It confuses most of the members of the Apache 
> Ignite community. 
> Moreover, this suite is no longer checks configured rules. For instance, in 
> the master branch, 11 {{Unused imports}} can be found (e.g. for 
> {{IgniteCachePutAllRestartTest} 
>  [3]).
> I think the maven-checkstyle-plugin should be used as the default code style 
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1] 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29



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

[jira] [Comment Edited] (IGNITE-11277) Use maven plugin as default code style checker for project



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

Maxim Muzafarov edited comment on IGNITE-11277 at 4/22/19 6:09 PM:
---

[~daradurvs]

1. The {{maven-checkstyle-plugin}} has {{6.18}} by default and for some of the 
configured rules, it is not working exactly right as it expected. For instance, 
this import of EventListener is used only in Javadoc description 
[ContinuousQuery.java#L26|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/query/ContinuousQuery.java#L26]
 and is marked by this version of the plugin as {{unused}} what is not right. 
The current behaviour has been fixed 
https://github.com/checkstyle/checkstyle/issues/4606 since 8.1 version, so for 
the dependency {{com.puppycrawl.tools}} you mentioned before I've set (the 
{{latest}}) 8.19 version.

2. The plugin configuration is used in the separate profile for two common 
reasons: to speed up the local build for developers (rules checking is time 
consuming operation) and not to add an unswitchable features to the Ignites 
project code. 


was (Author: mmuzaf):
[~daradurvs]

1. The {{maven-checkstyle-plugin}} has {{6.18}} by default and for some of the 
configured rules, it is work now exactly right as it expects. For instance, 
this import of EventListener is used only in Javadoc description 
[ContinuousQuery.java#L26|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/query/ContinuousQuery.java#L26]
 and is marked by this version of the plugin as {{unused}} what is not right. 
The current behaviour has been fixed 
https://github.com/checkstyle/checkstyle/issues/4606 since 8.1 version, so for 
the dependency {{com.puppycrawl.tools}} you mentioned before I've set (the 
{{latest}}) 8.19 version.

2. The plugin configuration is used in the separate profile for two common 
reasons: to speed up the local build for developers (rules checking is time 
consuming operation) and not to add an unswitchable features to the Ignites 
project code. 

> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: inspections
> Fix For: 2.8
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough. 
> The suite has a {{FAILED}} status for more than 2 months due to some issues 
> on TeamCity application [2]. It confuses most of the members of the Apache 
> Ignite community. 
> Moreover, this suite is no longer checks configured rules. For instance, in 
> the master branch, 11 {{Unused imports}} can be found (e.g. for 
> {{IgniteCachePutAllRestartTest} 
>  [3]).
> I think the maven-checkstyle-plugin should be used as the default code style 
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1] 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29



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

[jira] [Commented] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap in exchange history

2019-04-22 Thread Ivan Rakov (JIRA)



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

Ivan Rakov commented on IGNITE-11767:
-

[~ilyak], changes look good to me.

> GridDhtPartitionsFullMessage retains huge maps on heap in exchange history
> --
>
> Key: IGNITE-11767
> URL: https://issues.apache.org/jira/browse/IGNITE-11767
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Blocker
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> ExchangeHistory keeps a FinishState for every topology version.
> FinishState contains msg, which contains at least two huge maps:
> partCntrs2 and partsSizesBytes.
> We should probably strip msg, removing those two data structures before 
> putting msg in exchFuts linked list to be stowed away.



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

[jira] [Created] (IGNITE-11791) Fix IgnitePdsContinuousRestartTestWithExpiryPolicy

2019-04-22 Thread Alexei Scherbakov (JIRA)

Alexei Scherbakov created IGNITE-11791:
--

 Summary: Fix IgnitePdsContinuousRestartTestWithExpiryPolicy 
 Key: IGNITE-11791
 URL: https://issues.apache.org/jira/browse/IGNITE-11791
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexei Scherbakov


Test reproduces partition counter validation errors.



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

[jira] [Created] (IGNITE-11790) Optimize rebalance history calculation.

2019-04-22 Thread Alexei Scherbakov (JIRA)

Alexei Scherbakov created IGNITE-11790:
--

 Summary: Optimize rebalance history calculation.
 Key: IGNITE-11790
 URL: https://issues.apache.org/jira/browse/IGNITE-11790
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexei Scherbakov


Currently we pass initial update counters to coordinator during PME.

But this is not needed for calculation rebalance history.

It can be calculated like: maxCntr - updateCounter(last counter for sequential 
history)

 

 

 



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

[jira] [Resolved] (IGNITE-11051) Implement partition upload process as new part of GridCachePreloader



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

Maxim Muzafarov resolved IGNITE-11051.
--
   Resolution: Won't Do
Fix Version/s: None

> Implement partition upload process as new part of GridCachePreloader
> 
>
> Key: IGNITE-11051
> URL: https://issues.apache.org/jira/browse/IGNITE-11051
> Project: Ignite
>  Issue Type: Sub-task
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: iep-28
> Fix For: None
>
>
> *Preloader*
> A new implementation of cache entries preloader assume to be done. The new 
> implementation must send and receive cache partition files over the 
> CommunicationSpi channels by chunks of data with validation received items.
> The new layer over the cache partition file must support direct using of 
> FileChannel#transferTo method over the CommunicationSpi pipe connection;
> # The process manager must support transferring the cache partition file by 
> chunks of predefined size (multiply to the page size) one by one;
> # The connection bandwidth of the cache partition file transfer must have the 
> ability to be limited at runtime;



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

[jira] [Updated] (IGNITE-10619) Add support files transmission between nodes over connection via CommunicationSpi



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

Maxim Muzafarov updated IGNITE-10619:
-
Summary: Add support files transmission between nodes over connection via 
CommunicationSpi  (was: Add support for nio channel connections over 
CommunicationSpi)

> Add support files transmission between nodes over connection via 
> CommunicationSpi
> -
>
> Key: IGNITE-10619
> URL: https://issues.apache.org/jira/browse/IGNITE-10619
> Project: Ignite
>  Issue Type: Sub-task
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: iep-28
>
> To benefit from zero copy we must delegate the file transferring to 
> FileChannel#transferTo(long, long, java.nio.channels.WritableByteChannel) 
> because the fast path of transferTo method is only executed if the 
> destination buffer inherits from an internal JDK class.
> The {{CommunicationSpi}} needs to support pipe connections between two nodes;
> * The WritableByteChannel needs to be accessed on the supplier side;
> * The ReadableByteChannel needs to be read on the demander side;
> * The CommunicationListener must be extended to respond on new incoming pipe 
> connections;



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

[jira] [Updated] (IGNITE-11789) Document changes of LRT diagnostic messages made in IGNITE-11392

2019-04-22 Thread Denis Chudov (JIRA)



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

Denis Chudov updated IGNITE-11789:
--
Description: 
When LRT is detected, in the case if it is active, local node creates a request 
to near (client) node to get the dump of a thread that created the transaction. 
Dump of the client node appears in server node log.

There are methods in org.apache.ignite.mxbean.TransactionsMXBean class to allow 
and disallow thread dumps requesting:

public boolean getTxOwnerDumpRequestsAllowed() - to get information about 
whether requesting is allowed;

public void setTxOwnerDumpRequestsAllowed(boolean allowed) - to allow and 
disallow dump requests.

 

By default, dump requests are turned on.

 

  was:Additionally to log messages about detected LRTs, local node creates a 
request to near node to get the dump of a thread that created the transaction.


> Document changes of LRT diagnostic messages made in IGNITE-11392
> 
>
> Key: IGNITE-11789
> URL: https://issues.apache.org/jira/browse/IGNITE-11789
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
>
> When LRT is detected, in the case if it is active, local node creates a 
> request to near (client) node to get the dump of a thread that created the 
> transaction. Dump of the client node appears in server node log.
> There are methods in org.apache.ignite.mxbean.TransactionsMXBean class to 
> allow and disallow thread dumps requesting:
> public boolean getTxOwnerDumpRequestsAllowed() - to get information about 
> whether requesting is allowed;
> public void setTxOwnerDumpRequestsAllowed(boolean allowed) - to allow and 
> disallow dump requests.
>  
> By default, dump requests are turned on.
>  



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

[jira] [Updated] (IGNITE-11499) SQL: DML should not use batches by default

2019-04-22 Thread Alexey Goncharuk (JIRA)



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

Alexey Goncharuk updated IGNITE-11499:
--
Labels: stability  (was: )

> SQL: DML should not use batches by default
> --
>
> Key: IGNITE-11499
> URL: https://issues.apache.org/jira/browse/IGNITE-11499
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
>  Labels: stability
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently DML apply updates in batches equal to {{SqlFieldsQuery.pageSize}}. 
> This is prone to deadlocks. Instead, we should apply updates one-by-one by 
> default. Proposal:
> # Introduce {{SqlFieldsQuery.updateBatchSize}} property, set it to {{1}} by 
> default
> # Print a warning about deadlock to log if it is greater than 1
> # Add it to JDBC and ODBC drivers
> # Add it to other languages



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

[jira] [Updated] (IGNITE-11499) SQL: DML should not use batches by default

2019-04-22 Thread Alexey Goncharuk (JIRA)



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

Alexey Goncharuk updated IGNITE-11499:
--
Labels:   (was: stability)

> SQL: DML should not use batches by default
> --
>
> Key: IGNITE-11499
> URL: https://issues.apache.org/jira/browse/IGNITE-11499
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently DML apply updates in batches equal to {{SqlFieldsQuery.pageSize}}. 
> This is prone to deadlocks. Instead, we should apply updates one-by-one by 
> default. Proposal:
> # Introduce {{SqlFieldsQuery.updateBatchSize}} property, set it to {{1}} by 
> default
> # Print a warning about deadlock to log if it is greater than 1
> # Add it to JDBC and ODBC drivers
> # Add it to other languages



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

[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-22 Thread Ivan Fedotov (JIRA)



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

Ivan Fedotov commented on IGNITE-11412:
---

[~Pavlukhin], 

I think that now this ticket is completely ready.

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Refactor JUnit3TestLegacySupport class and remove, if it is possible.



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

[jira] [Updated] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-22 Thread Ivan Fedotov (JIRA)



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

Ivan Fedotov updated IGNITE-11412:
--
Description: Refactor JUnit3TestLegacySupport class and remove, if it is 
possible.  (was: Specify JUnit3TestLegacySupport class documentation.)

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Refactor JUnit3TestLegacySupport class and remove, if it is possible.



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

[jira] [Commented] (IGNITE-11142) Control.sh should print detailed information about transaction.

2019-04-22 Thread Ivan Rakov (JIRA)



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

Ivan Rakov commented on IGNITE-11142:
-

Please note: --tx-info may provide false negative search results. The problem 
is caused by the issue that FetchNearXidVersionJob is sent to only one server 
node. In case this node doesn't have specified transaction instance, command 
will result in the follwoing strange output:
{code:java}

Active transactions not found.
Will try to peek history to find out whether transaction was committed / rolled 
back.
Transaction was found in completed versions history of the following nodes:
TcpDiscoveryNode [id=78499646-f0d9-4271-a9e8-37ffafa2, 
addrs=[127.0.0.1], order=2, ver=2.8.0#20190418-sha1:176ea8de, isClient=false, 
consistentId=gridCommandHandlerTest2]:
State: ACTIVE
TcpDiscoveryNode [id=97ebe621-c4eb-4ad7-9d7a-afdef121, 
addrs=[127.0.0.1], order=3, ver=2.8.0#20190418-sha1:176ea8de, isClient=false, 
consistentId=gridCommandHandlerTest1]:
State: ACTIVE
{code}
It's definitely a bug. Will be fixed under IGNITE-11579.

> Control.sh should print detailed information about transaction.
> ---
>
> Key: IGNITE-11142
> URL: https://issues.apache.org/jira/browse/IGNITE-11142
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 7h 20m
>  Remaining Estimate: 0h
>
> We should be able to get detailed information about transactions. Approximate 
> info per node:
>  * Initiator node
>  * Transaction state
>  * Used caches
>  * Used entry keys
>  * Locked keys
>  
> Possible command: {{control.sh --tx-info --ids txid1[txid2,...txidN]}} 



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

[jira] [Comment Edited] (IGNITE-11142) Control.sh should print detailed information about transaction.

2019-04-22 Thread Ivan Rakov (JIRA)



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

Ivan Rakov edited comment on IGNITE-11142 at 4/22/19 2:05 PM:
--

Please note: --tx-info may provide false negative search results. The problem 
is caused by the issue that FetchNearXidVersionJob is sent to only one server 
node. In case this node doesn't have specified transaction instance, command 
will result in the following strange output:
{code:java}

Active transactions not found.
Will try to peek history to find out whether transaction was committed / rolled 
back.
Transaction was found in completed versions history of the following nodes:
TcpDiscoveryNode [id=78499646-f0d9-4271-a9e8-37ffafa2, 
addrs=[127.0.0.1], order=2, ver=2.8.0#20190418-sha1:176ea8de, isClient=false, 
consistentId=gridCommandHandlerTest2]:
State: ACTIVE
TcpDiscoveryNode [id=97ebe621-c4eb-4ad7-9d7a-afdef121, 
addrs=[127.0.0.1], order=3, ver=2.8.0#20190418-sha1:176ea8de, isClient=false, 
consistentId=gridCommandHandlerTest1]:
State: ACTIVE
{code}
It's definitely a bug. Will be fixed under IGNITE-11579.


was (Author: ivan.glukos):
Please note: --tx-info may provide false negative search results. The problem 
is caused by the issue that FetchNearXidVersionJob is sent to only one server 
node. In case this node doesn't have specified transaction instance, command 
will result in the follwoing strange output:
{code:java}

Active transactions not found.
Will try to peek history to find out whether transaction was committed / rolled 
back.
Transaction was found in completed versions history of the following nodes:
TcpDiscoveryNode [id=78499646-f0d9-4271-a9e8-37ffafa2, 
addrs=[127.0.0.1], order=2, ver=2.8.0#20190418-sha1:176ea8de, isClient=false, 
consistentId=gridCommandHandlerTest2]:
State: ACTIVE
TcpDiscoveryNode [id=97ebe621-c4eb-4ad7-9d7a-afdef121, 
addrs=[127.0.0.1], order=3, ver=2.8.0#20190418-sha1:176ea8de, isClient=false, 
consistentId=gridCommandHandlerTest1]:
State: ACTIVE
{code}
It's definitely a bug. Will be fixed under IGNITE-11579.

> Control.sh should print detailed information about transaction.
> ---
>
> Key: IGNITE-11142
> URL: https://issues.apache.org/jira/browse/IGNITE-11142
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 7h 20m
>  Remaining Estimate: 0h
>
> We should be able to get detailed information about transactions. Approximate 
> info per node:
>  * Initiator node
>  * Transaction state
>  * Used caches
>  * Used entry keys
>  * Locked keys
>  
> Possible command: {{control.sh --tx-info --ids txid1[txid2,...txidN]}} 



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

[jira] [Commented] (IGNITE-11579) Add new commands to deal with garbage in partitions which left after cache destroy in shared cache groups



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

Ignite TC Bot commented on IGNITE-11579:


{panel:title=--> Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=3664210]]

{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=3643589]]

{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=3663968]]
* ZookeeperDiscoverySpiTestSuite2: GridCommandHandlerTest.testTransactionInfo - 
0,0% fails in last 20 master runs.

{color:#d04437}SPI{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=3643533]]
* IgniteSpiTestSuite: 
TcpDiscoveryPendingMessageDeliveryTest.testCustomMessageInSingletonCluster - 
0,0% fails in last 125 master runs.

{color:#d04437}Cache 6{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=3643571]]
* IgniteCacheTestSuite6: 
CacheExchangeMergeTest.testFailExchangeCoordinatorChange_NoMerge_2 - 0,0% fails 
in last 124 master runs.

{color:#d04437}Cache 7{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=3663970]]
* IgniteCacheWithIndexingAndPersistenceTestSuite: 
GridCommandHandlerIndexingTest.testTransactionInfo - 0,0% fails in last 21 
master runs.

{color:#d04437}Basic 3{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=3663972]]
* IgniteBasicWithPersistenceTestSuite: 
GridCommandHandlerTest.testTransactionInfo - 0,0% fails in last 20 master runs.

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

> Add new commands to deal with garbage in partitions which left after cache 
> destroy in shared cache groups
> -
>
> Key: IGNITE-11579
> URL: https://issues.apache.org/jira/browse/IGNITE-11579
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The scenario of how to get to this situation (garbage in partition) described 
> in IGNITE-11578.
> We need to add a new command for control.sh:
> - show such keys;
> - remove such keys.



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

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

2019-04-22 Thread Anton Vinogradov (JIRA)



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

Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted

(was: {panel:title=--> Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=3663668]]

{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=3663673]]

{color:#d04437}Platform .NET{color} [[tests 152 TIMEOUT 
|https://ci.ignite.apache.org/viewLog.html?buildId=3663670]]
* exe: PartitionLossTest.TestReadOnlyAll - 75,1% fails in last 193 master runs.
* exe: PartitionLossTest.TestReadWriteAll - 66,3% fails in last 193 master runs.
* exe: PartitionLossTest.TestReadWriteSafe - 64,8% fails in last 193 master 
runs.
* exe: PartitionLossTest.TestReadOnlySafe - 63,7% fails in last 193 master runs.
* exe: CacheTest.TestAsyncCompletionOrder - 6,2% fails in last 193 master runs.
* exe: CacheTest.TestCacheNames - 5,7% fails in last 193 master runs.
* exe: ClientConnectionTest.TestAuthentication - 3,6% fails in last 193 master 
runs.
* exe: CacheTestSsl.TestPutGetUserObjects(False) - 3,1% fails in last 193 
master runs.
* exe: CacheTestKeepBinary.TestPutGetUserObjects(False) - 3,1% fails in last 
193 master runs.
* exe: CacheTest.TestClearAll - 3,1% fails in last 193 master runs.
* exe: SqlQueryTest.TestDml - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestClearKey - 3,1% fails in last 193 master runs.
* exe: CacheTestKeepBinary.TestPutIfAbsent - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestContainsKey - 3,1% fails in last 193 master runs.
* exe: CreateCacheTest.TestCreateFromConfiguration - 3,1% fails in last 193 
master runs.
* exe: CacheTest.TestContainsKeys - 3,1% fails in last 193 master runs.
* exe: CacheTestKeepBinary.TestRemove - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestExceptions - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestGetAll - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestGetAndPut - 3,1% fails in last 193 master runs.
* exe: SqlQueryTest.TestFieldsQuery - 3,1% fails in last 193 master runs.
* exe: SqlQueryTest.TestFieldsQueryCustomSchema - 3,1% fails in last 193 master 
runs.
* exe: SqlQueryTest.TestFieldsQueryDistributedJoins - 3,1% fails in last 193 
master runs.
* exe: SqlQueryTest.TestFieldsQueryMissingCache - 3,1% fails in last 193 master 
runs.
* exe: SqlQueryTest.TestFieldsQueryTimeout - 3,1% fails in last 193 master runs.
* exe: SqlQueryTest.TestSqlQuery - 3,1% fails in last 193 master runs.
* exe: SqlQueryTest.TestSqlQueryDistributedJoins - 3,1% fails in last 193 
master runs.
* exe: CacheTest.TestGetAsync - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestGetSize - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestPutAll - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestPutGetEmptyObject - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestPutGetPrimitives - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestPutIfAbsent - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestRemove - 3,1% fails in last 193 master runs.
* exe: CacheTestKeepBinary.TestRemoveReys - 3,1% fails in last 193 master runs.
* exe: ClientConnectionTest.TestEndPoints - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestGetAndPutIfAbsent - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestGetAndRemove - 3,1% fails in last 193 master runs.
* exe: ClientConnectionTest.TestFailover - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestGetAndReplace - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestGetAsync - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestGetSize - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestPutAll - 3,1% fails in last 193 master runs.
* exe: BinaryBuilderTest.TestClasslessBuilder - 3,1% fails in last 193 master 
runs.
* exe: BinaryBuilderTest.TestEnumBuilder - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestPutGetDictionary(True) - 3,1% fails in last 193 master 
runs.
* exe: CacheTest.TestPutGetDictionary(False) - 3,1% fails in last 193 master 
runs.
* exe: CreateCacheTest.TestCreateFromPartialConfiguration - 3,1% fails in last 
193 master runs.
* exe: CreateCacheTest.TestCreateFromTemplate - 3,1% fails in last 193 master 
runs.
* exe: BinaryBuilderTest.TestGetBinaryTypes - 3,1% fails in last 193 master 
runs.
* exe: BinaryBuilderTest.TestPersonBuilder - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestRemoveAll - 3,1% fails in last 193 master runs.
* exe: CreateCacheTest.TestGetCacheNames - 3,1% fails in last 193 master runs.
* exe: CacheTestKeepBinary.TestReplace - 3,1% fails in last 193 master runs.
* exe: CacheTest.TestRemoveKeyVal - 3,1% fails in last 193 master runs.
* exe: CreateCacheTest.TestGetOr

[jira] [Commented] (IGNITE-11699) Node can't start after forced shutdown if the wal archiver disabled

2019-04-22 Thread Vyacheslav Koptilin (JIRA)



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

Vyacheslav Koptilin commented on IGNITE-11699:
--

The root cause of the mentioned behavior is that {{SegmentRouter}} is not aware 
of the mode when WAL archive is disabled.
 under some circumstances, it leads to that the 
{{GridCacheDatabaseSharedManager#walTail}} may point to incorrect WAL segment 
after physical/logical restore and therefore it may break node restart 
procedure.

I have to mention the following issues as well:
 - first of all, it does not seem correct the handling of exceptions when a 
node applies physical/logical updates. For now, it ignores all runtime 
exceptions.
 - constructors of WALRecord (for example, InitNewPageRecord) may throw 
AssertionError that may break the physical/logical restore of a node.
 The corrupted entry/record may trigger assertion error that cannot be properly 
handled. So, I think we should avoid that or explicitly throw 
IgniteCheckedException instead of IgniteException, AssertionError, etc.

> Node can't start after forced shutdown if the wal archiver disabled
> ---
>
> Key: IGNITE-11699
> URL: https://issues.apache.org/jira/browse/IGNITE-11699
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.7
>Reporter: Pavel Vinokurov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Attachments: disabled-wal-archive-reproducer.zip
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a server node killed with the disabled wal archive, it could fail on start 
> with following exception:
> {code:java}
> [18:37:53,887][SEVERE][sys-stripe-1-#2][G] Failed to execute runnable.
> java.lang.IllegalStateException: Failed to get page IO instance (page content 
> is corrupted)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forVersion(IOVersions.java:85)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(IOVersions.java:97)
>   at 
> org.apache.ignite.internal.pagemem.wal.record.delta.MetaPageUpdatePartitionDataRecord.applyDelta(MetaPageUpdatePartitionDataRecord.java:109)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyPageDelta(GridCacheDatabaseSharedManager.java:2532)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.lambda$performBinaryMemoryRestore$11(GridCacheDatabaseSharedManager.java:2327)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.lambda$stripedApplyPage$12(GridCacheDatabaseSharedManager.java:2441)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.lambda$stripedApply$13(GridCacheDatabaseSharedManager.java:2479)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:550)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at java.lang.Thread.run(Thread.java:748)
> {code}
> The reproducer is attached(works only on Linux).
> Steps to run the reproducer.
> 1. Copy config/server.xml into IGNITE_HOME/config folder;
> 2. Set IGNITE_HOME in the CorruptionReproducer class;
> 3. Launch  CorruptionReproducer.



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

[jira] [Commented] (IGNITE-11499) SQL: DML should not use batches by default

2019-04-22 Thread Taras Ledkov (JIRA)



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

Taras Ledkov commented on IGNITE-11499:
---

[~jooger], the javadoc is fixed.
[~amashenkov], please review the patch.

> SQL: DML should not use batches by default
> --
>
> Key: IGNITE-11499
> URL: https://issues.apache.org/jira/browse/IGNITE-11499
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently DML apply updates in batches equal to {{SqlFieldsQuery.pageSize}}. 
> This is prone to deadlocks. Instead, we should apply updates one-by-one by 
> default. Proposal:
> # Introduce {{SqlFieldsQuery.updateBatchSize}} property, set it to {{1}} by 
> default
> # Print a warning about deadlock to log if it is greater than 1
> # Add it to JDBC and ODBC drivers
> # Add it to other languages



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

[jira] [Assigned] (IGNITE-11473) SQL: check convert to ENUM type by functions CAST, CONVERT throws sane exception



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

Yury Gerzhedovich reassigned IGNITE-11473:
--

Assignee: (was: Taras Ledkov)

> SQL: check convert to ENUM type by functions CAST, CONVERT throws sane 
> exception
> 
>
> Key: IGNITE-11473
> URL: https://issues.apache.org/jira/browse/IGNITE-11473
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Priority: Major
>
> CAST and CONVERT functions have the bug at the H2.
>  It is fixed at H2 1.4.198.
>  We have to check that the functions throws sane exception after H2 is 
> upgraded.



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

[jira] [Assigned] (IGNITE-11444) SQL: MERGE USING must throw clear exception with UNSUPPORTED error code



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

Yury Gerzhedovich reassigned IGNITE-11444:
--

Assignee: (was: Taras Ledkov)

> SQL: MERGE USING must throw clear exception with UNSUPPORTED error code
> ---
>
> Key: IGNITE-11444
> URL: https://issues.apache.org/jira/browse/IGNITE-11444
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Priority: Major
>
> The unsupported SQL statement MERGE USING throws unclear exception because H2 
> uses internal _ROWID_ column at MERGE USING implementation. Ignite tables 
> doesn't contain _ROWID_ column.
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: Column count does not match; SQL 
> statement:
> SELECT _ROWID_ FROM PARENT AS P WHERE (((P.ID = S.ID)
> AND (1 = 1))
> AND (S.ID = P.ID)) [21002-197]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
>   at org.h2.message.DbException.get(DbException.java:179)
>   at org.h2.message.DbException.get(DbException.java:155)
>   at org.h2.message.DbException.get(DbException.java:144)
>   at org.h2.command.dml.MergeUsing.prepare(MergeUsing.java:403)
>   at org.h2.command.Parser.prepareCommand(Parser.java:283)
>   at org.h2.engine.Session.prepareLocal(Session.java:611)
>   at org.h2.engine.Session.prepareCommand(Session.java:549)
>   at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
>   at 
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
>   at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
>   at 
> org.apache.ignite.internal.processors.query.h2.ConnectionManager.prepareStatementNoCache(ConnectionManager.java:363)
>   at 
> org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:264)
> {code}



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

[jira] [Updated] (IGNITE-11473) SQL: check convert to ENUM type by functions CAST, CONVERT throws sane exception



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

Yury Gerzhedovich updated IGNITE-11473:
---
Description: 
CAST and CONVERT functions have the bug at the H2.
 It is fixed at H2 1.4.198.
 We have to check that the functions throws sane exception after H2 is upgraded.

  was:
CAST and CONVERT functions have the bug at the H2.
It is  fixed at H2 1.4.198.
We have to check that the functions throws sane  exception after H@ is upgraded.


> SQL: check convert to ENUM type by functions CAST, CONVERT throws sane 
> exception
> 
>
> Key: IGNITE-11473
> URL: https://issues.apache.org/jira/browse/IGNITE-11473
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> CAST and CONVERT functions have the bug at the H2.
>  It is fixed at H2 1.4.198.
>  We have to check that the functions throws sane exception after H2 is 
> upgraded.



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

[jira] [Assigned] (IGNITE-11444) SQL: MERGE USING must throw clear exception with UNSUPPORTED error code



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

Yury Gerzhedovich reassigned IGNITE-11444:
--

Assignee: Taras Ledkov

> SQL: MERGE USING must throw clear exception with UNSUPPORTED error code
> ---
>
> Key: IGNITE-11444
> URL: https://issues.apache.org/jira/browse/IGNITE-11444
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> The unsupported SQL statement MERGE USING throws unclear exception because H2 
> uses internal _ROWID_ column at MERGE USING implementation. Ignite tables 
> doesn't contain _ROWID_ column.
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: Column count does not match; SQL 
> statement:
> SELECT _ROWID_ FROM PARENT AS P WHERE (((P.ID = S.ID)
> AND (1 = 1))
> AND (S.ID = P.ID)) [21002-197]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
>   at org.h2.message.DbException.get(DbException.java:179)
>   at org.h2.message.DbException.get(DbException.java:155)
>   at org.h2.message.DbException.get(DbException.java:144)
>   at org.h2.command.dml.MergeUsing.prepare(MergeUsing.java:403)
>   at org.h2.command.Parser.prepareCommand(Parser.java:283)
>   at org.h2.engine.Session.prepareLocal(Session.java:611)
>   at org.h2.engine.Session.prepareCommand(Session.java:549)
>   at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
>   at 
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
>   at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
>   at 
> org.apache.ignite.internal.processors.query.h2.ConnectionManager.prepareStatementNoCache(ConnectionManager.java:363)
>   at 
> org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:264)
> {code}



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

[jira] [Assigned] (IGNITE-11473) SQL: check convert to ENUM type by functions CAST, CONVERT throws sane exception



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

Yury Gerzhedovich reassigned IGNITE-11473:
--

Assignee: Taras Ledkov

> SQL: check convert to ENUM type by functions CAST, CONVERT throws sane 
> exception
> 
>
> Key: IGNITE-11473
> URL: https://issues.apache.org/jira/browse/IGNITE-11473
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> CAST and CONVERT functions have the bug at the H2.
> It is  fixed at H2 1.4.198.
> We have to check that the functions throws sane  exception after H@ is 
> upgraded.



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

[jira] [Updated] (IGNITE-11789) Document changes of LRT diagnostic messages made in IGNITE-11392

2019-04-22 Thread Denis Chudov (JIRA)



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

Denis Chudov updated IGNITE-11789:
--
Ignite Flags:   (was: Docs Required)

> Document changes of LRT diagnostic messages made in IGNITE-11392
> 
>
> Key: IGNITE-11789
> URL: https://issues.apache.org/jira/browse/IGNITE-11789
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
>
> Additionally to log messages about detected LRTs, local node creates a 
> request to near node to get the dump of a thread that created the transaction.



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

[jira] [Created] (IGNITE-11789) Document changes of LRT diagnostic messages made in IGNITE-11392

2019-04-22 Thread Denis Chudov (JIRA)

Denis Chudov created IGNITE-11789:
-

 Summary: Document changes of LRT diagnostic messages made in 
IGNITE-11392
 Key: IGNITE-11789
 URL: https://issues.apache.org/jira/browse/IGNITE-11789
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis Chudov
 Fix For: 2.8


Additionally to log messages about detected LRTs, local node creates a request 
to near node to get the dump of a thread that created the transaction.



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

[jira] [Updated] (IGNITE-11737) Apache Ignite 2.7.5 Linux packages version update



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

Dmitriy Pavlov updated IGNITE-11737:

Fix Version/s: 2.8

> Apache Ignite 2.7.5 Linux packages version update
> -
>
> Key: IGNITE-11737
> URL: https://issues.apache.org/jira/browse/IGNITE-11737
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.8, 2.7.5
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Update DEB and RPM packages' versions in Apache Ignite for the next version 
> (2.7.5)



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

[jira] [Updated] (IGNITE-11737) Apache Ignite 2.7.5 Linux packages version update



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

Dmitriy Pavlov updated IGNITE-11737:

Ignite Flags:   (was: Docs Required)

> Apache Ignite 2.7.5 Linux packages version update
> -
>
> Key: IGNITE-11737
> URL: https://issues.apache.org/jira/browse/IGNITE-11737
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.7.5
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Update DEB and RPM packages' versions in Apache Ignite for the next version 
> (2.7.5)



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

[jira] [Commented] (IGNITE-11737) Apache Ignite 2.7.5 Linux packages version update



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

Dmitriy Pavlov commented on IGNITE-11737:
-

[~vveider], should this change go to master? Or is it only 2.7.5-specific 
change?

> Apache Ignite 2.7.5 Linux packages version update
> -
>
> Key: IGNITE-11737
> URL: https://issues.apache.org/jira/browse/IGNITE-11737
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.7.5
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Update DEB and RPM packages' versions in Apache Ignite for the next version 
> (2.7.5)



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

[jira] [Commented] (IGNITE-11766) cpp: JVM library not found for openjdk 11 on windows



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

Dmitriy Pavlov commented on IGNITE-11766:
-

Cherry-picked to 2.7.5

> cpp: JVM library not found for openjdk 11 on windows
> 
>
> Key: IGNITE-11766
> URL: https://issues.apache.org/jira/browse/IGNITE-11766
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.8, 2.7.5
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to run compiled ignite.exe from platforms/cpp on windows
> {code}
> An error occurred: JVM library is not found (did you set JAVA_HOME 
> environment variable?)
> {code}
> Think problem that platforms\cpp\jni\os\win\src\utils -> JAVA_DDL = 
> "\\jre\\bin\\server\\jvm.dll" 
> searching for jre in jdk directory



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

[jira] [Updated] (IGNITE-11766) cpp: JVM library not found for openjdk 11 on windows



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

Dmitriy Pavlov updated IGNITE-11766:

Fix Version/s: 2.7.5

> cpp: JVM library not found for openjdk 11 on windows
> 
>
> Key: IGNITE-11766
> URL: https://issues.apache.org/jira/browse/IGNITE-11766
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.8, 2.7.5
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Trying to run compiled ignite.exe from platforms/cpp on windows
> {code}
> An error occurred: JVM library is not found (did you set JAVA_HOME 
> environment variable?)
> {code}
> Think problem that platforms\cpp\jni\os\win\src\utils -> JAVA_DDL = 
> "\\jre\\bin\\server\\jvm.dll" 
> searching for jre in jdk directory



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

[jira] [Updated] (IGNITE-11762) Test testClientStartCloseServersRestart causes hang of the whole Cache 2 suite in master

2019-04-22 Thread Alexey Goncharuk (JIRA)



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

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

> Test testClientStartCloseServersRestart causes hang of the whole Cache 2 
> suite in master
> 
>
> Key: IGNITE-11762
> URL: https://issues.apache.org/jira/browse/IGNITE-11762
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
>
> Attempt to restart server node in test hangs:
> {code:java}
> [2019-04-16 19:56:45,049][WARN 
> ][restart-1][GridCachePartitionExchangeManager] Failed to wait for initial 
> partition map exchange. Possible reasons are:
> ^-- Transactions in deadlock.
> ^-- Long running transactions (ignore if this is the case).
> ^-- Unreleased explicit locks.
> {code}
> The reason is that previous PME (late affinity assignment) still hangs due to 
> pending transaction:
> {code:java}
> [2019-04-16 19:56:23,717][WARN 
> ][exchange-worker-#1039%cache.IgniteClientCacheStartFailoverTest3%][diagnostic]
>  Pending transactions:
> [2019-04-16 19:56:23,718][WARN 
> ][exchange-worker-#1039%cache.IgniteClientCacheStartFailoverTest3%][diagnostic]
>  >>> [txVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
> exchWait=true, tx=GridDhtTxLocal 
> [nearNodeId=8559bfe0-3d4a-4090-a457-6df0eba5, 
> nearFutId=1edc7172a61-941f9dde-2b60-4a1f-8213-7d23d738bf33, nearMiniId=1, 
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion 
> [topVer=166913752, order=1555433759036, nodeOrder=6], lb=null, 
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, 
> nearNodes=KeySetView [], dhtNodes=KeySetView 
> [9ef33532-0e4a-4561-b57e-042afe10], explicitLock=false, 
> super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false, 
> depEnabled=false, txState=IgniteTxStateImpl [activeCacheIds=[-1062368467], 
> recovery=false, mvccEnabled=true, mvccCachingCacheIds=[], txMap=HashSet []], 
> super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=166913752, 
> order=1555433759045, nodeOrder=10], writeVer=null, implicit=false, loc=true, 
> threadId=1210, startTime=1555433762847, 
> nodeId=0088e9b8-f859-4d14-8071-6388e473, startVer=GridCacheVersion 
> [topVer=166913752, order=1555433759045, nodeOrder=10], endVer=null, 
> isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=0, 
> sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion 
> [topVer=166913752, order=1555433759045, nodeOrder=10], finalizing=NONE, 
> invalidParts=null, state=MARKED_ROLLBACK, timedOut=false, 
> topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
> mvccSnapshot=MvccSnapshotResponse [futId=292, crdVer=1555433741506, cntr=395, 
> opCntr=1, txs=[394], cleanupVer=390, tracking=0], skipCompletedVers=false, 
> parentTx=null, duration=20866ms, onePhaseCommit=false], size=0
> {code}
> However, load threads don't start any explicit transactions: they either hang 
> on put()/get() or on clientCache.close().
> Rolling back IGNITE-10799 resolves the issue (however, test remains flaky 
> with ~10% fail rate due to unhandled TransactionSerializationException).
>  



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

[jira] [Commented] (IGNITE-11103) "Control utility --cache idle_verify --dump --cache-filter ALL" comand result doesn't contain ignite-sys-cache group

2019-04-22 Thread Ilya Kasnacheev (JIRA)



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

Ilya Kasnacheev commented on IGNITE-11103:
--

C# errors ain't mine. [~ARomantsov] [~antonovsergey93] please review.

> "Control utility --cache idle_verify --dump --cache-filter ALL" comand result 
> doesn't contain ignite-sys-cache group
> 
>
> Key: IGNITE-11103
> URL: https://issues.apache.org/jira/browse/IGNITE-11103
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: ARomantsov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Look at functional add in https://issues.apache.org/jira/browse/IGNITE-9980 
> and find that issue



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

[jira] [Commented] (IGNITE-11103) "Control utility --cache idle_verify --dump --cache-filter ALL" comand result doesn't contain ignite-sys-cache group



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

Ignite TC Bot commented on IGNITE-11103:


{panel:title=--> Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests 150 TIMEOUT 
|https://ci.ignite.apache.org/viewLog.html?buildId=3665216]]
* exe: PartitionLossTest.TestReadOnlyAll - 74,1% fails in last 189 master runs.
* exe: PartitionLossTest.TestReadWriteAll - 65,1% fails in last 189 master runs.
* exe: PartitionLossTest.TestReadOnlySafe - 63,0% fails in last 189 master runs.
* exe: CacheTest.TestAsyncCompletionOrder - 6,3% fails in last 189 master runs.
* exe: CacheTest.TestCacheNames - 5,8% fails in last 189 master runs.
* exe: ClientConnectionTest.TestAuthentication - 3,7% fails in last 189 master 
runs.
* exe: CacheTestSsl.TestPutGetUserObjects(False) - 3,2% fails in last 189 
master runs.
* exe: CacheTestKeepBinary.TestPutGetUserObjects(False) - 3,2% fails in last 
189 master runs.
* exe: CacheTest.TestClearAll - 3,2% fails in last 189 master runs.
* exe: SqlQueryTest.TestDml - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestClearKey - 3,2% fails in last 189 master runs.
* exe: CacheTestKeepBinary.TestPutIfAbsent - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestContainsKey - 3,2% fails in last 189 master runs.
* exe: CreateCacheTest.TestCreateFromConfiguration - 3,2% fails in last 189 
master runs.
* exe: CacheTest.TestContainsKeys - 3,2% fails in last 189 master runs.
* exe: CacheTestKeepBinary.TestRemove - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestExceptions - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestGetAll - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestGetAndPut - 3,2% fails in last 189 master runs.
* exe: SqlQueryTest.TestFieldsQuery - 3,2% fails in last 189 master runs.
* exe: SqlQueryTest.TestFieldsQueryCustomSchema - 3,2% fails in last 189 master 
runs.
* exe: SqlQueryTest.TestFieldsQueryDistributedJoins - 3,2% fails in last 189 
master runs.
* exe: SqlQueryTest.TestFieldsQueryMissingCache - 3,2% fails in last 189 master 
runs.
* exe: SqlQueryTest.TestFieldsQueryTimeout - 3,2% fails in last 189 master runs.
* exe: SqlQueryTest.TestSqlQuery - 3,2% fails in last 189 master runs.
* exe: SqlQueryTest.TestSqlQueryDistributedJoins - 3,2% fails in last 189 
master runs.
* exe: CacheTest.TestGetAsync - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestGetSize - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestPutAll - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestPutGetEmptyObject - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestPutGetPrimitives - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestPutIfAbsent - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestRemove - 3,2% fails in last 189 master runs.
* exe: CacheTestKeepBinary.TestRemoveReys - 3,2% fails in last 189 master runs.
* exe: ClientConnectionTest.TestEndPoints - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestGetAndPutIfAbsent - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestGetAndRemove - 3,2% fails in last 189 master runs.
* exe: ClientConnectionTest.TestFailover - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestGetAndReplace - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestGetAsync - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestGetSize - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestPutAll - 3,2% fails in last 189 master runs.
* exe: BinaryBuilderTest.TestClasslessBuilder - 3,2% fails in last 189 master 
runs.
* exe: BinaryBuilderTest.TestEnumBuilder - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestPutGetDictionary(True) - 3,2% fails in last 189 master 
runs.
* exe: CacheTest.TestPutGetDictionary(False) - 3,2% fails in last 189 master 
runs.
* exe: CreateCacheTest.TestCreateFromPartialConfiguration - 3,2% fails in last 
189 master runs.
* exe: CreateCacheTest.TestCreateFromTemplate - 3,2% fails in last 189 master 
runs.
* exe: BinaryBuilderTest.TestGetBinaryTypes - 3,2% fails in last 189 master 
runs.
* exe: BinaryBuilderTest.TestPersonBuilder - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestRemoveAll - 3,2% fails in last 189 master runs.
* exe: CreateCacheTest.TestGetCacheNames - 3,2% fails in last 189 master runs.
* exe: CacheTestKeepBinary.TestReplace - 3,2% fails in last 189 master runs.
* exe: CacheTest.TestRemoveKeyVal - 3,2% fails in last 189 master runs.
* exe: CreateCacheTest.TestGetOrCreateFromConfiguration - 3,2% fails in last 
189 master runs.
* exe: CacheTestKeepBinary.TestWithKeepBinary - 3,2% fails in last 189 master 
runs.
* exe: CacheTest.TestRemoveReys - 3,2% fails in last 189 master runs.
* exe: CacheTestNoMeta.TestPutGetUserObjects - 3,2% fails in last 189 master 
runs.
* exe: CacheTest

[jira] [Comment Edited] (IGNITE-11287) JDBC Thin: best effort affinity

2019-04-22 Thread Alexander Lapin (JIRA)



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

Alexander Lapin edited comment on IGNITE-11287 at 4/22/19 9:40 AM:
---

Key points
 * IEP about affinity awareness 
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients]
 * Within jdbc thin client affinity awareness is switched off by default. In 
order to enable it please add 'affinityAwareness=true' to connection string: 
jdbc:ignite:thin://127.0.0.1:10800..10802?affinityAwareness=true
 * Jdbc thin affinity awareness is an optimization, so almost always it should 
be transparent to user. No new exceptions are expected, etc.

Test plan draft.
 # Сheck that requests go to the expected number of nodes for different 
combinations of conditions
 ** Transactional*
 *** Without params
  Select
 * Different partition tree options(All/NONE/Group/CONST) produced by 
different query types.
  DML: Update, Delete

 * - // -
 *** With params
  - // -
 ** Non-Transactional
 *** - // -
 # Check that request/response functionality works fine if server response 
lacks partition result.
 # Check that partition result is supplied only in case of rendezvous affinity 
function without custom filters.
 # Check that best effort functionality works fine for different partitions 
count.
 # Сheck that a change in topology leads to jdbc thin affinity cache 
invalidation.
 ## Topology changed during partition result retrieval.
 ## Topology changed during cache distribution retrieval.
 ## Topology changed during best-effort-affinity-unrelated query.
 # Check that jdbc thin best effort affinity works fine if cache is full and 
new data still coming. For given case we probably should decrease cache 
boundaries.
 # Check that proper connection is used if set of nodes we are connected to and 
set of nodes derived from partitions
 ## Fully intersect;
 ## Partially intersect;
 ## Doesn't intersect, i.e.
||User Specified||Derived from partitons||
|host:port1 - > UUID1
 host:port2 -> UUID2|partition1 -> UUID3|

No intersection, so random connection should be used.

 # Check client reconnection after failure.
 # Check that jdbc thin best effort affinity skipped if it is switched off.

* Please, pay attention that in case of transactions we should use sticky 
connections.


was (Author: alapin):
Test plan draft.
 # Сheck that requests go to the expected number of nodes for different 
combinations of conditions
 ** Transactional
 *** Without params
  Select
 * Different partition tree options(All/NONE/Group/CONST) produced by 
different query types.
  Dml
 * - // -
 *** With params
  - // -
 ** Non-Transactional
 *** - // -
 # Check that request/response functionality works fine if server response 
lacks partition result.
 # Check that partition result is supplied only in case of rendezvous affinity 
function without custom filters.
 # Check that best effort functionality works fine for different partitions 
count.
 # Сheck that a change in topology leads to jdbc thin affinity cache 
invalidation.
 ## Topology changed during partition result retrieval.
 ## Topology changed during cache distribution retrieval.
 ## Topology changed during best-effort-affinity-unrelated query.
 # Check that jdbc thin best effort affinity works fine if cache is full and 
new data still coming. For given case we probably should decrease cache 
boundaries.
 # Check that proper connection is used if set of nodes we are connected to and 
set of nodes derived from partitions
 ## Fully intersect;
 ## Partially intersect;
 ## Doesn't intersect, i.e.
||User Specified||Derived from partitons||
|host:port1 - > UUID1
 host:port2 -> UUID2|partition1 -> UUID3|

No intersection, so random connection should be used.

 # Check client reconnection after failure.
 # Check that jdbc thin best effort affinity skipped if it is switched off.

> JDBC Thin: best effort affinity
> ---
>
> Key: IGNITE-11287
> URL: https://issues.apache.org/jira/browse/IGNITE-11287
> Project: Ignite
>  Issue Type: New Feature
>  Components: jdbc
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
>  Labels: iep-23, iep-24
> Fix For: 2.8
>
>
> It's an umbrella ticket for implementing 
> [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients]
>  within the scope of JDBC Thin driver.



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

[jira] [Comment Edited] (IGNITE-11287) JDBC Thin: best effort affinity

2019-04-22 Thread Alexander Lapin (JIRA)

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

Alexander Lapin edited comment on IGNITE-11287 at 4/22/19 9:41 AM:
---

Key points
* IEP about affinity awareness
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients]
* Within jdbc thin client affinity awareness is switched off by default. In
order to enable it please add 'affinityAwareness=true' to connection string:
jdbc:ignite:thin://127.0.0.1:10800..10802?affinityAwareness=true
* Jdbc thin affinity awareness is an optimization, so almost always it should
be transparent to user. No new exceptions are expected, etc.

Test plan draft.
# Сheck that requests go to the expected number of nodes for different
combinations of conditions
** Transactional*
*** Without params
Select
* Different partition tree options(All/NONE/Group/CONST) produced by
different query types.
DML: Update, Delete

* - // -
*** With params
- // -
** Non-Transactional
*** - // -
# Check that request/response functionality works fine if server response
lacks partition result.
# Check that partition result is supplied only in case of rendezvous affinity
function without custom filters.
# Check that best effort functionality works fine for different partitions
count.
# Сheck that a change in topology leads to jdbc thin affinity cache
invalidation.
## Topology changed during partition result retrieval.
## Topology changed during cache distribution retrieval.
## Topology changed during best-effort-affinity-unrelated query.
# Check that jdbc thin best effort affinity works fine if cache is full and
new data still coming. For given case we probably should decrease cache
boundaries.
# Check that proper connection is used if set of nodes we are connected to and
set of nodes derived from partitions
## Fully intersect;
## Partially intersect;
## Doesn't intersect, i.e.
||User Specified||Derived from partitons||
|host:port1 - > UUID1
host:port2 -> UUID2|partition1 -> UUID3|
No intersection, so random connection should be used.
# Check client reconnection after failure.
# Check that jdbc thin best effort affinity skipped if it is switched off.

* Please, pay attention that in case of transactions we should use sticky
connections.

was (Author: alapin):
Key points
* IEP about affinity awareness
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients]
* Within jdbc thin client affinity awareness is switched off by default. In
order to enable it please add 'affinityAwareness=true' to connection string:
jdbc:ignite:thin://127.0.0.1:10800..10802?affinityAwareness=true
* Jdbc thin affinity awareness is an optimization, so almost always it should
be transparent to user. No new exceptions are expected, etc.

No intersection, so random connection should be used.

# Check client reconnection after failure.
# Check that jdbc thin best effort affinity skipped if it is switched off.

* Please, pay attention that in case of transactions we should use sticky
connections.

> JDBC Thin: best effort affinity
> ---
>
> Key: IGNITE-11287
> URL: https://issues.apache.org/jira/browse/IGNITE-11287
> Project: Ignite
> Issue Type: New Feature
> Components: jdbc
>Reporter: Alexander Lapin
>A

[jira] [Commented] (IGNITE-8788) Getting NullPointerException during commit into cassandra, after reconnecting to ignite server

2019-04-22 Thread Ilya Kasnacheev (JIRA)



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

Ilya Kasnacheev commented on IGNITE-8788:
-

I don't think that Cassandra Store should not consider fields looked up by 
getter/setter when this field is transient.

This causes other problems, such as 
https://stackoverflow.com/questions/55745205/how-to-restrict-a-column-of-my-pojo-to-be-part-of-ignite-tables

Maybe there should also be a more explicit way to exclude a field from 
Cassandra Store.

[~irudyak] is it possible to fix that behavior in this ticker or a separate one 
is needed?

> Getting NullPointerException during commit into cassandra, after reconnecting 
> to ignite server
> --
>
> Key: IGNITE-8788
> URL: https://issues.apache.org/jira/browse/IGNITE-8788
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Reporter: Yashasvi Kotamraju
>Assignee: Igor Rudyak
>Priority: Major
>
> When ignite client reconnects to restarted ignite server, while commiting 
> data into cassandra NullPointerException  is observed for random runs.
> caused by: java.lang.NullPointerException 
>         at 
> org.apache.ignite.cache.store.cassandra.persistence.PojoField.getValueFromObject(PojoField.java:167)
>  
>         at 
> org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindValues(PersistenceController.java:450)
>  
>         at 
> org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindKeyValue(PersistenceController.java:202)
>  
>         at 
> org.apache.ignite.cache.store.cassandra.session.transaction.WriteMutation.bindStatement(WriteMutation.java:58)
>  
>         at 
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:499)
>  
>  
> After going through the source code 
> there is a suspicion that its a java serialization issue in ignite cassandra 
> module 
> In org.apache.ignite.cache.store.cassandra.persistence.PojoField.java, there 
> is a PojoFieldAccessor instance variable which is transient type, so it will 
> not be part of serialization and if PojoField object is serialized and then 
> deserialized it would have PojoFieldAccessor as null. And in the Exception 
> we are seeing the same, NullPointerException when getValue(..) is called on 
> null PojoFieldAccessor in PojoField.getValueFromObject() method . So when 
> ever PojoField object is serialized and then deserialized we might be 
> observing the issue. 
> Reproducer can be found at:
> http://apache-ignite-users.70518.x6.nabble.com/Getting-NullPointerException-during-commit-into-cassandra-after-reconnecting-to-ignite-server-td22005.html
>  



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

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

2019-04-22 Thread Pavel Pereslegin (JIRA)



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

Pavel Pereslegin updated IGNITE-11584:
--
Description: 
* Implement batch insert operation into FreeList - insert several data rows at 
once
* Use batch insertion in preloader

  was:
* Implement batch insert operation into FreeList - insert several data rows at 
once
* Use batch insertion for new cache entries in preloader
* Add custom property to allow user enable batch insertion in preloader


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



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

[jira] [Commented] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions