[jira] [Commented] (IGNITE-8070) .NET: FailureHandler should be added to Ignite configuration

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy commented on IGNITE-8070:
--

[~ptupitsyn] I suppose I've corrected all issues.Could you please review again? 
TC build is attached.

> .NET: FailureHandler should be added to Ignite configuration
> 
>
> Key: IGNITE-8070
> URL: https://issues.apache.org/jira/browse/IGNITE-8070
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Andrey Gura
>Assignee: Ivan Daschinskiy
>Priority: Major
>  Labels: .NET, iep-14
>
> {{IgniteConfiguration}} class was extended by new methods: 
> {{setFailureHandler}} and {{getFailureHandler}}. Corresponding changes should 
> be done in ignite .Net 



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

[jira] [Updated] (IGNITE-8489) Web Console: Landing page does not show images under Retina display

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-8489:
-
Summary: Web Console: Landing page does not show images under Retina 
display  (was: Web Console: Landing page do not show images under Retina 
display)

> Web Console: Landing page does not show images under Retina display
> ---
>
> Key: IGNITE-8489
> URL: https://issues.apache.org/jira/browse/IGNITE-8489
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.6
>
>




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

[jira] [Created] (IGNITE-8489) Web Console: Landing page do not show images under Retina display

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8489:


 Summary: Web Console: Landing page do not show images under Retina 
display
 Key: IGNITE-8489
 URL: https://issues.apache.org/jira/browse/IGNITE-8489
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Alexey Kuznetsov
Assignee: Andrey Novikov
 Fix For: 2.6






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

[jira] [Comment Edited] (IGNITE-8350) GA Grid: Prepare documentation for 2.5

[Turik Campbell (JIRA)]

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

Turik Campbell edited comment on IGNITE-8350 at 5/15/18 3:43 AM:
-

[~dmagda], I understood the purpose of the docs were to describe how to use the 
GA Grid API.
   The GA API supports a 'single' genetic algorithm with the 
ability further customize  
   (ie: via Gene, IFitnessFunction, Crossover rate, Mutation 
rate, Selection etc)  
based on problem domain.
   The docs cover typical steps involved when using API by 
demonstrating an example:
   'HelloWorldGAExample'  -  evolve a phrase to 'Hello World'.
I guess the title could remain 'Genetic Algorithms',  if  
plan were add more examples to this page.
But, still feel comments '2-4' should be implemented.

   
   

   



was (Author: netmille):
[~dmagda], I understood the purpose of the docs were to describe how to use the 
GA Grid API.
   The GA API supports a 'single' genetic algorithm with the 
ability further customize  
   (ie: via Gene, IFitnessFunction, Crossover rate, Mutation 
rate, Selection etc)  
based on problem domain.
   The docs cover  steps involved when using API by 
demonstrating an example:
   'HelloWorldGAExample'  -  evolve a phrase to 'Hello World'.
I guess the title could remain 'Genetic Algorithms',  if  
plan were add more examples to this page.
But, still feel comments '2-4' should be implemented.

   
   

   


> GA Grid: Prepare documentation for 2.5
> --
>
> Key: IGNITE-8350
> URL: https://issues.apache.org/jira/browse/IGNITE-8350
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Turik Campbell
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.5
>
>
> Review documentation and prepare for 2.5.



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

[jira] [Commented] (IGNITE-8350) GA Grid: Prepare documentation for 2.5

[Turik Campbell (JIRA)]

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

Turik Campbell commented on IGNITE-8350:


[~dmagda], I understood the purpose of the docs were to describe how to use the 
GA Grid API.
   The GA API supports a 'single' genetic algorithm with the 
ability further customize  
   (ie: via Gene, IFitnessFunction, Crossover rate, Mutation 
rate, Selection etc)  
based on problem domain.
   The docs cover  steps involved when using API by 
demonstrating an example:
   'HelloWorldGAExample'  -  evolve a phrase to 'Hello World'.
I guess the title could remain 'Genetic Algorithms',  if  
plan were add more examples to this page.
But, still feel comments '2-4' should be implemented.

   
   

   


> GA Grid: Prepare documentation for 2.5
> --
>
> Key: IGNITE-8350
> URL: https://issues.apache.org/jira/browse/IGNITE-8350
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Turik Campbell
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.5
>
>
> Review documentation and prepare for 2.5.



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

[jira] [Created] (IGNITE-8488) Web console: scroll bar doesn't work inside cluster selector component

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8488:
--

 Summary: Web console: scroll bar doesn't work inside cluster 
selector component
 Key: IGNITE-8488
 URL: https://issues.apache.org/jira/browse/IGNITE-8488
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Ilya Borisov


List of clusters can be scrolled by mouse wheel but can't by dragging the 
scrollbar.



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

[jira] [Comment Edited] (IGNITE-8479) Web console: query text is empty on opening query section

[Ilya Borisov (JIRA)]

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

Ilya Borisov edited comment on IGNITE-8479 at 5/15/18 2:56 AM:
---

[~kuaw26] the issue was caused by another rogue animation. This class of bugs 
gets more and more annoying over time.
[~pkonstantinov] please confirm that the issue was fixed.


was (Author: klaster_1):
[~pkonstantinov] please confirm that the issue was fixed.

> Web console: query text is empty on opening query section
> -
>
> Key: IGNITE-8479
> URL: https://issues.apache.org/jira/browse/IGNITE-8479
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
> Attachments: image-2018-05-14-16-39-34-686.png
>
>
> On the first second the query text is empty and then it appears.
>  !image-2018-05-14-16-39-34-686.png! 



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

[jira] [Commented] (IGNITE-8479) Web console: query text is empty on opening query section

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-8479:
--

[~pkonstantinov] please confirm that the issue was fixed.

> Web console: query text is empty on opening query section
> -
>
> Key: IGNITE-8479
> URL: https://issues.apache.org/jira/browse/IGNITE-8479
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
> Attachments: image-2018-05-14-16-39-34-686.png
>
>
> On the first second the query text is empty and then it appears.
>  !image-2018-05-14-16-39-34-686.png! 



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

[jira] [Assigned] (IGNITE-8479) Web console: query text is empty on opening query section

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-8479:


Assignee: Alexey Kuznetsov  (was: Ilya Borisov)

> Web console: query text is empty on opening query section
> -
>
> Key: IGNITE-8479
> URL: https://issues.apache.org/jira/browse/IGNITE-8479
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.6
>
> Attachments: image-2018-05-14-16-39-34-686.png
>
>
> On the first second the query text is empty and then it appears.
>  !image-2018-05-14-16-39-34-686.png! 



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

[jira] [Assigned] (IGNITE-8479) Web console: query text is empty on opening query section

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-8479:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

> Web console: query text is empty on opening query section
> -
>
> Key: IGNITE-8479
> URL: https://issues.apache.org/jira/browse/IGNITE-8479
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
> Attachments: image-2018-05-14-16-39-34-686.png
>
>
> On the first second the query text is empty and then it appears.
>  !image-2018-05-14-16-39-34-686.png! 



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

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin commented on IGNITE-8085:


[~ivanan.fed],

Yes, right.

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Commented] (IGNITE-8436) Executor service for services does not shutdown properly

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-8436:
-

[~prabhat], you can refer to any test to get general understanding of the test 
framework used in Ignite. Should you have any questions - feel free to ask on 
the dev@ list.

As for this particular case, I'm not aware of any test that could be used as a 
reference. But I think it be fairly straightforward to create one.

> Executor service for services does not shutdown properly
> 
>
> Key: IGNITE-8436
> URL: https://issues.apache.org/jira/browse/IGNITE-8436
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Reporter: Maxim Muzafarov
>Assignee: Prabhat Ranjan
>Priority: Major
>  Labels: newbie
> Fix For: 2.6
>
>
> Issue [IGNITE-4802|https://issues.apache.org/jira/browse/IGNITE-4802] 
> introduces us separete thread pool for services execution.
> {{IgniteEx}} class defines a factory for the main Ignite API. It controls 
> Grid life cycle and allows listening for grid events. 
> As cotributor, you should ensure that execution pool shutdowns properly and 
> provide fix if needed in case stop grid instance method call occurs.
> {code:java|title=IgniteEx.java|borderStyle=solid}
> /** Executor service for services. */
> private ThreadPoolExecutor svcExecSvc;
> {code}



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

[jira] [Commented] (IGNITE-7745) JDBC: Add a note about SSL connection to docs

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7745:
-

Looks good to me, thanks.

> JDBC: Add a note about SSL connection to docs
> -
>
> Key: IGNITE-7745
> URL: https://issues.apache.org/jira/browse/IGNITE-7745
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Taras Ledkov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> JDBC thin documentation must be updated according with: IGNITE-6625



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

[jira] [Resolved] (IGNITE-7745) JDBC: Add a note about SSL connection to docs

[Denis Magda (JIRA)]

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

Denis Magda resolved IGNITE-7745.
-
Resolution: Fixed

> JDBC: Add a note about SSL connection to docs
> -
>
> Key: IGNITE-7745
> URL: https://issues.apache.org/jira/browse/IGNITE-7745
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Taras Ledkov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> JDBC thin documentation must be updated according with: IGNITE-6625



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

[jira] [Closed] (IGNITE-7745) JDBC: Add a note about SSL connection to docs

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-7745.
---

> JDBC: Add a note about SSL connection to docs
> -
>
> Key: IGNITE-7745
> URL: https://issues.apache.org/jira/browse/IGNITE-7745
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Taras Ledkov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> JDBC thin documentation must be updated according with: IGNITE-6625



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

[jira] [Commented] (IGNITE-8350) GA Grid: Prepare documentation for 2.5

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-8350:
-

[~netmille], what can't we stick to the plural form? For me, it implies that 
there are more than one genetic algorithms available as a part of the API or at 
least that you can use it for various tasks that can be solved by genetic 
algorithms.

> GA Grid: Prepare documentation for 2.5
> --
>
> Key: IGNITE-8350
> URL: https://issues.apache.org/jira/browse/IGNITE-8350
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Turik Campbell
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.5
>
>
> Review documentation and prepare for 2.5.



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

[jira] [Commented] (IGNITE-7745) JDBC: Add a note about SSL connection to docs

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-7745:
-

Reviewed and made minor edits. [~dmagda], Please do final review.

> JDBC: Add a note about SSL connection to docs
> -
>
> Key: IGNITE-7745
> URL: https://issues.apache.org/jira/browse/IGNITE-7745
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Taras Ledkov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> JDBC thin documentation must be updated according with: IGNITE-6625



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

[jira] [Assigned] (IGNITE-7745) JDBC: Add a note about SSL connection to docs

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-7745:
---

Assignee: Denis Magda  (was: Prachi Garg)

> JDBC: Add a note about SSL connection to docs
> -
>
> Key: IGNITE-7745
> URL: https://issues.apache.org/jira/browse/IGNITE-7745
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Taras Ledkov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> JDBC thin documentation must be updated according with: IGNITE-6625



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

[jira] [Commented] (IGNITE-8436) Executor service for services does not shutdown properly

[Prabhat Ranjan (JIRA)]

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

Prabhat Ranjan commented on IGNITE-8436:


Sure [~vkulichenko], I will create new test to check no thread ( or thread pool 
)  is active after node stop. Do you know of  any similar test which I can 
refer to ?

> Executor service for services does not shutdown properly
> 
>
> Key: IGNITE-8436
> URL: https://issues.apache.org/jira/browse/IGNITE-8436
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Reporter: Maxim Muzafarov
>Assignee: Prabhat Ranjan
>Priority: Major
>  Labels: newbie
> Fix For: 2.6
>
>
> Issue [IGNITE-4802|https://issues.apache.org/jira/browse/IGNITE-4802] 
> introduces us separete thread pool for services execution.
> {{IgniteEx}} class defines a factory for the main Ignite API. It controls 
> Grid life cycle and allows listening for grid events. 
> As cotributor, you should ensure that execution pool shutdowns properly and 
> provide fix if needed in case stop grid instance method call occurs.
> {code:java|title=IgniteEx.java|borderStyle=solid}
> /** Executor service for services. */
> private ThreadPoolExecutor svcExecSvc;
> {code}



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

[jira] [Commented] (IGNITE-8350) GA Grid: Prepare documentation for 2.5

[Turik Campbell (JIRA)]

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

Turik Campbell commented on IGNITE-8350:


[~dmagda], Upon review of the recent edits,it seems that following changes 
should be made:

  1. "Genetic Algorithms" to "Genetic Algorithm"  (ie: title).. As former 
implies plural.
  2. "..Genetic Algorithms (GA) represent a subset of Ignite Machine Learning 
APIs."
 changed to:
  "..Genetic Algorithm (GA) represent a subset of Ignite Machine Learning 
APIs..."

  3. "...The following diagram depicts the steps performed by Genetic 
Algorithms.."   
 changed to :
 "...The following diagram depicts the steps performed by the Genetic 
Algorithm"
  3. "..In order to begin using Genetic Algorithms.." change to "..In order to 
begin using the Genetic Algorithm.."

> GA Grid: Prepare documentation for 2.5
> --
>
> Key: IGNITE-8350
> URL: https://issues.apache.org/jira/browse/IGNITE-8350
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Turik Campbell
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.5
>
>
> Review documentation and prepare for 2.5.



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

[jira] [Comment Edited] (IGNITE-8350) GA Grid: Prepare documentation for 2.5

[Turik Campbell (JIRA)]

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

Turik Campbell edited comment on IGNITE-8350 at 5/14/18 8:46 PM:
-

[~dmagda], Upon review of the recent edits,it seems that following changes 
should be made:

  1. "Genetic Algorithms" to "Genetic Algorithm"  (ie: title).. As former 
implies plural.
  2. "..Genetic Algorithms (GA) represent a subset of Ignite Machine Learning 
APIs."
 changed to:
  "..Genetic Algorithm (GA) represent a subset of Ignite Machine Learning 
APIs..."

  3. "...The following diagram depicts the steps performed by Genetic 
Algorithms.."   
 changed to :
 "...The following diagram depicts the steps performed by the Genetic 
Algorithm"
  4. "..In order to begin using Genetic Algorithms.." change to "..In order to 
begin using the Genetic Algorithm.."


was (Author: netmille):
[~dmagda], Upon review of the recent edits,it seems that following changes 
should be made:

  1. "Genetic Algorithms" to "Genetic Algorithm"  (ie: title).. As former 
implies plural.
  2. "..Genetic Algorithms (GA) represent a subset of Ignite Machine Learning 
APIs."
 changed to:
  "..Genetic Algorithm (GA) represent a subset of Ignite Machine Learning 
APIs..."

  3. "...The following diagram depicts the steps performed by Genetic 
Algorithms.."   
 changed to :
 "...The following diagram depicts the steps performed by the Genetic 
Algorithm"
  3. "..In order to begin using Genetic Algorithms.." change to "..In order to 
begin using the Genetic Algorithm.."

> GA Grid: Prepare documentation for 2.5
> --
>
> Key: IGNITE-8350
> URL: https://issues.apache.org/jira/browse/IGNITE-8350
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Turik Campbell
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.5
>
>
> Review documentation and prepare for 2.5.



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

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

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

Ivan Fedotov commented on IGNITE-8085:
--

[~ein], thank you for description!

I correctly understand, that increasing of  NODE_START_CHECK_LIMIT will be 
enough in this case?

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Commented] (IGNITE-8350) GA Grid: Prepare documentation for 2.5

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-8350:
-

Reviewed and made several edits.

[~dmagda], please do a final review.

> GA Grid: Prepare documentation for 2.5
> --
>
> Key: IGNITE-8350
> URL: https://issues.apache.org/jira/browse/IGNITE-8350
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Turik Campbell
>Assignee: Prachi Garg
>Priority: Minor
> Fix For: 2.5
>
>
> Review documentation and prepare for 2.5.



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

[jira] [Assigned] (IGNITE-8350) GA Grid: Prepare documentation for 2.5

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-8350:
---

Assignee: Denis Magda  (was: Prachi Garg)

> GA Grid: Prepare documentation for 2.5
> --
>
> Key: IGNITE-8350
> URL: https://issues.apache.org/jira/browse/IGNITE-8350
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Turik Campbell
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.5
>
>
> Review documentation and prepare for 2.5.



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

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin commented on IGNITE-8085:


[~dpavlov], remote process startup procedure does the simple assumption - 
{{SUCCESSFUL_START_MSG}} have to occurs in the startup log (remote process 
output), so the local process wait for the occurrence scanning the log 
{{NODE_START_CHECK_LIMIT}}-times with {{NODE_START_CHECK_PERIOD}}-delay. Remote 
process may not had enougth time to finish startup sequence, making mistaken 
failure. You may sure of that looking at the test run artifacts.

In such situations preferred to increase {{NODE_START_CHECK_LIMIT}}. Increasing 
{{NODE_START_CHECK_PERIOD}} is not recommended as this lengthens successfully 
ran tests.

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Commented] (IGNITE-8486) Update ConcurrentLinkedDeque in Ignite's master repository to the latest JDK version

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8486:


GitHub user slukyano opened a pull request:

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

IGNITE-8486: Updated ConcurrentLinkedDeque8 to match the latest version in 
JSR 166 repo.



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

$ git pull https://github.com/gridgain/apache-ignite ignite-8486

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

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

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

This closes #3995


commit e5704f9975de02fa08a8f9c3cee58bc1c83d6ddd
Author: Stanislav Lukyanov 
Date:   2018-05-14T16:06:48Z

IGNITE-8486: Updated ConcurrentLinkedDeque8 to match the latest version in 
JSR 166 repo.




> Update ConcurrentLinkedDeque in Ignite's master repository to the latest JDK 
> version
> 
>
> Key: IGNITE-8486
> URL: https://issues.apache.org/jira/browse/IGNITE-8486
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
>
> Ignite still uses copies of several JSR 166 (j.u.concurrent) classes in it's 
> sources. Those copies are now outdated compared to the latest versions used 
> in JDK.
> In particular, `ConcurrentLinkedDeque` has received a couple of correctness 
> fixes recently (https://bugs.openjdk.java.net/browse/JDK-8188900, 
> https://bugs.openjdk.java.net/browse/JDK-8189387). It would be good to have 
> them in Ignite as well to protect ourselves from possible issues.
> The task is to update Ignite's `ConcurrentLinkedDeque8` to the latest version 
> of `ConcurrentLinkedDeque`, although keeping compatibility with earlier Java 
> version (e.g. JDK's version now uses Java 9's VarHandles which we can't use 
> yet).



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

[jira] [Updated] (IGNITE-8487) ZookeeperDiscoverySpi tests should use tmpfs on public TC

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8487:
---
Fix Version/s: 2.6

> ZookeeperDiscoverySpi tests should use tmpfs on public TC
> -
>
> Key: IGNITE-8487
> URL: https://issues.apache.org/jira/browse/IGNITE-8487
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.6
>
>
> ZookeeperDiscoverySpi suites don't look very stable on TC these failures are 
> flaky.
> As ZooKeeper persists data to disk slow disks on TC agents may contribute to 
> these flaky failures.
> Zookeeper tests should configure internal ZooKeeper instances to use tmpfs 
> available on some TC agents to avoid failures because of slow ZooKeeper 
> cluster.



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

[jira] [Commented] (IGNITE-8487) ZookeeperDiscoverySpi tests should use tmpfs on public TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8487:


Github user asfgit closed the pull request at:

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


> ZookeeperDiscoverySpi tests should use tmpfs on public TC
> -
>
> Key: IGNITE-8487
> URL: https://issues.apache.org/jira/browse/IGNITE-8487
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>
> ZookeeperDiscoverySpi suites don't look very stable on TC these failures are 
> flaky.
> As ZooKeeper persists data to disk slow disks on TC agents may contribute to 
> these flaky failures.
> Zookeeper tests should configure internal ZooKeeper instances to use tmpfs 
> available on some TC agents to avoid failures because of slow ZooKeeper 
> cluster.



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

[jira] [Commented] (IGNITE-8487) ZookeeperDiscoverySpi tests should use tmpfs on public TC

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8487:


I've merged PR to master and checked both configs
https://ci.ignite.apache.org/admin/editBuildParams.html?id=buildType:IgniteTests24Java8_ZooKeeperDiscovery1
https://ci.ignite.apache.org/admin/editBuildParams.html?id=buildType:IgniteTests24Java8_ZooKeeperDiscovery2
It seems all changes are OK, but let's keep an eye on these suite resuits


> ZookeeperDiscoverySpi tests should use tmpfs on public TC
> -
>
> Key: IGNITE-8487
> URL: https://issues.apache.org/jira/browse/IGNITE-8487
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>
> ZookeeperDiscoverySpi suites don't look very stable on TC these failures are 
> flaky.
> As ZooKeeper persists data to disk slow disks on TC agents may contribute to 
> these flaky failures.
> Zookeeper tests should configure internal ZooKeeper instances to use tmpfs 
> available on some TC agents to avoid failures because of slow ZooKeeper 
> cluster.



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

[jira] [Commented] (IGNITE-8487) ZookeeperDiscoverySpi tests should use tmpfs on public TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8487:


GitHub user sergey-chugunov-1985 opened a pull request:

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

IGNITE-8487 tmpfs is employed by ZooKeeper tests



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

$ git pull https://github.com/gridgain/apache-ignite ignite-8487

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

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

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

This closes #3994


commit 215c4e0658fb4da554db084158c7013e92a446d2
Author: Sergey Chugunov 
Date:   2018-05-14T16:45:54Z

IGNITE-8487 tmpfs is employed by ZooKeeper tests




> ZookeeperDiscoverySpi tests should use tmpfs on public TC
> -
>
> Key: IGNITE-8487
> URL: https://issues.apache.org/jira/browse/IGNITE-8487
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>
> ZookeeperDiscoverySpi suites don't look very stable on TC these failures are 
> flaky.
> As ZooKeeper persists data to disk slow disks on TC agents may contribute to 
> these flaky failures.
> Zookeeper tests should configure internal ZooKeeper instances to use tmpfs 
> available on some TC agents to avoid failures because of slow ZooKeeper 
> cluster.



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

[jira] [Commented] (IGNITE-1793) [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-1793:


I've unmuted this test and it is still failing  ( ~6/100 runs)

It does not hang suite, so I'm not sure we can close issue for now. I can merge 
this PR, but it won't be a fix to test failure

> [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC 
> sometimes
> -
>
> Key: IGNITE-1793
> URL: https://issues.apache.org/jira/browse/IGNITE-1793
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Attachments: test.logs
>
>
> IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes.
> Test hangs on IgniteCountDownLatch.count() method.
> {noformat}
> Thread [name="test-runner", id=24157, state=WAITING, blockCnt=0, waitCnt=96]
> Lock [object=o.a.i.i.util.future.GridFutureAdapter$ChainFuture@1e542154, 
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4525)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1544)
> at 
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:348)
> at 
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:342)
> at 
> o.a.i.i.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:962)
> at 
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl.count(GridCacheCountDownLatchImpl.java:143)
> at 
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkRemovedLatch(IgniteCountDownLatchAbstractSelfTest.java:159)
> at 
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkCountDown(IgniteCountDownLatchAbstractSelfTest.java:232)
> at 
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkLatch(IgniteCountDownLatchAbstractSelfTest.java:84)
> at 
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.testLatch(IgniteCountDownLatchAbstractSelfTest.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at 
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at 
> o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> {noformat}



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

[jira] [Updated] (IGNITE-8473) Add option to enable/disable WAL for several caches with single command

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-8473:
---
Description: 
API method for disabling WAL in IgniteCluster accepts only one cache name. 
Every call triggers exchange and checkpoints cluster-wide - it takes plenty of 
time to disable/enable WAL for multiple caches.
We should add option to disable/enable WAL for several caches with single 
command. 

New proposed API methods:
{noformat}
IgniteCluster.disableWal(Collection cacheNames)
IgniteCluster.enableWal(Collection cacheNames)
IgniteCluster.disableWal() // Disables WAL for all caches.
IgniteCluster.enableWal() // Enables WAL for all caches.
{noformat}
Methods should return true if WAL state of at least one cache was actually 
changed by the call.

  was:
API method for disabling WAL in IgniteCluster accepts only one cache name. 
Every call triggers exchange and checkpoints cluster-wide - it takes plenty of 
time to disable/enable WAL for multiple caches.
We should add option to disable/enable WAL for several caches with single 
command. 

New proposed API methods:
{noformat}
IgniteCluster.disableWal(Collection cacheNames)
IgniteCluster.enableWal(Collection cacheNames)
IgniteCluster.disableWal()
IgniteCluster.enableWal()
{noformat}
Methods should return true if WAL state of at least one cache was actually 
changed by the call.


> Add option to enable/disable WAL for several caches with single command
> ---
>
> Key: IGNITE-8473
> URL: https://issues.apache.org/jira/browse/IGNITE-8473
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> API method for disabling WAL in IgniteCluster accepts only one cache name. 
> Every call triggers exchange and checkpoints cluster-wide - it takes plenty 
> of time to disable/enable WAL for multiple caches.
> We should add option to disable/enable WAL for several caches with single 
> command. 
> New proposed API methods:
> {noformat}
> IgniteCluster.disableWal(Collection cacheNames)
> IgniteCluster.enableWal(Collection cacheNames)
> IgniteCluster.disableWal() // Disables WAL for all caches.
> IgniteCluster.enableWal() // Enables WAL for all caches.
> {noformat}
> Methods should return true if WAL state of at least one cache was actually 
> changed by the call.



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

[jira] [Updated] (IGNITE-8473) Add option to enable/disable WAL for several caches with single command

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-8473:
---
Description: 
API method for disabling WAL in IgniteCluster accepts only one cache name. 
Every call triggers exchange and checkpoints cluster-wide - it takes plenty of 
time to disable/enable WAL for multiple caches.
We should add option to disable/enable WAL for several caches with single 
command. 

New proposed API methods:
IgniteCluster.disableWal(Collection cacheNames)
IgniteCluster.enableWal(Collection cacheNames)
IgniteCluster.disableWal()
IgniteCluster.enableWal()

Methods should return true if WAL state of at least one cache was actually 
changed by the call.

  was:
API method for disabling WAL in IgniteCluster accepts only one cache name. 
Every call triggers exchange and checkpoints cluster-wide - it takes plenty of 
time to disable/enable WAL for multiple caches.
We should add option to disable/enable WAL for several caches with single 
command. 

New proposed API methods:
IgniteCluster.disableWal(Collection cacheNames)
IgniteCluster.enableWal(Collection cacheNames)


> Add option to enable/disable WAL for several caches with single command
> ---
>
> Key: IGNITE-8473
> URL: https://issues.apache.org/jira/browse/IGNITE-8473
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> API method for disabling WAL in IgniteCluster accepts only one cache name. 
> Every call triggers exchange and checkpoints cluster-wide - it takes plenty 
> of time to disable/enable WAL for multiple caches.
> We should add option to disable/enable WAL for several caches with single 
> command. 
> New proposed API methods:
> IgniteCluster.disableWal(Collection cacheNames)
> IgniteCluster.enableWal(Collection cacheNames)
> IgniteCluster.disableWal()
> IgniteCluster.enableWal()
> Methods should return true if WAL state of at least one cache was actually 
> changed by the call.



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

[jira] [Updated] (IGNITE-8473) Add option to enable/disable WAL for several caches with single command

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-8473:
---
Description: 
API method for disabling WAL in IgniteCluster accepts only one cache name. 
Every call triggers exchange and checkpoints cluster-wide - it takes plenty of 
time to disable/enable WAL for multiple caches.
We should add option to disable/enable WAL for several caches with single 
command. 

New proposed API methods:
{noformat}
IgniteCluster.disableWal(Collection cacheNames)
IgniteCluster.enableWal(Collection cacheNames)
IgniteCluster.disableWal()
IgniteCluster.enableWal()
{noformat}
Methods should return true if WAL state of at least one cache was actually 
changed by the call.

  was:
API method for disabling WAL in IgniteCluster accepts only one cache name. 
Every call triggers exchange and checkpoints cluster-wide - it takes plenty of 
time to disable/enable WAL for multiple caches.
We should add option to disable/enable WAL for several caches with single 
command. 

New proposed API methods:
IgniteCluster.disableWal(Collection cacheNames)
IgniteCluster.enableWal(Collection cacheNames)
IgniteCluster.disableWal()
IgniteCluster.enableWal()

Methods should return true if WAL state of at least one cache was actually 
changed by the call.


> Add option to enable/disable WAL for several caches with single command
> ---
>
> Key: IGNITE-8473
> URL: https://issues.apache.org/jira/browse/IGNITE-8473
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> API method for disabling WAL in IgniteCluster accepts only one cache name. 
> Every call triggers exchange and checkpoints cluster-wide - it takes plenty 
> of time to disable/enable WAL for multiple caches.
> We should add option to disable/enable WAL for several caches with single 
> command. 
> New proposed API methods:
> {noformat}
> IgniteCluster.disableWal(Collection cacheNames)
> IgniteCluster.enableWal(Collection cacheNames)
> IgniteCluster.disableWal()
> IgniteCluster.enableWal()
> {noformat}
> Methods should return true if WAL state of at least one cache was actually 
> changed by the call.



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

[jira] [Created] (IGNITE-8487) ZookeeperDiscoverySpi tests should use tmpfs on public TC

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-8487:
---

 Summary: ZookeeperDiscoverySpi tests should use tmpfs on public TC
 Key: IGNITE-8487
 URL: https://issues.apache.org/jira/browse/IGNITE-8487
 Project: Ignite
  Issue Type: Task
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov


ZookeeperDiscoverySpi suites don't look very stable on TC these failures are 
flaky.

As ZooKeeper persists data to disk slow disks on TC agents may contribute to 
these flaky failures.

Zookeeper tests should configure internal ZooKeeper instances to use tmpfs 
available on some TC agents to avoid failures because of slow ZooKeeper cluster.



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

[jira] [Commented] (IGNITE-8469) Non-heap memroy leak for calling cluster activation multi times

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8469:


Github user Mmuzaf closed the pull request at:

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


> Non-heap memroy leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.6
>
>
> Calling multiple time cluster (with enabled persistence and started client 
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory 
> leak.
> Line 
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} 
> looks suspicious because of in case method 
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} 
> callled multi times (e.g. activate(true) called multi times) we lost info 
> about allocated regions.



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

[jira] [Assigned] (IGNITE-8384) SQL: Secondary indexes should sort entries by links rather than keys

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko reassigned IGNITE-8384:
---

Assignee: Alexander Paschenko

> SQL: Secondary indexes should sort entries by links rather than keys
> 
>
> Key: IGNITE-8384
> URL: https://issues.apache.org/jira/browse/IGNITE-8384
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
>  Labels: iep-19, performance
> Fix For: 2.6
>
>
> Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The 
> key itself is not stored in the index in general case. It means that we need 
> to perform a lookup to data page to find correct insertion point for index 
> entry.
> This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
> link}}. This is all we need.
> UPD: If we have an affinity keys, then affinity column will be added to 
> secondary index as well. 
>  So, we'll have secondary index as  {{(idx_cols, KEY, AFF_COL)}}
> Comparison occur here: 
> {{org.apache.ignite.internal.processors.query.h2.database.H2Tree#compare}}
> What we need is to avoid adding PK and affinity key columns to every 
> secondary index and compare links instead in this method.
> Probably we need to preserve old behavior for compatibility purposes.



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

[jira] [Commented] (IGNITE-8407) Wrong memory size printing in IgniteCacheDatabaseSnaredManager

[Sergey Nuyanzin (JIRA)]

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

Sergey Nuyanzin commented on IGNITE-8407:
-

Hello [~sbberkov] 
could you please have a look at changes ?

> Wrong memory size printing in IgniteCacheDatabaseSnaredManager
> --
>
> Key: IGNITE-8407
> URL: https://issues.apache.org/jira/browse/IGNITE-8407
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Trivial
>
> In checkDataRegionSize regCfg printing in "si" format (based on 1000, not 
> 1024). Need to fix it and any other usages of getInitialSize()/getMaxSize()) 
> with U.readableSize(*, true) 
> {noformat}
> throw new IgniteCheckedException("DataRegion must have size more than 10MB 
> (use " +
> "DataRegionConfiguration.initialSize and .maxSize properties 
> to set correct size in bytes) " +
> "[name=" + regCfg.getName() + ", initialSize=" + 
> U.readableSize(regCfg.getInitialSize(), true) +
> ", maxSize=" + U.readableSize(regCfg.getMaxSize(), true) + "]"
> {noformat}
> should be replaced with
> {noformat}
> throw new IgniteCheckedException("DataRegion must have size more than 10MB 
> (use " +
> "DataRegionConfiguration.initialSize and .maxSize properties 
> to set correct size in bytes) " +
> "[name=" + regCfg.getName() + ", initialSize=" + 
> U.readableSize(regCfg.getInitialSize(), false) +
> ", maxSize=" + U.readableSize(regCfg.getMaxSize(), false) + 
> "]"
> {noformat}



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

[jira] [Created] (IGNITE-8486) Update ConcurrentLinkedDeque in Ignite's master repository to the latest JDK version

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-8486:
--

 Summary: Update ConcurrentLinkedDeque in Ignite's master 
repository to the latest JDK version
 Key: IGNITE-8486
 URL: https://issues.apache.org/jira/browse/IGNITE-8486
 Project: Ignite
  Issue Type: Improvement
Reporter: Stanislav Lukyanov
Assignee: Stanislav Lukyanov


Ignite still uses copies of several JSR 166 (j.u.concurrent) classes in it's 
sources. Those copies are now outdated compared to the latest versions used in 
JDK.
In particular, `ConcurrentLinkedDeque` has received a couple of correctness 
fixes recently (https://bugs.openjdk.java.net/browse/JDK-8188900, 
https://bugs.openjdk.java.net/browse/JDK-8189387). It would be good to have 
them in Ignite as well to protect ourselves from possible issues.

The task is to update Ignite's `ConcurrentLinkedDeque8` to the latest version 
of `ConcurrentLinkedDeque`, although keeping compatibility with earlier Java 
version (e.g. JDK's version now uses Java 9's VarHandles which we can't use 
yet).



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

[jira] [Updated] (IGNITE-8484) Web Console lacks 'collocated' flag on SQL query tab

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-8484:

Component/s: wizards

> Web Console lacks 'collocated' flag on SQL query tab
> 
>
> Key: IGNITE-8484
> URL: https://issues.apache.org/jira/browse/IGNITE-8484
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> For some queries, this flag is needed to avoid endless running and/or memory 
> depletion.
> There's setEnforceJoinOrder() flag and setDistributedJoins() flag but not 
> setCollocated() flag.



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

[jira] [Assigned] (IGNITE-8484) Web Console lacks 'collocated' flag on SQL query tab

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-8484:


Assignee: Alexey Kuznetsov

> Web Console lacks 'collocated' flag on SQL query tab
> 
>
> Key: IGNITE-8484
> URL: https://issues.apache.org/jira/browse/IGNITE-8484
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> For some queries, this flag is needed to avoid endless running and/or memory 
> depletion.
> There's setEnforceJoinOrder() flag and setDistributedJoins() flag but not 
> setCollocated() flag.



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

[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7993:


Hi [~yzhdanov], could you please check that your proposals were applied as you 
have suggested.

> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.6
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped 
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following 
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid 
> stripedPool thread pool size (must be greater than 0), actual value: 0
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
>   at org.apache.ignite.Ignition.start(Ignition.java:322)
>   ... 7 more
> {noformat}



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5965:


Github user asfgit closed the pull request at:

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


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



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

[jira] [Created] (IGNITE-8485) TDE - Phase-1

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-8485:
---

 Summary: TDE - Phase-1
 Key: IGNITE-8485
 URL: https://issues.apache.org/jira/browse/IGNITE-8485
 Project: Ignite
  Issue Type: Sub-task
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
 Fix For: 2.6


Basic support for a Transparent Data Encryption should be implemented:

1. Usage of standard JKS, Java Security.

2. Persistent Data Encryption/Decryption.



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

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

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5965:
---
Fix Version/s: 2.6

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



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

[jira] [Closed] (IGNITE-8265) TDE - MEK replacement

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov closed IGNITE-8265.
---

> TDE - MEK replacement
> -
>
> Key: IGNITE-8265
> URL: https://issues.apache.org/jira/browse/IGNITE-8265
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-18
>
> If MEK is lost or stolen while the cluster is alive, TDE should provide way 
> to replace(regenerate) MEK.



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

[jira] [Resolved] (IGNITE-8265) TDE - MEK replacement

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov resolved IGNITE-8265.
-
Resolution: Invalid

> TDE - MEK replacement
> -
>
> Key: IGNITE-8265
> URL: https://issues.apache.org/jira/browse/IGNITE-8265
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-18
>
> If MEK is lost or stolen while the cluster is alive, TDE should provide way 
> to replace(regenerate) MEK.



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

[jira] [Resolved] (IGNITE-8262) TDE - MEK and CEK processing

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov resolved IGNITE-8262.
-
Resolution: Invalid

> TDE - MEK and CEK processing
> 
>
> Key: IGNITE-8262
> URL: https://issues.apache.org/jira/browse/IGNITE-8262
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-18
>
> To get TDE working we should implement managing MEK and CEK's
> * MEK should be loaded from configured KeyStore
> * CEK's should be stored in some internal data storage and be encrypted with 
> MEK.
> * Cluster shouldn't get activated before MEK are loaded.



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

[jira] [Closed] (IGNITE-8261) TDE - Configuration

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov closed IGNITE-8261.
---

> TDE - Configuration
> ---
>
> Key: IGNITE-8261
> URL: https://issues.apache.org/jira/browse/IGNITE-8261
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-18
> Fix For: 2.6
>
>
> Ignite configuration should be extended to support all TDE specific 
> configuration parameters: 
> * KeyStore configuration. 
> * Default KeyStore implementation should use JDK provided KeyStore - 
> https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html. 
> * Other(not default) implementation of KeyStore should be allowed.
> * New option for encrypted caches.



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

[jira] [Closed] (IGNITE-8263) TDE - Encryption/Decryption of pages

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov closed IGNITE-8263.
---

> TDE - Encryption/Decryption of pages
> 
>
> Key: IGNITE-8263
> URL: https://issues.apache.org/jira/browse/IGNITE-8263
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-18
> Fix For: 2.6
>
>
> When data for an encrypted cache are written to the persistence store. 
> Data page should be encrypted through configured encryption provider. 
> * Encryption/decryption should be implemented



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

[jira] [Resolved] (IGNITE-8263) TDE - Encryption/Decryption of pages

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov resolved IGNITE-8263.
-
Resolution: Invalid

> TDE - Encryption/Decryption of pages
> 
>
> Key: IGNITE-8263
> URL: https://issues.apache.org/jira/browse/IGNITE-8263
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-18
> Fix For: 2.6
>
>
> When data for an encrypted cache are written to the persistence store. 
> Data page should be encrypted through configured encryption provider. 
> * Encryption/decryption should be implemented



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

[jira] [Resolved] (IGNITE-8261) TDE - Configuration

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov resolved IGNITE-8261.
-
Resolution: Invalid

> TDE - Configuration
> ---
>
> Key: IGNITE-8261
> URL: https://issues.apache.org/jira/browse/IGNITE-8261
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-18
> Fix For: 2.6
>
>
> Ignite configuration should be extended to support all TDE specific 
> configuration parameters: 
> * KeyStore configuration. 
> * Default KeyStore implementation should use JDK provided KeyStore - 
> https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html. 
> * Other(not default) implementation of KeyStore should be allowed.
> * New option for encrypted caches.



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

[jira] [Closed] (IGNITE-8262) TDE - MEK and CEK processing

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov closed IGNITE-8262.
---

> TDE - MEK and CEK processing
> 
>
> Key: IGNITE-8262
> URL: https://issues.apache.org/jira/browse/IGNITE-8262
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-18
>
> To get TDE working we should implement managing MEK and CEK's
> * MEK should be loaded from configured KeyStore
> * CEK's should be stored in some internal data storage and be encrypted with 
> MEK.
> * Cluster shouldn't get activated before MEK are loaded.



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

[jira] [Closed] (IGNITE-8264) TDE - Node join enhanecements

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov closed IGNITE-8264.
---

> TDE - Node join enhanecements
> -
>
> Key: IGNITE-8264
> URL: https://issues.apache.org/jira/browse/IGNITE-8264
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-18
>
> All nodes that are joined to the cluster with TDE enabled should be 
> configured to get TDE working. 
> They need access to MEK and CEK's. 
> We should extend node join mechanism to support TDE.



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

[jira] [Resolved] (IGNITE-8264) TDE - Node join enhanecements

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov resolved IGNITE-8264.
-
Resolution: Invalid

> TDE - Node join enhanecements
> -
>
> Key: IGNITE-8264
> URL: https://issues.apache.org/jira/browse/IGNITE-8264
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-18
>
> All nodes that are joined to the cluster with TDE enabled should be 
> configured to get TDE working. 
> They need access to MEK and CEK's. 
> We should extend node join mechanism to support TDE.



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

[jira] [Commented] (IGNITE-8092) Put operation may hang if cache was destroyed asynchronously.

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-8092:


Looks good for me.

> Put operation may hang if cache was destroyed asynchronously.
> -
>
> Key: IGNITE-8092
> URL: https://issues.apache.org/jira/browse/IGNITE-8092
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>
> If there is more than one cache in the cache group then put operation on 
> cache may hang if it was destroyed asynchronously.
> For now this applies to all cache modes (PARTITIONED/REPLICATED/LOCAL) and to 
> all atomicity modes (ATOMIC/TRANSACTIONAL).
> This problem can not be reproduced if there is only one cache in the cache 
> group.
> Reproducer:
> {code:java}
> public class DestroyCacheTest extends GridCommonAbstractTest {
> private CacheConfiguration ccfg(String name, String 
> grp) {
> return new CacheConfiguration Boolean>(name).setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> 
> .setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC)
> .setGroupName(grp);
> }
> public void testDestroyAsync() throws Exception {
> String grpName = "testGroup";
> try (IgniteEx node = startGrid(0)) {
> node.createCache(ccfg("cache2", grpName));
> for (int n = 0; n < 100; n++) {
> IgniteCache cache1 = 
> node.createCache(ccfg("cache1", grpName));
> AtomicInteger cntr = new AtomicInteger();
> GridTestUtils.runMultiThreadedAsync(() -> {
> try {
> int key;
> while ((key = cntr.getAndIncrement()) < 10_000) {
> if (key == 1000)
> cache1.destroy();
> cache1.putIfAbsent(key, true);
> }
> }
> catch (Exception ignore) {
> log.warning(ignore.getMessage());
> }
> return null;
> }, 6, "put-thread").get();
> }
> }
> }
> }
> {code}
> p.s. for ATOMIC cache additional cache status check in 
> GridCacheGateway#onStopped busy wait resolve this problem.



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

[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7993:


Hi [~guseinov], I've checked TC, it seems to be more or less the same with 
master.

Could you please close outdated PR because having 2 open PRs confuses reviewers 
a lot.

> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.6
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped 
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following 
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid 
> stripedPool thread pool size (must be greater than 0), actual value: 0
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
>   at org.apache.ignite.Ignition.start(Ignition.java:322)
>   ... 7 more
> {noformat}



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

[jira] [Commented] (IGNITE-8456) Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but persistence enabled

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8456:


Github user asfgit closed the pull request at:

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


> Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but 
> persistence enabled
> --
>
> Key: IGNITE-8456
> URL: https://issues.apache.org/jira/browse/IGNITE-8456
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Ryabov Dmitrii
>Priority: Critical
>  Labels: easyfix, newbie
> Fix For: 2.6
>
>
> In method org.apache.ignite.internal.util.IgniteUtils#workDirectory
> Ignite determine Work dir to be set, same value may be used in case 
> persistence Store Folder is not set and IGNITE_HOME is not specified.
> In case work dir is not specified, temp directory is used for Ignite Work. 
> But for persistence enabled case this means user DB goes to temp folder and 
> may be removed later.
> User may be confused by this behaviour. See:
> [https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage]
> and related Dev.List discussion
> [http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-HOME-for-persistence-td26470.html]
>  



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

[jira] [Created] (IGNITE-8484) Web Console lacks 'collocated' flag on SQL query tab

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8484:
---

 Summary: Web Console lacks 'collocated' flag on SQL query tab
 Key: IGNITE-8484
 URL: https://issues.apache.org/jira/browse/IGNITE-8484
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Ilya Kasnacheev


For some queries, this flag is needed to avoid endless running and/or memory 
depletion.

There's setEnforceJoinOrder() flag and setDistributedJoins() flag but not 
setCollocated() flag.



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

[jira] [Updated] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov updated IGNITE-8476:

Description: 
Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put() 
in each thread per second)

Kill 2 nodes and try to remove one node from baseline using

control.sh --baseline remove node1
 control.sh --baseline version TOPOLOGY_VERSION

 

Utility hangs or connected client may hangs, this assertion appears in log 

For transactional cache:
{code:java}
[16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125, 
dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef, 
addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1, 
loc=false, client=false], ZookeeperClusterNode 
[id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28, 
0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false], 
ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511, 
addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5, 
loc=false, client=false], ZookeeperClusterNode 
[id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37, 
127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false], 
ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde, 
addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6, 
loc=false, client=false]]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
at java.lang.Thread.run(Thread.java:748){code}
For atomic cache:
{code:java}
[18:40:12,858][SEVERE][sys-stripe-10-#11][GridCacheIoManager] Failed to process 
message [senderId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, messageType=class 
o.a.i.i.processors.cache.distributed.near.GridNearSingleGetRequest]
java.lang.AssertionError: Wrong ready topology version for invalid partitions 
response [topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
req=GridNearSingleGetRequest [futId=1526053201329, key=KeyCacheObjectImpl 
[part=42, val=1514, hasValBytes=true], flags=1, topVer=AffinityTopologyVersion 
[topVer=11, minorTopVer=0], subjId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, 
taskNameHash=0, createTtl=-1, accessTtl=-1]]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:943)
at 

[jira] [Updated] (IGNITE-8384) SQL: Secondary indexes should sort entries by links rather than keys

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-8384:

Description: 
Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The key 
itself is not stored in the index in general case. It means that we need to 
perform a lookup to data page to find correct insertion point for index entry.

This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
link}}. This is all we need.

UPD: If we have an affinity keys, then affinity column will be added to 
secondary index as well. 
 So, we'll have secondary index as  {{(idx_cols, KEY, AFF_COL)}}

Comparison occur here: 
{{org.apache.ignite.internal.processors.query.h2.database.H2Tree#compare}}
What we need is to avoid adding PK and affinity key columns to every secondary 
index and compare links instead in this method.

Probably we need to preserve old behavior for compatibility purposes.

  was:
Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The key 
itself is not stored in the index in general case. It means that we need to 
perform a lookup to data page to find correct insertion point for index entry.

This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
link}}. This is all we need.

UPD: If we have an affinity keys, then affinity column will be added to 
secondary index as well. 
 So, we'll have secondary index as  {{(idx_cols, KEY, AFF_COL)}}


> SQL: Secondary indexes should sort entries by links rather than keys
> 
>
> Key: IGNITE-8384
> URL: https://issues.apache.org/jira/browse/IGNITE-8384
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: iep-19, performance
> Fix For: 2.6
>
>
> Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The 
> key itself is not stored in the index in general case. It means that we need 
> to perform a lookup to data page to find correct insertion point for index 
> entry.
> This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
> link}}. This is all we need.
> UPD: If we have an affinity keys, then affinity column will be added to 
> secondary index as well. 
>  So, we'll have secondary index as  {{(idx_cols, KEY, AFF_COL)}}
> Comparison occur here: 
> {{org.apache.ignite.internal.processors.query.h2.database.H2Tree#compare}}
> What we need is to avoid adding PK and affinity key columns to every 
> secondary index and compare links instead in this method.
> Probably we need to preserve old behavior for compatibility purposes.



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

[jira] [Commented] (IGNITE-8384) SQL: Secondary indexes should sort entries by links rather than keys

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-8384:
-

[~langj], this should reduce number of page reads.

> SQL: Secondary indexes should sort entries by links rather than keys
> 
>
> Key: IGNITE-8384
> URL: https://issues.apache.org/jira/browse/IGNITE-8384
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: iep-19, performance
> Fix For: 2.6
>
>
> Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The 
> key itself is not stored in the index in general case. It means that we need 
> to perform a lookup to data page to find correct insertion point for index 
> entry.
> This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
> link}}. This is all we need.
> UPD: If we have an affinity keys, then affinity column will be added to 
> secondary index as well. 
>  So, we'll have secondary index as  {{(idx_cols, KEY, AFF_COL)}}



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

[jira] [Commented] (IGNITE-8456) Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but persistence enabled

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-8456:


[~agoncharuk], I changed text as you suggested.

> Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but 
> persistence enabled
> --
>
> Key: IGNITE-8456
> URL: https://issues.apache.org/jira/browse/IGNITE-8456
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Ryabov Dmitrii
>Priority: Critical
>  Labels: easyfix, newbie
> Fix For: 2.6
>
>
> In method org.apache.ignite.internal.util.IgniteUtils#workDirectory
> Ignite determine Work dir to be set, same value may be used in case 
> persistence Store Folder is not set and IGNITE_HOME is not specified.
> In case work dir is not specified, temp directory is used for Ignite Work. 
> But for persistence enabled case this means user DB goes to temp folder and 
> may be removed later.
> User may be confused by this behaviour. See:
> [https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage]
> and related Dev.List discussion
> [http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-HOME-for-persistence-td26470.html]
>  



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

[jira] [Commented] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8238:


GitHub user SharplEr opened a pull request:

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

IGNITE-8238: Operation can fails with unexpected RuntimeException when node 
is stopping.

For [IGNITE-8238](https://issues.apache.org/jira/browse/IGNITE-8238)

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

$ git pull https://github.com/SharplEr/ignite ignite-8238

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

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

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

This closes #3993






> Operation can fails with unexpected RuntimeException when node is stopping.
> ---
>
> Key: IGNITE-8238
> URL: https://issues.apache.org/jira/browse/IGNITE-8238
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
>Priority: Minor
> Fix For: 2.6
>
>
> Operation can fails with RuntimeException when node is stoped in other 
> thread. 
> It is not clear from javadoc that operation can throws RuntimeException.
>  We should add it to javadoc or e.g. throws IllegalStateException which 
> already present in java cache api javadoc.
> Failure in thread: Thread [id=3484, name=updater-2]
> java.lang.RuntimeException: Failed to perform cache update: node is stopping.
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1685)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:796)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1708)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:945)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:261)
>  at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)



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

[jira] [Comment Edited] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-5823 at 5/14/18 1:50 PM:
-

Triggered CI 
https://ci.ignite.apache.org/viewQueued.html?itemId=1288539=queuedBuildOverviewTab
 


was (Author: dpavlov):
Triggered CI https://ci.ignite.apache.org/viewQueued.html?itemId=1178819


> Need to remove CacheAtomicUpdateTimeoutException
> 
>
> Key: IGNITE-5823
> URL: https://issues.apache.org/jira/browse/IGNITE-5823
> Project: Ignite
>  Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Sergey Dorozhkin
>Priority: Minor
>  Labels: newbie
>
> And releated - CacheAtomicUpdateTimeoutCheckedException
> These exceptions are not used any more and can be removed.



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

[jira] [Commented] (IGNITE-7963) Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() is never called

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-7963:
-

[~gvvinblade] please review amended fix, javadoc only.

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

> Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() 
> is never called
> 
>
> Key: IGNITE-7963
> URL: https://issues.apache.org/jira/browse/IGNITE-7963
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: usability
>
> DataStreamer.addData() will return futures for operation.
> Thus the naive use of DataStreamer will look like this:
> {code}
> for (Data d : data)
>  futs.add(dataStreamer.addData(d));
> for (IgniteFuture f : futs)
> f.get();
> dataStreamer.close();
> {code}
> However, this does not work. Unless flush is called (manual or otherwisE), 
> futures are not being processed. This code will likely hang on f.get().
> The solution, IMHO, is to introduce dataStreamer-flushing clause in f.get().



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

[jira] [Commented] (IGNITE-6502) Need to output warning if -Djava.net.preferIPv4Stack=true is not set

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6502:


Github user asfgit closed the pull request at:

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


> Need to output warning if -Djava.net.preferIPv4Stack=true is not set
> 
>
> Key: IGNITE-6502
> URL: https://issues.apache.org/jira/browse/IGNITE-6502
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: vk
>Priority: Major
>  Labels: usability
> Fix For: 2.6
>
>
> Some issues were reported on dev/user list that may be caused by ipv6 usage. 
> I am not sure if Ignite can properly work with ipv6 networks. This needs to 
> be tested and another issue has been filed - 
> https://issues.apache.org/jira/browse/IGNITE-6503.
> For now it seems to be pretty handy just to have warning on node start:
> {noformat}
> Please set system property '-Djava.net.preferIPv4Stack=true' to avoid 
> possible problems in mixed environments.
> {noformat}



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

[jira] [Commented] (IGNITE-8456) Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but persistence enabled

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8456:
--

I suggest to slightly change the message to: "Persistence store directory is in 
the temp directory and may be cleaned. " and move the 
actual directory location to the end of the message.

> Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but 
> persistence enabled
> --
>
> Key: IGNITE-8456
> URL: https://issues.apache.org/jira/browse/IGNITE-8456
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Ryabov Dmitrii
>Priority: Critical
>  Labels: easyfix, newbie
> Fix For: 2.6
>
>
> In method org.apache.ignite.internal.util.IgniteUtils#workDirectory
> Ignite determine Work dir to be set, same value may be used in case 
> persistence Store Folder is not set and IGNITE_HOME is not specified.
> In case work dir is not specified, temp directory is used for Ignite Work. 
> But for persistence enabled case this means user DB goes to temp folder and 
> may be removed later.
> User may be confused by this behaviour. See:
> [https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage]
> and related Dev.List discussion
> [http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-HOME-for-persistence-td26470.html]
>  



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

[jira] [Assigned] (IGNITE-5997) [Test Failed] DynamicIndexPartitionedAtomicConcurrentSelfTest.testCoordinatorChange

[Dmitriy Sorokin (JIRA)]

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

Dmitriy Sorokin reassigned IGNITE-5997:
---

Assignee: Dmitriy Sorokin

> [Test Failed] 
> DynamicIndexPartitionedAtomicConcurrentSelfTest.testCoordinatorChange
> ---
>
> Key: IGNITE-5997
> URL: https://issues.apache.org/jira/browse/IGNITE-5997
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> It fails more often locally on linux machine
> http://ci.ignite.apache.org/viewLog.html?buildId=752869=buildResultsDiv=Ignite20Tests_IgniteQueries2#testNameId-4226597044755906475
> {code}
> SchemaOperationException [code=0, msg=Client node is disconnected (operation 
> result is unknown).]
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onDisconnected(GridQueryProcessor.java:822)
>   at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3770)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:749)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:559)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2391)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2370)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1686)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}



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

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-6528:
-

[~tledkov-gridgain] I have removed extra iteration and now avoid issuing 
warning more than once. Please take a look at changes.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



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

[jira] [Commented] (IGNITE-8456) Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but persistence enabled

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8456:


Hi [~SomeFire], thank you, there is just one failure and it is flaky test, so 
TC can be considered as OK.

> Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but 
> persistence enabled
> --
>
> Key: IGNITE-8456
> URL: https://issues.apache.org/jira/browse/IGNITE-8456
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Ryabov Dmitrii
>Priority: Critical
>  Labels: easyfix, newbie
> Fix For: 2.6
>
>
> In method org.apache.ignite.internal.util.IgniteUtils#workDirectory
> Ignite determine Work dir to be set, same value may be used in case 
> persistence Store Folder is not set and IGNITE_HOME is not specified.
> In case work dir is not specified, temp directory is used for Ignite Work. 
> But for persistence enabled case this means user DB goes to temp folder and 
> may be removed later.
> User may be confused by this behaviour. See:
> [https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage]
> and related Dev.List discussion
> [http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-HOME-for-persistence-td26470.html]
>  



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

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8085:


[~ein], could you please step in and comment timeouts change: 
NODE_START_CHECK_PERIOD & NODE_START_CHECK_LIMIT ?

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8085:


[~ivanan.fed] please feel free to assign all tickets to you.

But currently I don't understand why timeouts change helps to solve a number of 
test failures (I mean NODE_START_CHECK_PERIOD  & NODE_START_CHECK_LIMIT ).

Currently start nodes is really hot failure from point of view of MTCGA:
[Start Nodes]
org.apache.ignite.internal.IgniteStartStopRestartTestSuite: 
org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStopNodes
org.apache.ignite.internal.IgniteStartStopRestartTestSuite: 
org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls
org.apache.ignite.internal.IgniteStartStopRestartTestSuite: 
org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testRestartNodesFiltered
org.apache.ignite.internal.IgniteStartStopRestartTestSuite: 
org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds
org.apache.ignite.internal.IgniteStartStopRestartTestSuite: 
org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartThreeNodesAndDoEmptyCall

Would other test be fixed by this change.

Who could we ask to approve changing of these timeouts?

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Commented] (IGNITE-8446) Ability to check and completely fill transactions on creation

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-8446:
-

Hello, [~avinogradov].

Overall looks good.
I leaved several minor comments in Upsource.

> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.6
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
> guarantee it filled. 
> So, we have to add special event fired on {{tx}} creation. 
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta 
> should be added.



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

[jira] [Updated] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-8039:

Issue Type: Improvement  (was: Bug)

> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow 
> a client development basing on the spec only, w/o looking at other client 
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol 
> spec (v.2.4) 
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?) 
> - what is Object array (type code 23) ? What is the difference between it and 
> Objects Wrapped In​ Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
> 
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field 
> name".
> - "Repeat for as many times as the total number of schemas you have" -> 
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the 
> number of fields in the Data Object ?
> Objects Wrapped In​ Array
> 
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not 
> primitives)." -> does it mean that in general a complex object (103) must 
> always be sent via the Binary Protocol in a wrapper (27)? 
> - "Byte array size" -> "Payload size" or "Size of the whole array with 
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes 
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms 
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be 
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?



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

[jira] [Updated] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-8411:

Issue Type: Improvement  (was: Bug)

> Binary Client Protocol spec: other parts clarifications
> ---
>
> Key: IGNITE-8411
> URL: https://issues.apache.org/jira/browse/IGNITE-8411
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Denis Magda
>Priority: Major
>
> issues against previous parts: IGNITE-8039 IGNITE-8212
> Cache Configuration
>  ---
>  
> [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations]
>  - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - 
> QueryEntity - Structure of QueryField:
>  absent "default value - type Object" - it is the last field of the 
> QueryField in reality.
>  - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration:
>  Absent CacheAtomicityMode - is the first field in reality.
>  Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and 
> MaxQueryIterators in reality.
>  "Invalidate" field - does not exist in reality.
>  - meaning and possible values of every configuration parameter must be 
> clarified. If clarified in other docs, this spec must have link(s) to that 
> docs.
>  - suggest to combine somehow Cache Configuration descriptions in 
> OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid 
> duplicated descriptions.
> SQL and Scan Queries
>  
>  [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations]
>  - "Flag. Pass 0 for default, or 1 to keep the value in binary form.":
>  "the value in binary form" flag should be left end clarified in the 
> operations to which it is applicable for.
>  - OP_QUERY_SQL:
>  most of the fields in the request must be clarified. If clarified in other 
> docs, this spec must have link(s) to that docs.
>  For example:
>  ** "Name of a type or SQL table": name of what type?
>  - OP_QUERY_SQL_FIELDS:
>  most of the fields in the request must be clarified. If clarified in other 
> docs, this spec must have link(s) to that docs.
>  For example:
>  ** is there any correlation between "Query cursor page size" and "Max rows"?
>  ** "Statement type": why there are only three types? what about INSERT, etc.?
>  - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. 
> But responses for all other query operations contain it. Is it intentional?
>  - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality.
>  - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type 
> "long". Should be "int".
>  - OP_QUERY_SCAN:
>  format and rules of the Filter object must be clarified. If clarified in 
> other docs, this spec must have link(s) to that docs.
>  - OP_QUERY_SCAN:
>  in general, it's not clear how this operation should be supported on 
> platforms other than the mentioned in "Filter platform" field.
>  - OP_QUERY_SCAN: "Number of partitions to query"
>  Should be updated to "A partition number to query"
>  
> Binary Types
>  
>  
> [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations]
>  - somewhere should be explained when and why these operations need to be 
> supported by a client.
>  - Type id and Field id:
>  should be clarified that before an Id calculation Type and Field names must 
> be updated to low case.
>  - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id:
>  in reality it is not a type id (hash code) but a type code (1, 2,... 10,... 
> 103,...).
>  - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name":
>  should be explained what is it. If explained in other docs, this spec must 
> have link(s) to that docs.
>  - OP_PUT_BINARY_TYPE - schema id:
>  mandatory algorithm of schema Id calculation must be described somewhere. If 
> described in other docs, this spec must have link(s) to that docs.
>  - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME:
>  should be explained when and why these operations need to be supported by a 
> client.
>  How this operation should be supported on platforms other than the mentioned 
> in "Platform id" field.
>  - OP_REGISTER_BINARY_TYPE_NAME:
>  Type name - is it "full" or "short" name here?
>  Type id - is it a hash from "full" or "short" name here?



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

[jira] [Updated] (IGNITE-8212) Binary Client Protocol spec: Key-Value Queries clarifications

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-8212:

Issue Type: Improvement  (was: Bug)

> Binary Client Protocol spec: Key-Value Queries clarifications
> -
>
> Key: IGNITE-8212
> URL: https://issues.apache.org/jira/browse/IGNITE-8212
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> https://apacheignite.readme.io/v2.4/docs/binary-client-protocol-key-value-operations
> - all operations - "Flag. Pass 0 for default, or 1 to keep the value in 
> binary form":
> -- remove words about binary form and keep "Pass 0 for default" for all 
> operations where this flag has no meaning.
> -- clarify about binary form in operations where it has a meaning.
> - OP_CACHE_GET: clarify that null is returned if the provided key does not 
> exist in the cache.
> - OP_CACHE_GET_AND_PUT: clarify that new entry is created, if the provided 
> key does not exist in the cache, and null is returned in this case.
> - OP_CACHE_GET_AND_REPLACE:
> -- "if and only if there is a value currently mapped for that key" - is 
> confusing. Is it possible that an existing key has no associated value? 
> Suggest to rephrase as "if and only if the key exists in the cache"
> -- clarify that null is returned if the key does not exist in the cache.
> - OP_CACHE_GET_AND_REMOVE: clarify that null is returned if the key does not 
> exist in the cache.
> - OP_CACHE_PUT_IF_ABSENT: clarify what is "Success Flag" - true if the new 
> entry is created, false if the specified key already exists in the cache.
> - OP_CACHE_GET_AND_PUT_IF_ABSENT: "Previously contained value regardless of 
> whether put happened or not" - is confusing. Suggest to rewrite "the current 
> value associated with the key if it already exists in the cache, null if the 
> new entry is created".
> - OP_CACHE_GET_SIZE: clarify Peek modes
> - OP_CACHE_CLEAR_XXX and OP_CACHE_REMOVE_XXX:
> -- what is the difference between the corresponding operations? Only in 
> notifying / not notifying listeners and cache writers? Or there are other 
> differences not clarified by the spec?
> -- (the operations could be combined in one set - with a flag required/not 
> required notifications)
> -- there is OP_CACHE_REMOVE_IF_EQUALS. But there is no 
> OP_CACHE_CLEAR_IF_EQUALS. Is it intentional?
> -- OP_CACHE_REMOVE_KEY and OP_CACHE_REMOVE_IF_EQUALS have "Value indicating 
> whether remove happened" in the response. But OP_CACHE_CLEAR_KEY does not 
> have such a flag in the response. Is it intentional?
> -- OP_CACHE_CLEAR_KEYS, OP_CACHE_REMOVE_KEYS: clarify that even if some of 
> the specified keys do not exist other entries are removed anyway.



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

[jira] [Updated] (IGNITE-8483) Per partition TTL pending tree for in-memory caches.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-8483:
-
Description: 
For in memory cache pending tree root page is allocated when ignite store is 
initializing even if no ExpiryPolicy is used. 
 We have to implement lazy PendingTree initialization and switch to 
per-partition based PendingTree as we've done for persistent caches.

Switching to per-partition based PendingTree without lazy initialization will 
bump us with 1024 (default partitioned cache settings) unevictable pages per 
CacheGroup if no ExpiryPolicy is used.

 

  was:
For in memory cache pending tree root page is allocated when ignite store is 
initializing even if no ExpiryPolicy is used. 
 We have to implement lazy PendingTree initialization and switch to 
per-partition based PendingTree as we've done for persistent caches.

Switching to per-partition based PendingTree without lazy initialization will 
bump us with 1024 unevictable pages per CacheGroup if no ExpiryPolicy is used.

 


> Per partition TTL pending tree for in-memory caches.
> 
>
> Key: IGNITE-8483
> URL: https://issues.apache.org/jira/browse/IGNITE-8483
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
>
> For in memory cache pending tree root page is allocated when ignite store is 
> initializing even if no ExpiryPolicy is used. 
>  We have to implement lazy PendingTree initialization and switch to 
> per-partition based PendingTree as we've done for persistent caches.
> Switching to per-partition based PendingTree without lazy initialization will 
> bump us with 1024 (default partitioned cache settings) unevictable pages per 
> CacheGroup if no ExpiryPolicy is used.
>  



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

[jira] [Created] (IGNITE-8482) Skip 2-phase partition release wait in case of activation or dynamic caches start

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8482:
---

 Summary: Skip 2-phase partition release wait in case of activation 
or dynamic caches start
 Key: IGNITE-8482
 URL: https://issues.apache.org/jira/browse/IGNITE-8482
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.6


Currently we perform 2-phase partitions release waiting on any type of 
distributed exchange. We can optimize this behaviour, skipping such waiting on 
cluster activation (obviously if we activate cluster it means that before 
activation no caches were running and there is no reason to wait for finishing 
operations) and on dynamic caches start.



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

[jira] [Commented] (IGNITE-8469) Non-heap memroy leak for calling cluster activation multi times

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8469:


GitHub user Mmuzaf opened a pull request:

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

IGNITE-8469: add memory leak test case



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

$ git pull https://github.com/Mmuzaf/ignite leak-ignite-8469

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

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

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

This closes #3992


commit 2c319879f2d79c72c57c90539fd0ce16a8b37e5a
Author: Maxim Muzafarov 
Date:   2018-05-14T12:20:33Z

IGNITE-8469: add memory leak test case




> Non-heap memroy leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.6
>
>
> Calling multiple time cluster (with enabled persistence and started client 
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory 
> leak.
> Line 
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} 
> looks suspicious because of in case method 
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} 
> callled multi times (e.g. activate(true) called multi times) we lost info 
> about allocated regions.



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

[jira] [Created] (IGNITE-8483) Per partition TTL pending tree for in-memory caches.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-8483:


 Summary: Per partition TTL pending tree for in-memory caches.
 Key: IGNITE-8483
 URL: https://issues.apache.org/jira/browse/IGNITE-8483
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Reporter: Andrew Mashenkov


For in memory cache pending tree root page is allocated when ignite store is 
initializing even if no ExpiryPolicy is used. 
 We have to implement lazy PendingTree initialization and switch to 
per-partition based PendingTree as we've done for persistent caches.

Switching to per-partition based PendingTree without lazy initialization will 
bump us with 1024 unevictable pages per CacheGroup if no ExpiryPolicy is used.

 



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

[jira] [Updated] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov updated IGNITE-8476:

Description: 
Run 6 nodes, start loading (8 threads, 1000 cache.put() in each thread per 
second)

Kill 2 nodes and try to remove one node from baseline using

control.sh --baseline remove node1
 control.sh --baseline version TOPOLOGY_VERSION

 

Utility hangs or connected client may hangs, this assertion appears in log 
{code:java}
[18:40:12,858][SEVERE][sys-stripe-10-#11][GridCacheIoManager] Failed to process 
message [senderId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, messageType=class 
o.a.i.i.processors.cache.distributed.near.GridNearSingleGetRequest]
java.lang.AssertionError: Wrong ready topology version for invalid partitions 
response [topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
req=GridNearSingleGetRequest [futId=1526053201329, key=KeyCacheObjectImpl 
[part=42, val=1514, hasValBytes=true], flags=1, topVer=AffinityTopologyVersion 
[topVer=11, minorTopVer=0], subjId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, 
taskNameHash=0, createTtl=-1, accessTtl=-1]]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:943)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:906)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:906)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$300(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$4.apply(GridDhtAtomicCache.java:252)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$4.apply(GridDhtAtomicCache.java:247)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
at java.lang.Thread.run(Thread.java:748){code}

  was:
Run 6 nodes, start loading (8 threads, 1000 cache.put() in each thread per 
second)

Kill 2 nodes and try to remove one node from baseline using

control.sh --baseline remove node1
control.sh --baseline version TOPOLOGY_VERSION

 

Utility hangs, this assertion appears in log
{code:java}
[18:40:12,858][SEVERE][sys-stripe-10-#11][GridCacheIoManager] Failed to process 
message [senderId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, messageType=class 
o.a.i.i.processors.cache.distributed.near.GridNearSingleGetRequest]
java.lang.AssertionError: Wrong ready topology version for invalid partitions 
response [topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
req=GridNearSingleGetRequest [futId=1526053201329, key=KeyCacheObjectImpl 
[part=42, val=1514, hasValBytes=true], flags=1, topVer=AffinityTopologyVersion 
[topVer=11, minorTopVer=0], subjId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, 
taskNameHash=0, createTtl=-1, accessTtl=-1]]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:943)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:906)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:906)
at 

[jira] [Updated] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov updated IGNITE-8476:

Summary: AssertionError exception occurs when trying to remove node from 
baseline under loading  (was: AssertionError exception occurs when trying to 
remove node from baseline by consistentId under loading)

> AssertionError exception occurs when trying to remove node from baseline 
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Priority: Blocker
>
> Run 6 nodes, start loading (8 threads, 1000 cache.put() in each thread per 
> second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
> control.sh --baseline version TOPOLOGY_VERSION
>  
> Utility hangs, this assertion appears in log
> {code:java}
> [18:40:12,858][SEVERE][sys-stripe-10-#11][GridCacheIoManager] Failed to 
> process message [senderId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, 
> messageType=class 
> o.a.i.i.processors.cache.distributed.near.GridNearSingleGetRequest]
> java.lang.AssertionError: Wrong ready topology version for invalid partitions 
> response [topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
> req=GridNearSingleGetRequest [futId=1526053201329, key=KeyCacheObjectImpl 
> [part=42, val=1514, hasValBytes=true], flags=1, 
> topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
> subjId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, taskNameHash=0, createTtl=-1, 
> accessTtl=-1]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:943)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:906)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:906)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$300(GridDhtAtomicCache.java:130)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$4.apply(GridDhtAtomicCache.java:252)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$4.apply(GridDhtAtomicCache.java:247)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
> at java.lang.Thread.run(Thread.java:748){code}



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

[jira] [Updated] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline by consistentId under loading

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov updated IGNITE-8476:

Description: 
Run 6 nodes, start loading (8 threads, 1000 cache.put() in each thread per 
second)

Kill 2 nodes and try to remove one node from baseline using

control.sh --baseline remove node1
control.sh --baseline version TOPOLOGY_VERSION

 

Utility hangs, this assertion appears in log
{code:java}
[18:40:12,858][SEVERE][sys-stripe-10-#11][GridCacheIoManager] Failed to process 
message [senderId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, messageType=class 
o.a.i.i.processors.cache.distributed.near.GridNearSingleGetRequest]
java.lang.AssertionError: Wrong ready topology version for invalid partitions 
response [topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
req=GridNearSingleGetRequest [futId=1526053201329, key=KeyCacheObjectImpl 
[part=42, val=1514, hasValBytes=true], flags=1, topVer=AffinityTopologyVersion 
[topVer=11, minorTopVer=0], subjId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, 
taskNameHash=0, createTtl=-1, accessTtl=-1]]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:943)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:906)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:906)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$300(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$4.apply(GridDhtAtomicCache.java:252)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$4.apply(GridDhtAtomicCache.java:247)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
at java.lang.Thread.run(Thread.java:748){code}

  was:
Run 6 nodes, start loading (8 threads, 1000 cache.put() in each thread per 
second)

Kill 2 nodes and try to remove one node from baseline using

control.sh --baseline remove node1

 

Utility hangs, this assertion appears in log
{code:java}
[18:40:12,858][SEVERE][sys-stripe-10-#11][GridCacheIoManager] Failed to process 
message [senderId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, messageType=class 
o.a.i.i.processors.cache.distributed.near.GridNearSingleGetRequest]
java.lang.AssertionError: Wrong ready topology version for invalid partitions 
response [topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
req=GridNearSingleGetRequest [futId=1526053201329, key=KeyCacheObjectImpl 
[part=42, val=1514, hasValBytes=true], flags=1, topVer=AffinityTopologyVersion 
[topVer=11, minorTopVer=0], subjId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, 
taskNameHash=0, createTtl=-1, accessTtl=-1]]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:943)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:906)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:906)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$300(GridDhtAtomicCache.java:130)
at 

[jira] [Updated] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline by consistentId under loading

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov updated IGNITE-8476:

Priority: Blocker  (was: Critical)

> AssertionError exception occurs when trying to remove node from baseline by 
> consistentId under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Priority: Blocker
>
> Run 6 nodes, start loading (8 threads, 1000 cache.put() in each thread per 
> second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
>  
> Utility hangs, this assertion appears in log
> {code:java}
> [18:40:12,858][SEVERE][sys-stripe-10-#11][GridCacheIoManager] Failed to 
> process message [senderId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, 
> messageType=class 
> o.a.i.i.processors.cache.distributed.near.GridNearSingleGetRequest]
> java.lang.AssertionError: Wrong ready topology version for invalid partitions 
> response [topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
> req=GridNearSingleGetRequest [futId=1526053201329, key=KeyCacheObjectImpl 
> [part=42, val=1514, hasValBytes=true], flags=1, 
> topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
> subjId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, taskNameHash=0, createTtl=-1, 
> accessTtl=-1]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:943)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:906)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:906)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$300(GridDhtAtomicCache.java:130)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$4.apply(GridDhtAtomicCache.java:252)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$4.apply(GridDhtAtomicCache.java:247)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
> at java.lang.Thread.run(Thread.java:748){code}



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

[jira] [Updated] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline by consistentId under loading

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov updated IGNITE-8476:

Affects Version/s: 2.5

> AssertionError exception occurs when trying to remove node from baseline by 
> consistentId under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Priority: Critical
>
> Run 6 nodes, start loading (8 threads, 1000 cache.put() in each thread per 
> second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
>  
> Utility hangs, this assertion appears in log
> {code:java}
> [18:40:12,858][SEVERE][sys-stripe-10-#11][GridCacheIoManager] Failed to 
> process message [senderId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, 
> messageType=class 
> o.a.i.i.processors.cache.distributed.near.GridNearSingleGetRequest]
> java.lang.AssertionError: Wrong ready topology version for invalid partitions 
> response [topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
> req=GridNearSingleGetRequest [futId=1526053201329, key=KeyCacheObjectImpl 
> [part=42, val=1514, hasValBytes=true], flags=1, 
> topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], 
> subjId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5, taskNameHash=0, createTtl=-1, 
> accessTtl=-1]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:943)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:906)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:906)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$300(GridDhtAtomicCache.java:130)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$4.apply(GridDhtAtomicCache.java:252)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$4.apply(GridDhtAtomicCache.java:247)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
> at java.lang.Thread.run(Thread.java:748){code}



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

[jira] [Assigned] (IGNITE-6964) Ignite restart with PDS enabled may cause delays in TTL cleanup worker

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reassigned IGNITE-6964:
--

Assignee: Andrew Mashenkov

> Ignite restart with PDS enabled may cause delays in TTL cleanup worker
> --
>
> Key: IGNITE-6964
> URL: https://issues.apache.org/jira/browse/IGNITE-6964
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.6
>
>
> If ignite was restarted and not all TTL entries were evicted, simple restart 
> does not cause entries to be deleted, even if test waits for some time.
> In the same time if some entries were touched by get() TTL eviction starts to 
> work as it is expected.



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

[jira] [Resolved] (IGNITE-6964) Ignite restart with PDS enabled may cause delays in TTL cleanup worker

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov resolved IGNITE-6964.
--
Resolution: Fixed

Fixed within IGNITE-5874.

> Ignite restart with PDS enabled may cause delays in TTL cleanup worker
> --
>
> Key: IGNITE-6964
> URL: https://issues.apache.org/jira/browse/IGNITE-6964
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.6
>
>
> If ignite was restarted and not all TTL entries were evicted, simple restart 
> does not cause entries to be deleted, even if test waits for some time.
> In the same time if some entries were touched by get() TTL eviction starts to 
> work as it is expected.



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

[jira] [Comment Edited] (IGNITE-8161) Suspend-resume TX test is flaky on TC (~5% fail rate)

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-8161 at 5/14/18 11:57 AM:


[~dpavlov] sorry for delay, Im working on this ticket.


was (Author: alexey kuznetsov):
[~dpavlov] sorry for delay, Im working on this ticket

> Suspend-resume TX test is flaky on TC (~5% fail rate)
> -
>
> Key: IGNITE-8161
> URL: https://issues.apache.org/jira/browse/IGNITE-8161
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1176294=buildResultsDiv=IgniteTests24Java8_Cache6#testNameId-7194341254453895210
> Causal chani java.lang.RuntimeException: javax.cache.CacheException: class 
> org.apache.ignite.transactions.TransactionTimeoutException: Cache transaction 
> timed out: GridNearTxLocal 
> First exception in log
> {noformat}
> validParts=null, state=MARKED_ROLLBACK, timedOut=true, 
> topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], duration=172ms, 
> onePhaseCommit=false], size=0]]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:759)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:728)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnResumed(IgniteOptimisticTxSuspendResumeTest.java:431)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2018)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:136)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1933)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Test history
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7194341254453895210=testDetails



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

[jira] [Commented] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in client's configuration

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5789:


Hi [~vk],

please merge conflicts in PR, 
Conflicting files
GridDhtPartitionsExchangeFuture.java
ClientReconnectAfterClusterRestartTest.java

Branch test was also not-successful because of compilation errors.

> After client reconnects to server if server was restarted, client doesn't 
> create caches defined in client's configuration
> -
>
> Key: IGNITE-5789
> URL: https://issues.apache.org/jira/browse/IGNITE-5789
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Evgenii Zhuravlev
>Assignee: vk
>Priority: Major
> Fix For: 2.6
>
> Attachments: ClientReconnectAfterClusterRestartTest.java
>
>
> User with this problem on SO:
> https://stackoverflow.com/questions/46053089/ignite-cache-reconnection-issue-cache-is-stopped



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

[jira] [Commented] (IGNITE-8161) Suspend-resume TX test is flaky on TC (~5% fail rate)

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-8161:
--

[~dpavlov] sorry for delay, Im working on this ticket

> Suspend-resume TX test is flaky on TC (~5% fail rate)
> -
>
> Key: IGNITE-8161
> URL: https://issues.apache.org/jira/browse/IGNITE-8161
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1176294=buildResultsDiv=IgniteTests24Java8_Cache6#testNameId-7194341254453895210
> Causal chani java.lang.RuntimeException: javax.cache.CacheException: class 
> org.apache.ignite.transactions.TransactionTimeoutException: Cache transaction 
> timed out: GridNearTxLocal 
> First exception in log
> {noformat}
> validParts=null, state=MARKED_ROLLBACK, timedOut=true, 
> topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], duration=172ms, 
> onePhaseCommit=false], size=0]]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:759)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:728)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnResumed(IgniteOptimisticTxSuspendResumeTest.java:431)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2018)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:136)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1933)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Test history
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7194341254453895210=testDetails



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

[jira] [Updated] (IGNITE-8022) Need to add README.txt for ignite-direct-io

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8022:
---
Component/s: persistence

> Need to add README.txt for ignite-direct-io
> ---
>
> Key: IGNITE-8022
> URL: https://issues.apache.org/jira/browse/IGNITE-8022
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Ksenia Rybakova
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.6
>
>
> Need to add README.txt for ignite-direct-io



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

[jira] [Updated] (IGNITE-8022) Need to add README.txt for ignite-direct-io

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8022:
---
Fix Version/s: (was: 2.5)
   2.6

> Need to add README.txt for ignite-direct-io
> ---
>
> Key: IGNITE-8022
> URL: https://issues.apache.org/jira/browse/IGNITE-8022
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Ksenia Rybakova
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.6
>
>
> Need to add README.txt for ignite-direct-io



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

[jira] [Commented] (IGNITE-8022) Need to add README.txt for ignite-direct-io

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov commented on IGNITE-8022:


In fact, this isn't a duplicate. IGNITE-7466 dealt with readme.io, but this is 
for README.txt in the source repo. Reopened.

> Need to add README.txt for ignite-direct-io
> ---
>
> Key: IGNITE-8022
> URL: https://issues.apache.org/jira/browse/IGNITE-8022
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Ksenia Rybakova
>Priority: Major
> Fix For: 2.5
>
>
> Need to add README.txt for ignite-direct-io



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

[jira] [Assigned] (IGNITE-8022) Need to add README.txt for ignite-direct-io

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov reassigned IGNITE-8022:
--

Assignee: Dmitriy Pavlov

> Need to add README.txt for ignite-direct-io
> ---
>
> Key: IGNITE-8022
> URL: https://issues.apache.org/jira/browse/IGNITE-8022
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Ksenia Rybakova
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> Need to add README.txt for ignite-direct-io



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

[jira] [Commented] (IGNITE-8037) DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart is flaky

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8037:


[~tledkov-gridgain] please set patch available if issue is ready for review.

> DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart
>  is flaky
> ---
>
> Key: IGNITE-8037
> URL: https://issues.apache.org/jira/browse/IGNITE-8037
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Assignee: Taras Ledkov
>Priority: Major
>
> Test fails on TC as well as locally (although local runs reproduce failure 
> rarely: 1-3 failed tests for 100 runs).
> There are suspicious errors in logs:
> {noformat}
> [2018-03-23 
> 18:55:19,371][ERROR][exchange-worker-#630%index.DynamicColumnsConcurrentTransactionalPartitionedSelfTest4%][GridQueryProcessor]
>  Failed to clear indexing on cache unregister (will ignore): idx
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=idx]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:542)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:705)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2794)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1630)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:799)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:860)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1161)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1902)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1768)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:784)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:666)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2344)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.h2.jdbc.JdbcSQLException: Schema "idx" not found; SQL 
> statement:
> SET SCHEMA "idx" [90079-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.engine.Database.getSchema(Database.java:1755)
> at org.h2.command.dml.Set.update(Set.java:408)
> at org.h2.command.CommandContainer.update(CommandContainer.java:101)
> at org.h2.command.Command.executeUpdate(Command.java:260)
> at org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
> at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:534)
> ... 14 more{noformat}
> Test fails with the following error:
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect 
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.waitReconnectEvent(IgniteClientReconnectAbstractTest.java:120)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:297)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:238)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest.reconnectClientNode(DynamicColumnsAbstractConcurrentSelfTest.java:804)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest.checkClientReconnect(DynamicColumnsAbstractConcurrentSelfTest.java:781)
> at 
> 

[jira] [Created] (IGNITE-8481) VisorValidateIndexesJob works very slowly in case of many partitions/keys for each partition.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-8481:
-

 Summary: VisorValidateIndexesJob works very slowly in case of many 
partitions/keys for each partition.
 Key: IGNITE-8481
 URL: https://issues.apache.org/jira/browse/IGNITE-8481
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Alexei Scherbakov
 Fix For: 2.6
 Attachments: ignite.zip, thrdump-server.log

I tried to validate indexes using newly introduced VisorValidateIndexesTask 
from control.sh and found what on large data set it works very slowly. Process 
was not finished for 12 hours from start.

Looking through a thread dump I've noticed following problems:

1. ValidateIndexesClosure works not in optimal way by doing btree lookup for 
each index for each entry of each partition. It should be faster to validate by 
scanning index tree.

2. Thread dump shows contention on acquiring segment read lock by worker 
pool-XXX threads, but no obvious reason for holding write lock (no load on grid)

3. 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.Segment#partGeneration
 generates garbage on each page access.

Check attachment for log and thread dump.




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

[jira] [Updated] (IGNITE-7449) Rebalancing metrics doesn't display actual information about current rebalance state

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov updated IGNITE-7449:

Priority: Minor  (was: Major)

> Rebalancing metrics doesn't display actual information about current 
> rebalance state
> 
>
> Key: IGNITE-7449
> URL: https://issues.apache.org/jira/browse/IGNITE-7449
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Priority: Minor
>
> In case of shutdown node with clear LFS following metrics doesn't display 
> correct information about rebalance:
> RebalancingKeysRate
> RebalancingBytesRate
> KeysToRebalanceLeft
>  
> Otherwise RebalancingPartitionsCount metric displays information correctly
> Steps to reproduce:
>  1. Cluster with enabled statistics
>  2. Shutdown node and clear LFS
>  3. Run node
>  4. Start node and ask node for current rebalance state through JMX:
> Current result:
> 1 tick
> RebalancingKeysRate 0
> RebalancingBytesRate 0
> KeysToRebalanceLeft 0
> RebalancingPartitionsCount 342
> 2 tick
> RebalancingKeysRate 0
> RebalancingBytesRate 0
> KeysToRebalanceLeft 0
> RebalancingPartitionsCount 80
> Expected:
> 2 tick
> RebalancingKeysRate SOME_NON_ZERO_VALUE
> RebalancingBytesRate SOME_NON_ZERO_VALUE
> KeysToRebalanceLeft SOME_NON_ZERO_VALUE
> RebalancingPartitionsCount 80
>  
> UPD: -DIGNITE_REBALANCE_STATISTICS_TIME_INTERVAL=1000 doesn't affect results



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

[jira] [Commented] (IGNITE-8474) WalStateNodeLeaveExchangeTask prevents merge exchanges on leaving many nodes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8474:


GitHub user sergey-chugunov-1985 opened a pull request:

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

IGNITE-8474 skipForExchangeMerge property changed to 'true'



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

$ git pull https://github.com/gridgain/apache-ignite ignite-8474

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

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

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

This closes #3990


commit 853908d1f9eaaeea9dbbf8dbc1f63c02fc59b4a0
Author: Sergey Chugunov 
Date:   2018-05-14T10:52:58Z

IGNITE-8474 skipForExchangeMerge property changed to 'true'




> WalStateNodeLeaveExchangeTask prevents merge exchanges on leaving many nodes
> 
>
> Key: IGNITE-8474
> URL: https://issues.apache.org/jira/browse/IGNITE-8474
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.6
>
>
> Exchange merge mechanism provides huge optimization when a lot of nodes join 
> or leave cluster simultaneously.
> In IGNITE-7003 WalStateNodeLeaveExchangeTask custom exchange task was added 
> which is generated for each NODE_LEFT/NODE_FAILED event.
> Because of property skipForExchangeMerge set to false on this task it 
> prohibits exchange merge optimization.
> The property needs to be reconsidered and changed if it is not crucial for 
> this functionality.



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

[jira] [Commented] (IGNITE-6879) Support Spring Data 2.0

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6879:


Hi [~homich], ok, I've created 
https://issues.apache.org/jira/browse/IGNITE-8480 issue for test fix, included 
it into Make TC green Again activity. 

I hope this failure does not indicate fix itself does not work.

I would appreciate if you will take a look.

> Support Spring Data 2.0
> ---
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
> Fix For: 2.6
>
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



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