[jira] [Commented] (IGNITE-8002) Authentication: add to REST support of new authentication

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-8002:


Test your changes. Please, throw proper exception when authenticationEnabled = 
false and the following commands are called: adduser, updateuser.

> Authentication:  add to REST support of new authentication
> --
>
> Key: IGNITE-8002
> URL: https://issues.apache.org/jira/browse/IGNITE-8002
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
>




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

[jira] [Comment Edited] (IGNITE-8002) Authentication: add to REST support of new authentication

[Andrey Novikov (JIRA)]

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

Andrey Novikov edited comment on IGNITE-8002 at 3/21/18 4:32 AM:
-

Tested your changes. Please, throw proper exception when authenticationEnabled 
= false and the following commands are called: adduser, updateuser.


was (Author: anovikov):
Test your changes. Please, throw proper exception when authenticationEnabled = 
false and the following commands are called: adduser, updateuser.

> Authentication:  add to REST support of new authentication
> --
>
> Key: IGNITE-8002
> URL: https://issues.apache.org/jira/browse/IGNITE-8002
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
>




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

[jira] [Comment Edited] (IGNITE-7926) Web console: demo faled to start under java 9

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-7926 at 3/21/18 4:27 AM:
-

Tested on Windows


was (Author: pkonstantinov):
Tested

> Web console: demo faled to start under java 9
> -
>
> Key: IGNITE-7926
> URL: https://issues.apache.org/jira/browse/IGNITE-7926
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.5
>
>
> We need to add support for Java 9 to web console demo.



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

[jira] [Comment Edited] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin

[Ilya Borisov (JIRA)]

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

Ilya Borisov edited comment on IGNITE-6816 at 3/21/18 4:26 AM:
---

[~alexdel] I've fixed the web console frontend compilation in Webpack 4, but 
there's a catch: no more vendor chunk. We probably will have to address this 
issue.

Meanwhile, the autodll plugin [does not support Webpack 4 
yet|https://github.com/asfktz/autodll-webpack-plugin/issues/105].


was (Author: klaster_1):
[~alexdel] I've fixed the web console frontend compilation in Webpack 4, but 
there's a catch: no more vendor chunk. We probably will have to address this 
issue.

> Webconsole: investigate/integrate Webpack dll-plugin
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Trivial
>
> As the webconsole frontend app size grows, it takes more and more time to 
> incrementally rebuild after each source code change in development 
> environment. Let's investigate this plugin 
> https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack 
> build pipeline if it offers measureable performance improvements.



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

[jira] [Created] (IGNITE-8002) Authentication: add to REST support of new authentication

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8002:


 Summary: Authentication:  add to REST support of new authentication
 Key: IGNITE-8002
 URL: https://issues.apache.org/jira/browse/IGNITE-8002
 Project: Ignite
  Issue Type: Task
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov






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

[jira] [Commented] (IGNITE-7926) Web console: demo faled to start under java 9

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7926:


Tested

> Web console: demo faled to start under java 9
> -
>
> Key: IGNITE-7926
> URL: https://issues.apache.org/jira/browse/IGNITE-7926
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.5
>
>
> We need to add support for Java 9 to web console demo.



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

[jira] [Commented] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-6816:
--

[~alexdel] I've fixed the web console frontend compilation in Webpack 4, but 
there's a catch: no more vendor chunk. We probably will have to address this 
issue.

> Webconsole: investigate/integrate Webpack dll-plugin
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Trivial
>
> As the webconsole frontend app size grows, it takes more and more time to 
> incrementally rebuild after each source code change in development 
> environment. Let's investigate this plugin 
> https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack 
> build pipeline if it offers measureable performance improvements.



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

[jira] [Assigned] (IGNITE-7864) Control utility: Add confirm on dangerous operations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7864:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master.

> Control utility: Add confirm on dangerous operations
> 
>
> Key: IGNITE-7864
> URL: https://issues.apache.org/jira/browse/IGNITE-7864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> control.sh can deactivate cluster.
> It could be very dangerous in some cases.
> Lets add manual confirmation for dangerous operations: deactivate, change 
> base line, ...
> Also, lets add "-force" option to not ask for confirmation (will be useful in 
> scripts).
>  



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

[jira] [Assigned] (IGNITE-7940) Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7940:
--

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().
> ---
>
> Key: IGNITE-7940
> URL: https://issues.apache.org/jira/browse/IGNITE-7940
> Project: Ignite
>  Issue Type: Task
>  Components: visor
>Reporter: Alexey Kuznetsov
>Assignee: Vasiliy Sisko
>Priority: Major
> Fix For: 2.5
>
>
> See: https://apacheignite.readme.io/docs/partition-loss-policies



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

[jira] [Commented] (IGNITE-7940) Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7940:


Works in one case and doesn't in another.
I think it should be investigated deeply.

> Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().
> ---
>
> Key: IGNITE-7940
> URL: https://issues.apache.org/jira/browse/IGNITE-7940
> Project: Ignite
>  Issue Type: Task
>  Components: visor
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> See: https://apacheignite.readme.io/docs/partition-loss-policies



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

[jira] [Commented] (IGNITE-7864) Control utility: Add confirm on dangerous operations

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7864:


Tested.

> Control utility: Add confirm on dangerous operations
> 
>
> Key: IGNITE-7864
> URL: https://issues.apache.org/jira/browse/IGNITE-7864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> control.sh can deactivate cluster.
> It could be very dangerous in some cases.
> Lets add manual confirmation for dangerous operations: deactivate, change 
> base line, ...
> Also, lets add "-force" option to not ask for confirmation (will be useful in 
> scripts).
>  



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

[jira] [Assigned] (IGNITE-7949) Web Console: Refactor post validation on sign in / sign up.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7949:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web Console: Refactor post validation on sign in / sign up.
> ---
>
> Key: IGNITE-7949
> URL: https://issues.apache.org/jira/browse/IGNITE-7949
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> In current implementation we show ugly popover in case of server error or 
> when backend unavailable at all.
>  
> Lets show errors as we do for input validation errors.
> And when server not available lets show proper message.



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

[jira] [Commented] (IGNITE-7949) Web Console: Refactor post validation on sign in / sign up.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7949:


Tested

> Web Console: Refactor post validation on sign in / sign up.
> ---
>
> Key: IGNITE-7949
> URL: https://issues.apache.org/jira/browse/IGNITE-7949
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> In current implementation we show ugly popover in case of server error or 
> when backend unavailable at all.
>  
> Lets show errors as we do for input validation errors.
> And when server not available lets show proper message.



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

[jira] [Updated] (IGNITE-8001) Web console: show more user-friendly error instead of 'Internal error'

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8001:
---
Summary: Web console: show more user-friendly error instead of 'Internal 
error'  (was: Web console: show more userfriendly error instead of 'Internal 
error')

> Web console: show more user-friendly error instead of 'Internal error'
> --
>
> Key: IGNITE-8001
> URL: https://issues.apache.org/jira/browse/IGNITE-8001
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Konstantinov
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> In case if the backend is down we display the 'Internal error' message.
> I suggest displaying some other more user-friendly text.
>  !screenshot-1.png! 



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

[jira] [Updated] (IGNITE-8001) Web console: show more userfriendly error instead of 'Internal error'

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8001:
---
Description: 
In case if the backend is down we display the 'Internal error' message.
I suggest displaying some other more user-friendly text.
 !screenshot-1.png! 

  was:
In case if the backend is down we display the 'Internal error' message.
I suggest displaying some other more user-friendly text.



> Web console: show more userfriendly error instead of 'Internal error'
> -
>
> Key: IGNITE-8001
> URL: https://issues.apache.org/jira/browse/IGNITE-8001
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Konstantinov
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> In case if the backend is down we display the 'Internal error' message.
> I suggest displaying some other more user-friendly text.
>  !screenshot-1.png! 



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

[jira] [Updated] (IGNITE-8001) Web console: show more userfriendly error instead of 'Internal error'

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8001:
---
Attachment: screenshot-1.png

> Web console: show more userfriendly error instead of 'Internal error'
> -
>
> Key: IGNITE-8001
> URL: https://issues.apache.org/jira/browse/IGNITE-8001
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Konstantinov
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> In case if the backend is down we display the 'Internal error' message.
> I suggest displaying some other more user-friendly text.



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

[jira] [Created] (IGNITE-8001) Web console: show more userfriendly error instead of 'Internal error'

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8001:
--

 Summary: Web console: show more userfriendly error instead of 
'Internal error'
 Key: IGNITE-8001
 URL: https://issues.apache.org/jira/browse/IGNITE-8001
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Konstantinov
 Attachments: screenshot-1.png

In case if the backend is down we display the 'Internal error' message.
I suggest displaying some other more user-friendly text.




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

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

[Roman Guseinov (JIRA)]

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

Roman Guseinov commented on IGNITE-7993:


[~vkulichenko] , thanks for your comments. I agree with that and will create a 
test.

> 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.5
>
>
> 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] [Assigned] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-7466:
---

Assignee: Prachi Garg  (was: Denis Magda)

> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.5
>
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

[jira] [Commented] (IGNITE-7595) Find and switch to alternate documentation engine

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-7595:
-

I looked into [https://docusaurus.io/en/] and [https://www.gitbook.com/] . I 
liked Docusaurus better because of all the features it supports. I have 
attached a comparison table.

Additionally, looks like readme.io has its own markdown format for some 
elements. Regardless of the documentation platform we use, we need to convert 
those markdown elements to standard markdown. See attached spreadsheet.

> Find and switch to alternate documentation engine
> -
>
> Key: IGNITE-7595
> URL: https://issues.apache.org/jira/browse/IGNITE-7595
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.5
>
> Attachments: Docusaurus-GitBook comparison.docx, 
> readme-markdown-mapping.xlsx
>
>
> Current readme.io documentation has many drawbacks that make the life of 
> Ignite technical writers hard. Some of the problems are:
>  * Each "version" is just a copy of the previous one. When fixing something, 
> you have to update
> all the versions.
>  * No good way to review changes.
>  * "Propose edit" functionality is a not suitable for review. You can only 
> accept or reject an
> edit, no way to communicate with a contributor, etc
>  * There is no way to prevent Google from indexing old documentation 
> versions. Thus, it's common to come across old doc version in a google 
> search. 
> We might consider GitHub based documentation or another approach. The 
> discussion is here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html



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

[jira] [Commented] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7466:
-

High-level overview of Direct I/O benefits and usage scenarios:
* https://linux.cloudibee.com/2008/01/what-is-direct-io/
* 
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.genprogc/benefits_direct_io.htm

> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.5
>
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

[jira] [Updated] (IGNITE-7595) Find and switch to alternate documentation engine

[Prachi Garg (JIRA)]

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

Prachi Garg updated IGNITE-7595:

Attachment: readme-markdown-mapping.xlsx
Docusaurus-GitBook comparison.docx

> Find and switch to alternate documentation engine
> -
>
> Key: IGNITE-7595
> URL: https://issues.apache.org/jira/browse/IGNITE-7595
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.5
>
> Attachments: Docusaurus-GitBook comparison.docx, 
> readme-markdown-mapping.xlsx
>
>
> Current readme.io documentation has many drawbacks that make the life of 
> Ignite technical writers hard. Some of the problems are:
>  * Each "version" is just a copy of the previous one. When fixing something, 
> you have to update
> all the versions.
>  * No good way to review changes.
>  * "Propose edit" functionality is a not suitable for review. You can only 
> accept or reject an
> edit, no way to communicate with a contributor, etc
>  * There is no way to prevent Google from indexing old documentation 
> versions. Thus, it's common to come across old doc version in a google 
> search. 
> We might consider GitHub based documentation or another approach. The 
> discussion is here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html



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

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

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-7993:
-

[~guseinov], I'm not sure this is enough for the fix. Please create a test and 
check that system pool is used if you configure to disable striped pool.

> 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.5
>
>
> 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-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7466:
-

[~dpavlov], thanks. We'll work with Prachi and put high-level information to 
the durable memory tuning page:
https://apacheignite.readme.io/docs/durable-memory-tuning

[~pgarg], let's create a section on the performance page above suggesting to 
try Direct I/O for write-intensive and mixed workloads. Edit the 2.4 version 
directly because the feature is already available.

Relevant discussion on the dev list:
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Direct-I-O-plugin-description-added-to-wiki-td28324.html



> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.5
>
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

[jira] [Commented] (IGNITE-6341) Use direct IO or libaio for file page store where applicable

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6341:


Described here 
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-DirectI/O
 

> Use direct IO or libaio for file page store where applicable
> 
>
> Key: IGNITE-6341
> URL: https://issues.apache.org/jira/browse/IGNITE-6341
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.4
>
>
> Need try to use direct IO or libaio for page store because once data buffer 
> is serialized, we can write it as disk pages (this will also make it easier 
> if we decide to open file as a block device).



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

[jira] [Assigned] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reassigned IGNITE-7466:
--

Assignee: Denis Magda  (was: Dmitriy Pavlov)

[~dmagda], my description appeared to be quite large

https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-DirectI/O

Could you select information appropriate for docs? 


> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.5
>
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

[jira] [Comment Edited] (IGNITE-4161) Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from outside

[Ryan Samo (JIRA)]

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

Ryan Samo edited comment on IGNITE-4161 at 3/20/18 8:52 PM:


This would be very useful, allowing multiple scale-able Ignite clusters to run 
on the same bare metal cluster separated by Kubernetes namespaces. One issue is 
that hostNetwork=true would only allow for a single Ignite cluster to exist as 
it would consume the required Ignite ports on the host itself, thereby not 
allowing for 1:N clusters within the same Kubernetes deployment.


was (Author: one70six):
This would be very useful, allowing multiple scale-able Ignite clusters to run 
on the same bare metal cluster separated by Kubernetes namespaces. One issue is 
that hostNetwork=true would only allow for a single Ignite cluster to exist as 
it would consume the required ports Ignite ports on the host itself, thereby 
not allowing for 1:N clusters within the same Kubernetes deployment.

> Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from 
> outside
> ---
>
> Key: IGNITE-4161
> URL: https://issues.apache.org/jira/browse/IGNITE-4161
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Major
>
> Ignite cluster can be considered as a set of Kubernetes pods of a similar 
> type that are scaled across available hardware. To get access to the cluster 
> from outside the one has to use Kubernetes Service that will expose a single 
> public API address for the whole Ignite Cluster. 
> Let's think over how an Ignite client can connect to the Ignite's Kubernetes 
> cluster from outside, look up nodes and interact with them. As a result, most 
> likely we will implement a special discovery SPI for such "outside" nodes 
> that will connect to Kubernetes Service before the joining process.



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

[jira] [Commented] (IGNITE-4161) Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from outside

[Ryan Samo (JIRA)]

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

Ryan Samo commented on IGNITE-4161:
---

This would be very useful, allowing multiple scale-able Ignite clusters to run 
on the same bare metal cluster separated by Kubernetes namespaces. One issue is 
that hostNetwork=true would only allow for a single Ignite cluster to exist as 
it would consume the required ports Ignite ports on the host itself, thereby 
not allowing for 1:N clusters within the same Kubernetes deployment.

> Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from 
> outside
> ---
>
> Key: IGNITE-4161
> URL: https://issues.apache.org/jira/browse/IGNITE-4161
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Major
>
> Ignite cluster can be considered as a set of Kubernetes pods of a similar 
> type that are scaled across available hardware. To get access to the cluster 
> from outside the one has to use Kubernetes Service that will expose a single 
> public API address for the whole Ignite Cluster. 
> Let's think over how an Ignite client can connect to the Ignite's Kubernetes 
> cluster from outside, look up nodes and interact with them. As a result, most 
> likely we will implement a special discovery SPI for such "outside" nodes 
> that will connect to Kubernetes Service before the joining process.



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

[jira] [Commented] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7466:


I've started to collect info here:

https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-DirectI/O

> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

[jira] [Created] (IGNITE-8000) Implicit transactions may not finish properly on unstable topology.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-8000:
-

 Summary: Implicit transactions may not finish properly on unstable 
topology.
 Key: IGNITE-8000
 URL: https://issues.apache.org/jira/browse/IGNITE-8000
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Alexei Scherbakov
 Fix For: 2.5


Add default tx timeout [1] to IgniteCacheMultiTxLockSelfTest test configuration.

[1] c.getTransactionConfiguration().setDefaultTxTimeout(10);

Looks like in some case remote tx is added to rolled back version (because 
partition is gone) and subsequent near request for the same tx to this node 
fails.

This is not happen if timeouts are disabled because corresponding check is 
skipped.



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

[jira] [Comment Edited] (IGNITE-7090) Semaphore Stuck when no acquirers to assign permit

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev edited comment on IGNITE-7090 at 3/20/18 5:40 PM:


[~vladisav] I have triggered TC Run All. 
https://ci.ignite.apache.org/viewQueued.html?itemId=1148373
Will be ready in ~14 hours.


was (Author: edshanggg):
[~vladisav] I have triggered TC Run All. 
https://ci.ignite.apache.org/viewQueued.html?itemId=1148373
Will be ready in ~4 hours.

> Semaphore Stuck when no acquirers to assign permit
> --
>
> Key: IGNITE-7090
> URL: https://issues.apache.org/jira/browse/IGNITE-7090
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, data structures
>Affects Versions: 2.1, 2.4
>Reporter: Tim Onyschak
>Assignee: Tim Onyschak
>Priority: Major
> Fix For: 2.5
>
> Attachments: SemaphoreFailoverNoWaitingAcquirerTest.java
>
>
> If no acquirers are available to take permit of semaphore, the permit never 
> gets release and any further acquirerers will wait forever. 
> On node shut down DataStructuresProcessor.dsMap gets cleared out prior to 
> event listener being able to execute onNodeRemoved, hence owner is never 
> cleared out if it was unable to pass to a different acquirer. 
>  



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

[jira] [Commented] (IGNITE-7090) Semaphore Stuck when no acquirers to assign permit

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev commented on IGNITE-7090:
---

[~vladisav] I have triggered TC Run All. 
https://ci.ignite.apache.org/viewQueued.html?itemId=1148373
Will be ready in ~4 hours.

> Semaphore Stuck when no acquirers to assign permit
> --
>
> Key: IGNITE-7090
> URL: https://issues.apache.org/jira/browse/IGNITE-7090
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, data structures
>Affects Versions: 2.1, 2.4
>Reporter: Tim Onyschak
>Assignee: Tim Onyschak
>Priority: Major
> Fix For: 2.5
>
> Attachments: SemaphoreFailoverNoWaitingAcquirerTest.java
>
>
> If no acquirers are available to take permit of semaphore, the permit never 
> gets release and any further acquirerers will wait forever. 
> On node shut down DataStructuresProcessor.dsMap gets cleared out prior to 
> event listener being able to execute onNodeRemoved, hence owner is never 
> cleared out if it was unable to pass to a different acquirer. 
>  



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

[jira] [Commented] (IGNITE-6827) Configurable rollback for long running transactions before partition exchange

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-6827:
---

Latest TC run [1]

[1] https://ci.ignite.apache.org/viewQueued.html?itemId=1148082

> Configurable rollback for long running transactions before partition exchange
> -
>
> Key: IGNITE-6827
> URL: https://issues.apache.org/jira/browse/IGNITE-6827
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.5
>
>
> Currently long running / buggy user transactions force partition exchange 
> block on waiting for 
> org.apache.ignite.internal.processors.cache.GridCacheSharedContext#partitionReleaseFuture,
>  preventing all grid progress.
> I suggest introducing new global flag in TransactionConfiguration, like 
> {{txRollbackTimeoutOnTopologyChange}}
> which will rollback exchange blocking transaction after the timeout.
> Still need to think what to do with other topology locking activities.



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

[jira] [Updated] (IGNITE-7754) WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-7754:
---
Attachment: image-2018-03-20-19-08-42-234.png

> WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin
> --
>
> Key: IGNITE-7754
> URL: https://issues.apache.org/jira/browse/IGNITE-7754
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Ilya Lantukh
>Assignee: Ivan Rakov
>Priority: Critical
> Fix For: 2.5
>
> Attachments: image-2018-03-20-19-08-42-234.png
>
>
> On checkpoint begin method IgniteWriteAheadLogManager.fsync(WALPointer ptr) 
> will be called, but it won't actually perform fsync because mode isn't FSYNC. 
> It might lead to LFS corruption if OS or hardware failed until checkpoint had 
> been finished.



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

[jira] [Created] (IGNITE-7999) Enhance performance of the thin JDBC streaming mode

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-7999:


 Summary: Enhance performance of the thin JDBC streaming mode 
 Key: IGNITE-7999
 URL: https://issues.apache.org/jira/browse/IGNITE-7999
 Project: Ignite
  Issue Type: Task
  Components: jdbc
Affects Versions: 2.4
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.5


Try to enhance thin JDBC performance for streaming mode.
Waiting for server response takes a lot of time on streaming INSERT.
Try to skip server response in special mode.



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

[jira] [Commented] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-5553:
--

[~dpavlov], we discussed the PR with [~xtern] and replaced two init flags with 
single state field (that is, single mean of synchronization). Now I like the 
changes. 

> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.5
>
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



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

[jira] [Closed] (IGNITE-7887) [ML] Adopt SVM Linear Multi-Class Classification Model and Trainer to the new Partitioned Dataset

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev closed IGNITE-7887.


> [ML] Adopt SVM Linear Multi-Class Classification Model and Trainer to the new 
> Partitioned Dataset
> -
>
> Key: IGNITE-7887
> URL: https://issues.apache.org/jira/browse/IGNITE-7887
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-7931) Wrong arguments for ConcurrentHashMap

[Ivan Fedotov (JIRA)]

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

Ivan Fedotov updated IGNITE-7931:
-
Description: 
When creating ConcurrentHashMap:
{code:java|title=BinaryUtils.java}
new ConcurrentHashMap<>(U.capacity((map).size()));{code}
[1], [2] `U.capacity` returns capacity that is sufficient to keep the map from 
being resized. In ConcurrentHashMap this is unnecessary because recalculation 
already performs in the constructor.
 Similar problem in GridConcurrentHashSet because inside it implements 
ConcurrentHashMap:
{code:java|title=DataStreamerImpl.java}
keys = new GridConcurrentHashSet<>(entries.size(), U.capacity(entries.size()), 
1);{code}
[3],[4] result of `U.capacity` is passed as `loadFactor` value. When loadFactor 
== U.capacity, initial size of table is 1. 
 This leads to performance penalty due to rehashing of internal map.

 

[1[https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]

[2][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L688|https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]

[3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]

[4][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]

 

 

  was:
When creating
{code:java|title=DataStreamerImpl.java}
keys = new GridConcurrentHashSet<>(entries.size(), U.capacity(entries.size()), 
1);{code}
[1],[2] result of `U.capacity` is passed as `loadFactor` value. When loadFactor 
== U.capacity, initial size of table is 1. This leads to performance penalty 
due to rehashing of internal map.

[1][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]

[2][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]

 


>  Wrong arguments for ConcurrentHashMap
> --
>
> Key: IGNITE-7931
> URL: https://issues.apache.org/jira/browse/IGNITE-7931
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Trivial
> Fix For: 2.5
>
>
> When creating ConcurrentHashMap:
> {code:java|title=BinaryUtils.java}
> new ConcurrentHashMap<>(U.capacity((map).size()));{code}
> [1], [2] `U.capacity` returns capacity that is sufficient to keep the map 
> from being resized. In ConcurrentHashMap this is unnecessary because 
> recalculation already performs in the constructor.
>  Similar problem in GridConcurrentHashSet because inside it implements 
> ConcurrentHashMap:
> {code:java|title=DataStreamerImpl.java}
> keys = new GridConcurrentHashSet<>(entries.size(), 
> U.capacity(entries.size()), 1);{code}
> [3],[4] result of `U.capacity` is passed as `loadFactor` value. When 
> loadFactor == U.capacity, initial size of table is 1. 
>  This leads to performance penalty due to rehashing of internal map.
>  
> [1[https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]
> [2][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L688|https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]
> [3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]
> [4][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]
>  
>  



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

[jira] [Updated] (IGNITE-7931) Wrong arguments for ConcurrentHashMap

[Ivan Fedotov (JIRA)]

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

Ivan Fedotov updated IGNITE-7931:
-
Description: 
When creating ConcurrentHashMap:
{code:java|title=BinaryUtils.java}
new ConcurrentHashMap<>(U.capacity((map).size()));{code}
[1], [2] `U.capacity` returns capacity that is sufficient to keep the map from 
being resized. In ConcurrentHashMap this is unnecessary because recalculation 
already performs in the constructor.
 Similar problem in GridConcurrentHashSet because inside it implements 
ConcurrentHashMap:
{code:java|title=DataStreamerImpl.java}
keys = new GridConcurrentHashSet<>(entries.size(), U.capacity(entries.size()), 
1);{code}
[3],[4] result of `U.capacity` is passed as `loadFactor` value. When loadFactor 
== U.capacity, initial size of table is 1. 
 This leads to performance penalty due to rehashing of internal map.

 

[1][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]

[2][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L688|https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]

[3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]

[4][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]

  was:
When creating ConcurrentHashMap:
{code:java|title=BinaryUtils.java}
new ConcurrentHashMap<>(U.capacity((map).size()));{code}
[1], [2] `U.capacity` returns capacity that is sufficient to keep the map from 
being resized. In ConcurrentHashMap this is unnecessary because recalculation 
already performs in the constructor.
 Similar problem in GridConcurrentHashSet because inside it implements 
ConcurrentHashMap:
{code:java|title=DataStreamerImpl.java}
keys = new GridConcurrentHashSet<>(entries.size(), U.capacity(entries.size()), 
1);{code}
[3],[4] result of `U.capacity` is passed as `loadFactor` value. When loadFactor 
== U.capacity, initial size of table is 1. 
 This leads to performance penalty due to rehashing of internal map.

 

[1[https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]

[2][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L688|https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]

[3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]

[4][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]

 

 


>  Wrong arguments for ConcurrentHashMap
> --
>
> Key: IGNITE-7931
> URL: https://issues.apache.org/jira/browse/IGNITE-7931
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Trivial
> Fix For: 2.5
>
>
> When creating ConcurrentHashMap:
> {code:java|title=BinaryUtils.java}
> new ConcurrentHashMap<>(U.capacity((map).size()));{code}
> [1], [2] `U.capacity` returns capacity that is sufficient to keep the map 
> from being resized. In ConcurrentHashMap this is unnecessary because 
> recalculation already performs in the constructor.
>  Similar problem in GridConcurrentHashSet because inside it implements 
> ConcurrentHashMap:
> {code:java|title=DataStreamerImpl.java}
> keys = new GridConcurrentHashSet<>(entries.size(), 
> U.capacity(entries.size()), 1);{code}
> [3],[4] result of `U.capacity` is passed as `loadFactor` value. When 
> loadFactor == U.capacity, initial size of table is 1. 
>  This leads to performance penalty due to rehashing of internal map.
>  
> [1][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]
> [2][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L688|https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]
> [3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]
> [4][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]

[jira] [Commented] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7986:


[~VitaliyB], thank you for explanation and benchmark information. 

According your microbenchmark results this change seems to me as very useful 
contribution.

> GridPartitionStateMap.entrySet() optimization.
> --
>
> Key: IGNITE-7986
> URL: https://issues.apache.org/jira/browse/IGNITE-7986
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Attachments: GridPartitionStateMapBench.java, fullResult.txt
>
>
> GridPartitionStateMap based on BitSet. And the size of a BitSet depends on 
> the maximum key element, and not on the number of elements. 
> Just using the "BitSet.nextSetBit" method, will improve the performance of 
> the iterator for big clusters or caches with a large number of partitions.



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

[jira] [Updated] (IGNITE-7931) Wrong arguments for ConcurrentHashMap

[Ivan Fedotov (JIRA)]

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

Ivan Fedotov updated IGNITE-7931:
-
Summary:  Wrong arguments for ConcurrentHashMap  (was:  Wrong arguments for 
`keys` in DataStreamerImpl)

>  Wrong arguments for ConcurrentHashMap
> --
>
> Key: IGNITE-7931
> URL: https://issues.apache.org/jira/browse/IGNITE-7931
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Trivial
> Fix For: 2.5
>
>
> When creating
> {code:java|title=DataStreamerImpl.java}
> keys = new GridConcurrentHashSet<>(entries.size(), 
> U.capacity(entries.size()), 1);{code}
> [1],[2] result of `U.capacity` is passed as `loadFactor` value. When 
> loadFactor == U.capacity, initial size of table is 1. This leads to 
> performance penalty due to rehashing of internal map.
> [1][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]
> [2][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]
>  



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

[jira] [Updated] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-7986:
-
Attachment: fullResult.txt

> GridPartitionStateMap.entrySet() optimization.
> --
>
> Key: IGNITE-7986
> URL: https://issues.apache.org/jira/browse/IGNITE-7986
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Attachments: GridPartitionStateMapBench.java, fullResult.txt
>
>
> GridPartitionStateMap based on BitSet. And the size of a BitSet depends on 
> the maximum key element, and not on the number of elements. 
> Just using the "BitSet.nextSetBit" method, will improve the performance of 
> the iterator for big clusters or caches with a large number of partitions.



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

[jira] [Assigned] (IGNITE-7501) Improve underlying iterators closing process for cache iterators.

[Roman Kondakov (JIRA)]

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

Roman Kondakov reassigned IGNITE-7501:
--

Assignee: Roman Kondakov

> Improve underlying iterators closing process for cache iterators.
> -
>
> Key: IGNITE-7501
> URL: https://issues.apache.org/jira/browse/IGNITE-7501
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
>  Labels: cache, iterators, mvcc
> Fix For: 2.5
>
>
> When we call {{javax.cache.Cache#iterator()}}  we get {{java.util.Iterator}} 
> which doesn't have a {{close()}} method. But underlying 
> {{GridCloseableIterator}} does have this method and it should be called when 
> all the work with the current iterator is done. Currently calling {{close()}} 
> for the underlying closeable iterator is delegated to 
> {{WeakQueryCloseableIterator}}. So, {{close()}} method is usually called in 
> GridCacheGateway#onEnter or on a garbage collection phase, which is not 
> acceptable in some situations. For example if MVCC is enabled, this *late* 
> iterator closing could dramatically increase the active queries tracking list 
> size which  could lead to the performance and garbage collection ("vacuum") 
> issues.



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

[jira] [Commented] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov commented on IGNITE-7986:
--

[~dpavlov],

As far as I understand,  size of the GridPartitionStateMap depends on the 
number of nodes in the cluster, the number of backups and the number of 
partitions (except local map).  

Results of my benchmark for nonlocal partition maps. 
 |backups|nodes|partitions|current (ns/op)|new (ns/op)|new better times|
|0|10|1024|7773.397|3095.733|2.5110036944|
|0|10|2048|16087.69|6144.741|2.6181233676|
|0|10|4096|34482.486|12345.651|2.7930877035|
|0|10|8000|72479.404|26650.82|2.7195937686|
|0|10|16000|146432.544|58102.809|2.5202317499|
|0|10|32000|296809.492|120724.04|2.458578192|
|0|10|64000|594322.515|242735.119|2.4484405777|
|0|100|1024|4729.686|336.3|14.0638893845|
|0|100|2048|9415.128|647.433|14.5422429811|
|0|100|4096|21148.614|1316.889|16.0595266571|
|0|100|8000|38834.411|2621.357|14.8146212057|
|0|100|16000|82633.151|5140.644|16.0744745211|
|0|100|32000|173895.173|10422.767|16.6841658266|
|0|100|64000|342516.513|23952.39|14.2998887794|
|0|1000|1024|2426.349|46.471|52.2121107788|
|0|1000|2048|8139.08|108.815|74.7974084455|
|0|1000|4096|14454.287|240.411|60.1232347937|
|0|1000|8000|34907.128|489.104|71.3695410383|
|0|1000|16000|73389.182|944.313|77.7170090849|
|0|1000|32000|160308.128|1984.28|80.7890660592|
|0|1000|64000|324560.687|4079.957|79.5500263851|
|0|2000|1024|3.008|2.537|1.1856523453|
|0|2000|2048|5946.673|90.027|66.054328146|
|0|2000|4096|17325.297|138.235|125.3322024089|
|0|2000|8000|33072.617|348.708|94.8432986912|
|0|2000|16000|64440.651|745.311|86.461424828|
|0|2000|32000|155238.657|1479.522|104.9248723574|
|0|2000|64000|321251.884|3167.658|101.4162147555|
|1|10|1024|11171.521|6119.496|1.8255622685|
|1|10|2048|24172.271|12665.634|1.9084927766|
|1|10|4096|53294.77|26685.115|1.9971722063|
|1|10|8000|109864.099|53980.026|2.0352731768|
|1|10|16000|221824.913|113037.367|1.9624033971|
|1|10|32000|436256.482|230921.664|1.8891968577|
|1|10|64000|881911.03|459193.654|1.9205644989|
|1|100|1024|5129.195|629.328|8.1502729896|
|1|100|2048|10859.603|1250.619|8.683382389|
|1|100|4096|21685.862|2539.37|8.5398590989|
|1|100|8000|42293.47|4960.049|8.5268250374|
|1|100|16000|90791.646|10598.697|8.5663026314|
|1|100|32000|180378.316|21288.594|8.4730027732|
|1|100|64000|367885.521|51335.901|7.1662426067|
|1|1000|1024|2905.899|90.916|31.9624598531|
|1|1000|2048|9262.415|186.65|49.624571|
|1|1000|4096|18267.382|360.739|50.6387776204|
|1|1000|8000|32897.705|729.977|45.066769227|
|1|1000|16000|76443.255|1409.925|54.217958402|
|1|1000|32000|164860.382|2946.506|55.9511441687|
|1|1000|64000|330178.483|5966.129|55.3421628999|
|1|2000|1024|2292.627|55.323|41.4407570088|
|1|2000|2048|8686.208|108.265|80.2309887775|
|1|2000|4096|14479.482|242.147|59.7962477338|
|1|2000|8000|35766.976|484.239|73.8622374489|
|1|2000|16000|74094.016|962.648|76.968960617|
|1|2000|32000|157008.208|1986.852|79.0236051805|
|1|2000|64000|328899.34|4067.667|80.8569973894|
|2|10|1024|13852.683|9270.305|1.4943071452|
|2|10|2048|32389.393|19186.303|1.688151855|
|2|10|4096|71480.692|40449.752|1.7671478431|
|2|10|8000|145103.259|83085.115|1.7464410924|
|2|10|16000|298201.673|168707.071|1.7675706847|
|2|10|32000|597223.744|338370.431|1.7649998028|
|2|10|64000|1181314.547|677498.149|1.7436424716|
|2|100|1024|5556.731|929.405|5.9788047191|
|2|100|2048|11336.611|1884.978|6.0141874335|
|2|100|4096|23191.629|3724.606|6.2265992698|
|2|100|8000|46321.575|7395.63|6.2633710718|
|2|100|16000|96597.642|15122.088|6.3878508047|
|2|100|32000|198318.107|33385.073|5.9403227005|
|2|100|64000|390379.128|77205.45|5.0563674974|
|2|1000|1024|4275.427|107.752|39.6784004009|
|2|1000|2048|9002.224|240.328|37.4580739656|
|2|1000|4096|17506.322|478.795|36.5632932675|
|2|1000|8000|36023.671|936.647|38.4602427595|
|2|1000|16000|77573.168|1900.365|40.8201413939|
|2|1000|32000|166096.53|3807.846|43.6195502654|
|2|1000|64000|333527.89|8057.699|41.39244839|
|2|2000|1024|4215.233|40.166|104.9453019967|
|2|2000|2048|7817.065|140.176|55.7660726515|
|2|2000|4096|16460.534|302.354|54.4412642135|
|2|2000|8000|34834.671|595.045|58.5412380576|
|2|2000|16000|71198.703|1198.658|59.3986800238|
|2|2000|32000|164602.702|2441.896|67.4077446378|
|2|2000|64000|326950.689|5018.504|65.149034254|
|3|10|1024|17563.189|12591.11|1.3948880599|
|3|10|2048|40323.233|26827.544|1.5030534662|
|3|10|4096|90634.301|55372.915|1.636798442|
|3|10|8000|180605.006|112340.016|1.607664058|
|3|10|16000|377485.446|220576.124|1.7113613167|
|3|10|32000|719862.747|444048.477|1.6211354937|
|3|10|64000|1448648.778|888291.277|1.6308263016|
|3|100|1024|5953.177|1282.051|4.6434790816|
|3|100|2048|11867.489|2475.663|4.7936609304|
|3|100|4096|23781.162|4956.259|4.798208084|
|3|100|8000|50154.639|9918.107|5.0568761761|
|3|100|16000|101415.351|20612.608|4.920064021|

[jira] [Commented] (IGNITE-7998) SQL: Improve MVCC vacuum performance by iterating over data pages instead of cache tree.

[Roman Kondakov (JIRA)]

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

Roman Kondakov commented on IGNITE-7998:


There is a very raw prototype with a bunch of unsolved issues with persistence 
in professional/ignite-5936-proto-with-persistence branch.

> SQL: Improve MVCC vacuum performance by iterating over data pages instead of 
> cache tree. 
> -
>
> Key: IGNITE-7998
> URL: https://issues.apache.org/jira/browse/IGNITE-7998
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Roman Kondakov
>Priority: Major
>  Labels: iep-3
>
> At the moment vacuum process uses cache trees to find outdated (dead) entries 
> and cache and index trees to cleanup them. It is not efficient due to several 
> reasons. For example, we should lock a datapage for each cache tree entry to 
> find out if entry is dead.
> We can consider a direct iteration over datapages as a possible improvement 
> of  the vacuum process. Data page iteration prototype demonstrated 5-10 times 
> time improvement over the tree iteration.
> At first stage we need to implement direct datapages iteration only for 
> collecting dead entries links.
> At the second stage we need to consider removing links to dead entries from 
> index pages directly. In other words, we need to efficiently remove batches 
> of dead links from indexes without traversing cache and index tree one dead 
> link by one.



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

[jira] [Updated] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-7986:
-
Attachment: GridPartitionStateMapBench.java

> GridPartitionStateMap.entrySet() optimization.
> --
>
> Key: IGNITE-7986
> URL: https://issues.apache.org/jira/browse/IGNITE-7986
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Attachments: GridPartitionStateMapBench.java
>
>
> GridPartitionStateMap based on BitSet. And the size of a BitSet depends on 
> the maximum key element, and not on the number of elements. 
> Just using the "BitSet.nextSetBit" method, will improve the performance of 
> the iterator for big clusters or caches with a large number of partitions.



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

[jira] [Created] (IGNITE-7998) SQL: Improve MVCC vacuum performance by iterating over data pages instead of cache tree.

[Roman Kondakov (JIRA)]

Roman Kondakov created IGNITE-7998:
--

 Summary: SQL: Improve MVCC vacuum performance by iterating over 
data pages instead of cache tree. 
 Key: IGNITE-7998
 URL: https://issues.apache.org/jira/browse/IGNITE-7998
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Roman Kondakov


At the moment vacuum process uses cache trees to find outdated (dead) entries 
and cache and index trees to cleanup them. It is not efficient due to several 
reasons. For example, we should lock a datapage for each cache tree entry to 
find out if entry is dead.

We can consider a direct iteration over datapages as a possible improvement of  
the vacuum process. Data page iteration prototype demonstrated 5-10 times time 
improvement over the tree iteration.

At first stage we need to implement direct datapages iteration only for 
collecting dead entries links.

At the second stage we need to consider removing links to dead entries from 
index pages directly. In other words, we need to efficiently remove batches of 
dead links from indexes without traversing cache and index tree one dead link 
by one.



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

[jira] [Updated] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-7986:
-
Description: 
GridPartitionStateMap based on BitSet. And the size of a BitSet depends on the 
maximum key element, and not on the number of elements. 

Just using the "BitSet.nextSetBit" method, will improve the performance of the 
iterator for big clusters or caches with a large number of partitions.

  was:
GridPartitionStateMap based on BitSet. And the size of a BitSet depends on the 
maximum key element, and not on the number of elements. 

 

 

 

 

As far as I understand,  size of the GridPartitionStateMap depends on the 
number of nodes in the cluster, the number of backups and the number of 
partitions (except local map).  


> GridPartitionStateMap.entrySet() optimization.
> --
>
> Key: IGNITE-7986
> URL: https://issues.apache.org/jira/browse/IGNITE-7986
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
>
> GridPartitionStateMap based on BitSet. And the size of a BitSet depends on 
> the maximum key element, and not on the number of elements. 
> Just using the "BitSet.nextSetBit" method, will improve the performance of 
> the iterator for big clusters or caches with a large number of partitions.



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

[jira] [Updated] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-7986:
-
Description: 
GridPartitionStateMap based on BitSet. And the size of a BitSet depends on the 
maximum key element, and not on the number of elements. 

 

 

 

 

As far as I understand,  size of the GridPartitionStateMap depends on the 
number of nodes in the cluster, the number of backups and the number of 
partitions (except local map).  

  was:
GridPartitionStateMap based on BitSet. And size of BitSet depends on the 
maximum number of partitions contained, and not on the number of elements.

 

As far as I understand,  size of the GridPartitionStateMap depends on the 
number of nodes in the cluster, the number of backups and the number of 
partitions (except local map).  


> GridPartitionStateMap.entrySet() optimization.
> --
>
> Key: IGNITE-7986
> URL: https://issues.apache.org/jira/browse/IGNITE-7986
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
>
> GridPartitionStateMap based on BitSet. And the size of a BitSet depends on 
> the maximum key element, and not on the number of elements. 
>  
>  
>  
>  
> As far as I understand,  size of the GridPartitionStateMap depends on the 
> number of nodes in the cluster, the number of backups and the number of 
> partitions (except local map).  



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

[jira] [Updated] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-7986:
-
Description: 
GridPartitionStateMap based on BitSet. And size of BitSet depends on the 
maximum number of partitions contained, and not on the number of elements.

 

As far as I understand,  size of the GridPartitionStateMap depends on the 
number of nodes in the cluster, the number of backups and the number of 
partitions (except local map).  

  was:
 

 

As far as I understand,  size of the GridPartitionStateMap depends on the 
number of nodes in the cluster, the number of backups and the number of 
partitions (except local map).  


> GridPartitionStateMap.entrySet() optimization.
> --
>
> Key: IGNITE-7986
> URL: https://issues.apache.org/jira/browse/IGNITE-7986
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
>
> GridPartitionStateMap based on BitSet. And size of BitSet depends on the 
> maximum number of partitions contained, and not on the number of elements.
>  
> As far as I understand,  size of the GridPartitionStateMap depends on the 
> number of nodes in the cluster, the number of backups and the number of 
> partitions (except local map).  



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

[jira] [Updated] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-7986:
-
Description: 
 

 

As far as I understand,  size of the GridPartitionStateMap depends on the 
number of nodes in the cluster, the number of backups and the number of 
partitions (except local map).  

> GridPartitionStateMap.entrySet() optimization.
> --
>
> Key: IGNITE-7986
> URL: https://issues.apache.org/jira/browse/IGNITE-7986
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
>
>  
>  
> As far as I understand,  size of the GridPartitionStateMap depends on the 
> number of nodes in the cluster, the number of backups and the number of 
> partitions (except local map).  



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

[jira] [Commented] (IGNITE-7945) Apache Ignite nightly releases

[Peter Ivanov (JIRA)]

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

Peter Ivanov commented on IGNITE-7945:
--

Preliminary [build|https://ci.ignite.apache.org/viewLog.html?buildId=1146163] 
passed to QA.
[~skozlov], please, take it from here.

> Apache Ignite nightly releases
> --
>
> Key: IGNITE-7945
> URL: https://issues.apache.org/jira/browse/IGNITE-7945
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
>
> # As discussed 
> [here|http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-nightly-release-builds-td27966.html],
>  it is necessary to prepare build on [AI 
> TeamCity|https://ci.ignite.apache.org] which will run every night and will 
> build release binaries for *{{master}}* branch.
> # Prepare corresponding [Apache Ignite 
> Documentation|https://ignite.apache.org/download.cgi] section for link to 
> latest nightly release binaries.



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

[jira] [Commented] (IGNITE-7887) [ML] Adopt SVM Linear Multi-Class Classification Model and Trainer to the new Partitioned Dataset

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7887:


Github user asfgit closed the pull request at:

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


> [ML] Adopt SVM Linear Multi-Class Classification Model and Trainer to the new 
> Partitioned Dataset
> -
>
> Key: IGNITE-7887
> URL: https://issues.apache.org/jira/browse/IGNITE-7887
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




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

[jira] [Resolved] (IGNITE-7959) Deadlock at GridDhtAtomicCache.lockEntries during parallel SQL delete

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-7959.
-
Resolution: Duplicate

> Deadlock at GridDhtAtomicCache.lockEntries during parallel SQL delete
> -
>
> Key: IGNITE-7959
> URL: https://issues.apache.org/jira/browse/IGNITE-7959
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Pavel Vinokurov
>Priority: Major
> Attachments: DeadlockOnDelete.java
>
>
> Reproduce steps:
> 1. Run insert operations from single thread.
> 2. Run "delete from table limit 50" in 5 threads.
> The reproducer is attached.



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

[jira] [Closed] (IGNITE-7959) Deadlock at GridDhtAtomicCache.lockEntries during parallel SQL delete

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7959.
---

> Deadlock at GridDhtAtomicCache.lockEntries during parallel SQL delete
> -
>
> Key: IGNITE-7959
> URL: https://issues.apache.org/jira/browse/IGNITE-7959
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Pavel Vinokurov
>Priority: Major
> Attachments: DeadlockOnDelete.java
>
>
> Reproduce steps:
> 1. Run insert operations from single thread.
> 2. Run "delete from table limit 50" in 5 threads.
> The reproducer is attached.



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

[jira] [Commented] (IGNITE-7604) SQL TX: Allow DML operations with reducer

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-7604:


[~vozerov],

p.1,3,5,6,7) fixed.
p.2) In that case, the query will be processed with current one-step "query 
enlist" protocol.
In fact, 'isLocSubqry' is always false for anything other than INSERT, MERGE or 
BULK_LOAD (the latter being a mistake I guess).
Thus, if we remove the check for mode equal to INSERT or MERGE here, the UPDATE 
and DELETE queries will always be processed with new "map/reduce + batch" 
protocol, which is incorrect.

p.4) First we check that transaction context has a timeout handler installed(in 
absense of current operation it is a GridNearTxLocal own handler that would 
initiate a rollback).
We need to replace current "idle" handler with our own handler for the duration 
of our operation. So we call remove tx.removeTimeoutHandler().
If we fail to remove old handler, it means that tx is already timed out and we 
must arrange to be notified when transaction is rolled back in order to fail 
our own future.
If removal was successful, we install our own handler.
When our future is complete we restore the GridNearTxLocal's handler with a 
call to tx.addTimeoutHandler().

> SQL TX: Allow DML operations with reducer
> -
>
> Key: IGNITE-7604
> URL: https://issues.apache.org/jira/browse/IGNITE-7604
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Sergey Kalashnikov
>Priority: Major
>
> The following protocol is proposed for DML request with non-trivial reduce 
> step within a transaction.
> 1. The SQL select part is deduced from a DML request and is split to form 
> two-step map/reduce request.
> 2. Map query requests are sent to data nodes which execute them locally.
> 3. Resulting data pages are sent to originating node (reducer), which 
> accumulates them.
> 4. Originating node performs reduce step on data received from map nodes and 
> forms batches of updates to apply to target table.
> 5. Lock requests containing delta updates are mapped and sent to data nodes 
> storing the corresponding keys.
> 6. Lock acks are received at originating node and accumulated there, 
> producing the total update counter.
> Note that no locks are acquired when map requests are processed. 
> This is consistent with what Oracle and PostgreSQL do (but not MySQL!) with 
> respect to locks within complex DML statements.
> The Oracle docs 
> (https://docs.oracle.com/cd/B28359_01/server.111/b28318/consist.htm#CNCPT1351)
>  specifically states:
> The transaction that contains a DML statement does not need to acquire row 
> locks on any rows selected by a subquery or an implicit query, such as a 
> query in a WHERE clause. A subquery or implicit query in a DML statement is 
> guaranteed to be consistent as of the start of the query and does not see the 
> effects of the DML statement it is part of.



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

[jira] [Assigned] (IGNITE-7864) Control utility: Add confirm on dangerous operations

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev reassigned IGNITE-7864:
--

Assignee: Alexey Kuznetsov  (was: Sergey Kosarev)

> Control utility: Add confirm on dangerous operations
> 
>
> Key: IGNITE-7864
> URL: https://issues.apache.org/jira/browse/IGNITE-7864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> control.sh can deactivate cluster.
> It could be very dangerous in some cases.
> Lets add manual confirmation for dangerous operations: deactivate, change 
> base line, ...
> Also, lets add "-force" option to not ask for confirmation (will be useful in 
> scripts).
>  



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

[jira] [Commented] (IGNITE-7864) Control utility: Add confirm on dangerous operations

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev commented on IGNITE-7864:


fixed

> Control utility: Add confirm on dangerous operations
> 
>
> Key: IGNITE-7864
> URL: https://issues.apache.org/jira/browse/IGNITE-7864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Kosarev
>Priority: Major
> Fix For: 2.5
>
>
> control.sh can deactivate cluster.
> It could be very dangerous in some cases.
> Lets add manual confirmation for dangerous operations: deactivate, change 
> base line, ...
> Also, lets add "-force" option to not ask for confirmation (will be useful in 
> scripts).
>  



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

[jira] [Closed] (IGNITE-7931) Wrong arguments for `keys` in DataStreamerImpl

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov closed IGNITE-7931.


>  Wrong arguments for `keys` in DataStreamerImpl
> ---
>
> Key: IGNITE-7931
> URL: https://issues.apache.org/jira/browse/IGNITE-7931
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Trivial
> Fix For: 2.5
>
>
> When creating
> {code:java|title=DataStreamerImpl.java}
> keys = new GridConcurrentHashSet<>(entries.size(), 
> U.capacity(entries.size()), 1);{code}
> [1],[2] result of `U.capacity` is passed as `loadFactor` value. When 
> loadFactor == U.capacity, initial size of table is 1. This leads to 
> performance penalty due to rehashing of internal map.
> [1][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]
> [2][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]
>  



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

[jira] [Issue Comment Deleted] (IGNITE-7931) Wrong arguments for `keys` in DataStreamerImpl

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-7931:
-
Comment: was deleted

(was: Одобрено)

>  Wrong arguments for `keys` in DataStreamerImpl
> ---
>
> Key: IGNITE-7931
> URL: https://issues.apache.org/jira/browse/IGNITE-7931
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Trivial
> Fix For: 2.5
>
>
> When creating
> {code:java|title=DataStreamerImpl.java}
> keys = new GridConcurrentHashSet<>(entries.size(), 
> U.capacity(entries.size()), 1);{code}
> [1],[2] result of `U.capacity` is passed as `loadFactor` value. When 
> loadFactor == U.capacity, initial size of table is 1. This leads to 
> performance penalty due to rehashing of internal map.
> [1][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]
> [2][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]
>  



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

[jira] [Resolved] (IGNITE-7931) Wrong arguments for `keys` in DataStreamerImpl

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov resolved IGNITE-7931.
--
Resolution: Fixed

Одобрено

>  Wrong arguments for `keys` in DataStreamerImpl
> ---
>
> Key: IGNITE-7931
> URL: https://issues.apache.org/jira/browse/IGNITE-7931
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Trivial
> Fix For: 2.5
>
>
> When creating
> {code:java|title=DataStreamerImpl.java}
> keys = new GridConcurrentHashSet<>(entries.size(), 
> U.capacity(entries.size()), 1);{code}
> [1],[2] result of `U.capacity` is passed as `loadFactor` value. When 
> loadFactor == U.capacity, initial size of table is 1. This leads to 
> performance penalty due to rehashing of internal map.
> [1][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]
> [2][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]
>  



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

[jira] [Commented] (IGNITE-7237) Web console: Wrong switcher behaviour on grid deactivation

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin commented on IGNITE-7237:
--

[~vsisko] not reproduced

> Web console: Wrong switcher behaviour on grid deactivation
> --
>
> Key: IGNITE-7237
> URL: https://issues.apache.org/jira/browse/IGNITE-7237
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>Priority: Major
>
> # Run node and agent.
> # Open notebook page.
> # Activate grid.
> # Deactivate grid.
> In process of deactivation switcher transit to off state. In that transition 
> *Deactivation...* message is changed to "Activation...". Progress animation 
> is showed in some time after switcher state was changed.



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

[jira] [Assigned] (IGNITE-7237) Web console: Wrong switcher behaviour on grid deactivation

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-7237:


Assignee: Vasiliy Sisko  (was: Dmitriy Shabalin)

> Web console: Wrong switcher behaviour on grid deactivation
> --
>
> Key: IGNITE-7237
> URL: https://issues.apache.org/jira/browse/IGNITE-7237
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>Priority: Major
>
> # Run node and agent.
> # Open notebook page.
> # Activate grid.
> # Deactivate grid.
> In process of deactivation switcher transit to off state. In that transition 
> *Deactivation...* message is changed to "Activation...". Progress animation 
> is showed in some time after switcher state was changed.



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

[jira] [Commented] (IGNITE-7984) DML: improve deadlock handling

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7984:


Github user devozerov closed the pull request at:

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


> DML: improve deadlock handling 
> ---
>
> Key: IGNITE-7984
> URL: https://issues.apache.org/jira/browse/IGNITE-7984
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> Current DML implementation is not transactional. It groups keys in batches by 
> their affinity, and then flushes that batches synchronously. This could lead 
> to deadlocks easily.
> This could be improved if we sort key within a batch. However, this would 
> require new comparison function for {{BinaryObjectImpl}}, as it is not 
> comparable.



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

[jira] [Commented] (IGNITE-6113) Partition eviction prevents exchange from completion

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6113:


GitHub user Jokser opened a pull request:

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

IGNITE-6113 Backport to 2.4.3.b1



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

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

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

https://github.com/apache/ignite/pull/3662.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 #3662


commit e7ca9b65a68de7752195c8f4d2b5180f3c77d19f
Author: Dmitriy Govorukhin 
Date:   2017-11-13T18:52:47Z

ignite-blt-merge -> ignite-2.4.1

commit cc8168fc184bb7f5e3cc3bbb0743397097f78bfb
Author: Dmitriy Govorukhin 
Date:   2017-11-13T19:13:01Z

merge ignite-pitr-rc1 -> ignite-2.4.1

commit 87e6d74cf6a251c7984f9e68c391f790feccc281
Author: Dmitriy Govorukhin 
Date:   2017-11-14T12:49:33Z

ignite-gg-12877 Compact consistent ID in WAL

commit 9f5a22711baea05bd37ab07c8f928a4837dd83a4
Author: Ilya Lantukh 
Date:   2017-11-14T14:12:28Z

Fixed javadoc.

commit d5af2d78dd8eef8eca8ac5391d31d8c779649bb0
Author: Alexey Kuznetsov 
Date:   2017-11-15T08:09:00Z

IGNITE-6913 Baseline: Added new options to controls.sh for baseline 
manipulations.

commit 713924ce865752b6e99b03bd624136541cea5f9f
Author: Sergey Chugunov 
Date:   2017-11-15T09:03:12Z

IGNITE-5850 failover tests for cache operations during BaselineTopology 
changes

commit b65fd134e748d496f732ec2aa0953a0531f544b8
Author: Ilya Lantukh 
Date:   2017-11-15T12:54:35Z

TX read logging if PITR is enabled.

commit 9b2a567c0e04dc33116b51f88bee75f76e9107d1
Author: Ilya Lantukh 
Date:   2017-11-15T13:45:16Z

TX read logging if PITR is enabled.

commit 993058ccf0b2b8d9e80750c3e45a9ffa31d85dfa
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:51:54Z

ignite-2.4.1 optimization for store full set node more compacted

commit 1eba521f608d39967aec376b397b7fc800234e54
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:52:22Z

Merge remote-tracking branch 'professional/ignite-2.4.1' into ignite-2.4.1

commit 564b3fd51f8a7d1d81cb6874df66d0270623049c
Author: Sergey Chugunov 
Date:   2017-11-15T14:00:51Z

IGNITE-5850 fixed issue with initialization of data regions on node 
activation, fixed issue with auto-activation when random node joins inactive 
cluster with existing BLT

commit c6d1fa4da7adfadc80abdc7eaf6452b86a4f6aa4
Author: Sergey Chugunov 
Date:   2017-11-15T16:23:08Z

IGNITE-5850 transitionResult is set earlier when request for changing 
BaselineTopology is sent

commit d65674363163e38a4c5fdd73d1c8d8e1c7610797
Author: Sergey Chugunov 
Date:   2017-11-16T11:59:07Z

IGNITE-5850 new failover tests for changing BaselineTopology up (new node 
added to topology)

commit 20552f3851fe8825191b144179be032965e0b5c6
Author: Sergey Chugunov 
Date:   2017-11-16T12:53:43Z

IGNITE-5850 improved error message when online node is removed from baseline

commit 108bbcae4505ac904a6db774643ad600bfb42c21
Author: Sergey Chugunov 
Date:   2017-11-16T13:45:52Z

IGNITE-5850 BaselineTopology should not change on cluster deactivation

commit deb641ad3bdbf260fa60ad6bf607629652e324bd
Author: Dmitriy Govorukhin 
Date:   2017-11-17T09:45:44Z

ignite-2.4.1 truncate wal and checkpoint history on move/delete snapshot

commit 3c8b06f3659af30d1fd148ccc0f40e216a56c998
Author: Alexey Goncharuk 
Date:   2017-11-17T12:48:12Z

IGNITE-6947 Abandon remap after single map if future is done (fixes NPE)

commit ba2047e5ae7d271a677e0c418375d82d78c4023e
Author: devozerov 
Date:   2017-11-14T12:26:31Z

IGNITE-6901: Fixed assertion during 
IgniteH2Indexing.rebuildIndexesFromHash. This closes #3027.

commit abfc0466d6d61d87255d0fe38cbdf11ad46d4f89
Author: Sergey Chugunov 
Date:   2017-11-17T13:40:57Z

IGNITE-5850 tests for queries in presence of BaselineTopology

commit f4eabaf2a905abacc4c60c01d3ca04f6ca9ec188
Author: Sergey Chugunov 
Date:   2017-11-17T17:23:02Z

IGNITE-5850 implementation for setBaselineTopology(long topVer) migrated 
from wc-251

commit 4edeccd3e0b671aa277f58995df9ff9935baa95a
Author: EdShangGG 
Date:   2017-11-17T18:21:17Z

GG-13074 Multiple snapshot test failures after baseline topology is 
introduced
-adding baseline 

[jira] [Commented] (IGNITE-7770) Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 removal

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-7770:
--

[~agura], I've prepared a fix for "infinite park" scenario, could you please 
take a look?
NPE scenario is suppressed in the PR.

> Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 
> removal
> 
>
> Key: IGNITE-7770
> URL: https://issues.apache.org/jira/browse/IGNITE-7770
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 
> removal
> After appying IGNITE-7518 Get rid of org.jsr166.LongAdder8, 
>  IgniteCacheTestSuite6: 
> TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations (fail rate 
> 38,6%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3733584033131292028=%3Cdefault%3E=testDetails



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

[jira] [Commented] (IGNITE-7888) ODBC: Add support for SQL_ATTR_LOGIN_TIMEOUT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7888:


Github user asfgit closed the pull request at:

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


> ODBC: Add support for SQL_ATTR_LOGIN_TIMEOUT
> 
>
> Key: IGNITE-7888
> URL: https://issues.apache.org/jira/browse/IGNITE-7888
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> It would be great if we can support SQL_ATTR_LOGIN_TIMEOUT even without 
> login/password connection parameter. Now we have some default timeout for 
> initial ODBC connection establishment.



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

[jira] [Assigned] (IGNITE-7864) Control utility: Add confirm on dangerous operations

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7864:
--

Assignee: Sergey Kosarev  (was: Pavel Konstantinov)

> Control utility: Add confirm on dangerous operations
> 
>
> Key: IGNITE-7864
> URL: https://issues.apache.org/jira/browse/IGNITE-7864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Kosarev
>Priority: Major
> Fix For: 2.5
>
>
> control.sh can deactivate cluster.
> It could be very dangerous in some cases.
> Lets add manual confirmation for dangerous operations: deactivate, change 
> base line, ...
> Also, lets add "-force" option to not ask for confirmation (will be useful in 
> scripts).
>  



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

[jira] [Commented] (IGNITE-7864) Control utility: Add confirm on dangerous operations

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7864:


Please remove the warning from --baseline command.

> Control utility: Add confirm on dangerous operations
> 
>
> Key: IGNITE-7864
> URL: https://issues.apache.org/jira/browse/IGNITE-7864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> control.sh can deactivate cluster.
> It could be very dangerous in some cases.
> Lets add manual confirmation for dangerous operations: deactivate, change 
> base line, ...
> Also, lets add "-force" option to not ask for confirmation (will be useful in 
> scripts).
>  



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

[jira] [Commented] (IGNITE-7869) Dynamic start cache by stored cache data

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7869:


Github user akalash closed the pull request at:

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


> Dynamic start cache by stored cache data
> 
>
> Key: IGNITE-7869
> URL: https://issues.apache.org/jira/browse/IGNITE-7869
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.5
>
>
> Dynamic start cache by stored cache data



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

[jira] [Assigned] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-6816:


Assignee: Ilya Borisov  (was: Alexander Kalinin)

> Webconsole: investigate/integrate Webpack dll-plugin
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Trivial
>
> As the webconsole frontend app size grows, it takes more and more time to 
> incrementally rebuild after each source code change in development 
> environment. Let's investigate this plugin 
> https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack 
> build pipeline if it offers measureable performance improvements.



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

[jira] [Comment Edited] (IGNITE-7949) Web Console: Refactor post validation on sign in / sign up.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-7949 at 3/20/18 10:06 AM:


Code looks good.

Pavel, please test in branch.

To test:
 # Input not-existing e-mail on sign in.
 # Input existing e-mail on sign up.
 # Stop back end and try to sign-in/sign-up.
 # Forgot password: enter not-existing emial.


was (Author: kuaw26):
Code looks good.

Pavel, please test in branch.

To test:
 # Input not-existing e-mail on sign in.
 # Input existing e-mail on sign up.
 # Stop back end and try to sign-in/sign-up.

> Web Console: Refactor post validation on sign in / sign up.
> ---
>
> Key: IGNITE-7949
> URL: https://issues.apache.org/jira/browse/IGNITE-7949
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> In current implementation we show ugly popover in case of server error or 
> when backend unavailable at all.
>  
> Lets show errors as we do for input validation errors.
> And when server not available lets show proper message.



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

[jira] [Assigned] (IGNITE-7949) Web Console: Refactor post validation on sign in / sign up.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7949:


Assignee: Pavel Konstantinov  (was: Ilya Borisov)

Code looks good.

Pavel, please test in branch.

To test:
 # Input not-existing e-mail on sign in.
 # Input existing e-mail on sign up.
 # Stop back end and try to sign-in/sign-up.

> Web Console: Refactor post validation on sign in / sign up.
> ---
>
> Key: IGNITE-7949
> URL: https://issues.apache.org/jira/browse/IGNITE-7949
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> In current implementation we show ugly popover in case of server error or 
> when backend unavailable at all.
>  
> Lets show errors as we do for input validation errors.
> And when server not available lets show proper message.



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

[jira] [Commented] (IGNITE-7950) SQL: Add upload benchmarks for sql streamer feature

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7950:
--

[~pkouznet], the patch is OK with me.

> SQL: Add upload benchmarks for sql streamer feature
> ---
>
> Key: IGNITE-7950
> URL: https://issues.apache.org/jira/browse/IGNITE-7950
> Project: Ignite
>  Issue Type: Task
>  Components: sql, yardstick
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> IGNITE-7253 introduces streaming mode. 
> We need to update/create benchmarks to measure total upload time using single 
> and batched inserts
> Data model remains the same as in IGNITE-7531 : incrementaly generated long 
> primary key, 5 long and 5 strings (contains random long value in string 
> representation)



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

[jira] [Commented] (IGNITE-7647) Apache Ignite RPM packages (Stage II)

[Peter Ivanov (JIRA)]

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

Peter Ivanov commented on IGNITE-7647:
--

Selected splitting scheme for implementation:
* *apache-ignite-core*
** bin
** config
** libs (!optional)
* *apache-ignite-libs*
** optional libs
* *apache-ignite-benchmarks*
* *apache-ignite-docs*
* *apache-ignite-examples*
* *apache-ignite-dotnet*
* *apache-ignite-cpp*

> Apache Ignite RPM packages (Stage II)
> -
>
> Key: IGNITE-7647
> URL: https://issues.apache.org/jira/browse/IGNITE-7647
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.5
>
>
> # Repack RPM specification to:
> #* be able to build package from source code (?)
> #* divide single package into multiple packages (core + optional).
> # Introduce process of PRM building in release procedure.
> # Introduce repository update scheme.



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

[jira] [Updated] (IGNITE-7945) Apache Ignite nightly releases

[Peter Ivanov (JIRA)]

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

Peter Ivanov updated IGNITE-7945:
-
Description: 
# As discussed 
[here|http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-nightly-release-builds-td27966.html],
 it is necessary to prepare build on [AI TeamCity|https://ci.ignite.apache.org] 
which will run every night and will build release binaries for *{{master}}* 
branch.
# Prepare corresponding [Apache Ignite 
Documentation|https://ignite.apache.org/download.cgi] section for link to 
latest nightly release binaries.

  was:
# As discussed 
[here|http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-nightly-release-builds-td27966.html],
 it is necessary to prepare build on [AI TeamCity|ttps://ci.ignite.apache.org] 
which will run every night and will build release binaries for *{{master}}* 
branch.
# Prepare corresponding [Apache Ignite 
Documentation|https://ignite.apache.org/download.cgi] section for link to 
latest nightly release binaries.


> Apache Ignite nightly releases
> --
>
> Key: IGNITE-7945
> URL: https://issues.apache.org/jira/browse/IGNITE-7945
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
>
> # As discussed 
> [here|http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-nightly-release-builds-td27966.html],
>  it is necessary to prepare build on [AI 
> TeamCity|https://ci.ignite.apache.org] which will run every night and will 
> build release binaries for *{{master}}* branch.
> # Prepare corresponding [Apache Ignite 
> Documentation|https://ignite.apache.org/download.cgi] section for link to 
> latest nightly release binaries.



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

[jira] [Updated] (IGNITE-7647) Apache Ignite RPM packages (Stage II)

[Peter Ivanov (JIRA)]

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

Peter Ivanov updated IGNITE-7647:
-
Description: 
# Repack RPM specification to:
#* be able to build package from source code (?)
#* divide single package into multiple packages (core + optional).
# Introduce process of PRM building in release procedure.
# Introduce repository update scheme.

  was:
# Repack RPM specification to:
#* be able to build package from source code
#* divide single package into multiple packages (core + optional).
# Introduce process of PRM building in release procedure.
# Introduce repository update scheme.


> Apache Ignite RPM packages (Stage II)
> -
>
> Key: IGNITE-7647
> URL: https://issues.apache.org/jira/browse/IGNITE-7647
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.5
>
>
> # Repack RPM specification to:
> #* be able to build package from source code (?)
> #* divide single package into multiple packages (core + optional).
> # Introduce process of PRM building in release procedure.
> # Introduce repository update scheme.



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

[jira] [Closed] (IGNITE-6378) Web console: Demo mode panel hide part of affix panel.

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin closed IGNITE-6378.
-

> Web console: Demo mode panel hide part of affix panel.
> --
>
> Key: IGNITE-6378
> URL: https://issues.apache.org/jira/browse/IGNITE-6378
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>Priority: Major
>




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

[jira] [Commented] (IGNITE-7976) [Test failed] IgnitePersistentStoreCacheGroupsTest.testClusterRestartCachesWithH2Indexes fails on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7976:


Github user asfgit closed the pull request at:

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


> [Test failed] 
> IgnitePersistentStoreCacheGroupsTest.testClusterRestartCachesWithH2Indexes 
> fails on TC
> 
>
> Key: IGNITE-7976
> URL: https://issues.apache.org/jira/browse/IGNITE-7976
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test 
> {{IgnitePersistentStoreCacheGroupsTest.testClusterRestartCachesWithH2Indexes}}
>  always fail on TeamCity due to changes by IGNITE-7869. With the following 
> error:
> {noformat}
> javax.cache.CacheException: Failed to parse query. Table "PERSON" not found; 
> SQL statement:
> SELECT p._KEY, p._VAL FROM Person p WHERE p.lname=? ORDER BY p.fname 
> [42102-195]
> ...
> {noformat}



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

[jira] [Comment Edited] (IGNITE-6378) Web console: Demo mode panel hide part of affix panel.

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin edited comment on IGNITE-6378 at 3/20/18 9:31 AM:


Configuration screen has been reimplmented in IGNITE-5466. Issue is not actual 
anymore.


was (Author: alexdel):
Configuration screen has been reimplmented. Issue is not actual anymore.

> Web console: Demo mode panel hide part of affix panel.
> --
>
> Key: IGNITE-6378
> URL: https://issues.apache.org/jira/browse/IGNITE-6378
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>Priority: Major
>




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

[jira] [Resolved] (IGNITE-6378) Web console: Demo mode panel hide part of affix panel.

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin resolved IGNITE-6378.
---
Resolution: Won't Fix

> Web console: Demo mode panel hide part of affix panel.
> --
>
> Key: IGNITE-6378
> URL: https://issues.apache.org/jira/browse/IGNITE-6378
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>Priority: Major
>




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

[jira] [Commented] (IGNITE-6378) Web console: Demo mode panel hide part of affix panel.

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-6378:
---

Configuration screen has been reimplmented. Issue is not actual anymore.

> Web console: Demo mode panel hide part of affix panel.
> --
>
> Key: IGNITE-6378
> URL: https://issues.apache.org/jira/browse/IGNITE-6378
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>Priority: Major
>




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

[jira] [Assigned] (IGNITE-6378) Web console: Demo mode panel hide part of affix panel.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6378:


Assignee: Alexander Kalinin  (was: Dmitriy Shabalin)

> Web console: Demo mode panel hide part of affix panel.
> --
>
> Key: IGNITE-6378
> URL: https://issues.apache.org/jira/browse/IGNITE-6378
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>Priority: Major
>




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

[jira] [Assigned] (IGNITE-5466) Web Console: New Configuration Screen

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-5466:


Assignee: Alexey Kuznetsov  (was: Ilya Borisov)

> Web Console: New Configuration Screen
> -
>
> Key: IGNITE-5466
> URL: https://issues.apache.org/jira/browse/IGNITE-5466
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Alexey Kuznetsov
>Priority: Major
>




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

[jira] [Comment Edited] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin edited comment on IGNITE-6816 at 3/20/18 9:20 AM:


There is a branch ignite-6816-webpack4 which holds new webpack 4 dependencies.


was (Author: alexdel):
There is a branch 
[ignite-6816-webpack4|https://github.com/gridgain/apache-ignite/tree/ignite-6816-webpack4]
 which holds new webpack 4 dependencies.

> Webconsole: investigate/integrate Webpack dll-plugin
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Alexander Kalinin
>Priority: Trivial
>
> As the webconsole frontend app size grows, it takes more and more time to 
> incrementally rebuild after each source code change in development 
> environment. Let's investigate this plugin 
> https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack 
> build pipeline if it offers measureable performance improvements.



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

[jira] [Commented] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-6816:
---

There is a branch 
[ignite-6816-webpack4|https://github.com/gridgain/apache-ignite/tree/ignite-6816-webpack4]
 which holds new webpack 4 dependencies.

> Webconsole: investigate/integrate Webpack dll-plugin
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Alexander Kalinin
>Priority: Trivial
>
> As the webconsole frontend app size grows, it takes more and more time to 
> incrementally rebuild after each source code change in development 
> environment. Let's investigate this plugin 
> https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack 
> build pipeline if it offers measureable performance improvements.



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

[jira] [Updated] (IGNITE-7976) [Test failed] IgnitePersistentStoreCacheGroupsTest.testClusterRestartCachesWithH2Indexes fails on TC

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7976:

Component/s: sql

> [Test failed] 
> IgnitePersistentStoreCacheGroupsTest.testClusterRestartCachesWithH2Indexes 
> fails on TC
> 
>
> Key: IGNITE-7976
> URL: https://issues.apache.org/jira/browse/IGNITE-7976
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test 
> {{IgnitePersistentStoreCacheGroupsTest.testClusterRestartCachesWithH2Indexes}}
>  always fail on TeamCity due to changes by IGNITE-7869. With the following 
> error:
> {noformat}
> javax.cache.CacheException: Failed to parse query. Table "PERSON" not found; 
> SQL statement:
> SELECT p._KEY, p._VAL FROM Person p WHERE p.lname=? ORDER BY p.fname 
> [42102-195]
> ...
> {noformat}



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

[jira] [Commented] (IGNITE-7864) Control utility: Add confirm on dangerous operations

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev commented on IGNITE-7864:


1. you are correct, we don't print waring for --baseline as it only prints 
current baseline state.
2. fixed:
  Deactivate cluster:
control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password 
PASSWORD] --deactivate [--force]

  Add nodes into baseline topology:
control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password 
PASSWORD] --baseline add consistentId1[,consistentId2,,consistentIdN] 
[--force]

  Remove nodes from baseline topology:
control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password 
PASSWORD] --baseline remove consistentId1[,consistentId2,,consistentIdN] 
[--force]

  Set baseline topology:
control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password 
PASSWORD] --baseline set consistentId1[,consistentId2,,consistentIdN] 
[--force]

  Set baseline topology based on version:
control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password 
PASSWORD] --baseline version topologyVersion [--force]

By default cluster deactivation and changes in baseline topology commands 
request interactive confirmation. 
  --force option can be used to execute commands without prompting for 
confirmation.

> Control utility: Add confirm on dangerous operations
> 
>
> Key: IGNITE-7864
> URL: https://issues.apache.org/jira/browse/IGNITE-7864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Kosarev
>Priority: Major
> Fix For: 2.5
>
>
> control.sh can deactivate cluster.
> It could be very dangerous in some cases.
> Lets add manual confirmation for dangerous operations: deactivate, change 
> base line, ...
> Also, lets add "-force" option to not ask for confirmation (will be useful in 
> scripts).
>  



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

[jira] [Assigned] (IGNITE-7864) Control utility: Add confirm on dangerous operations

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev reassigned IGNITE-7864:
--

Assignee: Pavel Konstantinov  (was: Sergey Kosarev)

> Control utility: Add confirm on dangerous operations
> 
>
> Key: IGNITE-7864
> URL: https://issues.apache.org/jira/browse/IGNITE-7864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> control.sh can deactivate cluster.
> It could be very dangerous in some cases.
> Lets add manual confirmation for dangerous operations: deactivate, change 
> base line, ...
> Also, lets add "-force" option to not ask for confirmation (will be useful in 
> scripts).
>  



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

[jira] [Commented] (IGNITE-5466) Web Console: New Configuration Screen

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin commented on IGNITE-5466:
--

[~Klaster_1] all good

> Web Console: New Configuration Screen
> -
>
> Key: IGNITE-5466
> URL: https://issues.apache.org/jira/browse/IGNITE-5466
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Dmitriy Shabalin
>Priority: Major
>




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

[jira] [Assigned] (IGNITE-5466) Web Console: New Configuration Screen

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-5466:


Assignee: Ilya Borisov  (was: Dmitriy Shabalin)

> Web Console: New Configuration Screen
> -
>
> Key: IGNITE-5466
> URL: https://issues.apache.org/jira/browse/IGNITE-5466
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Ilya Borisov
>Priority: Major
>




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

[jira] [Assigned] (IGNITE-7359) SQL: DDL synchronization with query and cache API operations

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-7359:
---

Assignee: Vladimir Ozerov  (was: Sergey Kalashnikov)

> SQL: DDL synchronization with query and cache API operations
> 
>
> Key: IGNITE-7359
> URL: https://issues.apache.org/jira/browse/IGNITE-7359
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Sergey Kalashnikov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> We need to add a means to synchronize DDL operations with queries and cache 
> operations. This is required to facilitate future DDL improvements that would 
> require to modify user data and/or some cache metadata atomically. Basically 
> it is a sort of a global table lock.
> One way to achieve this is to re-use a mechanism used by the exchange 
> procedure. 
> An exchange is waiting for all already started cache operations to end before 
> proceeding itself.
> Likewise, the new cache operations won't start until exchange procedure has 
> completed.
> However, for DDL we only need to selectively defer operations that are made 
> on the same cache as DDL operation.



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

[jira] [Assigned] (IGNITE-7359) SQL: DDL synchronization with query and cache API operations

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-7359:
---

Assignee: Sergey Kalashnikov  (was: Vladimir Ozerov)

> SQL: DDL synchronization with query and cache API operations
> 
>
> Key: IGNITE-7359
> URL: https://issues.apache.org/jira/browse/IGNITE-7359
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
>Priority: Major
> Fix For: 2.5
>
>
> We need to add a means to synchronize DDL operations with queries and cache 
> operations. This is required to facilitate future DDL improvements that would 
> require to modify user data and/or some cache metadata atomically. Basically 
> it is a sort of a global table lock.
> One way to achieve this is to re-use a mechanism used by the exchange 
> procedure. 
> An exchange is waiting for all already started cache operations to end before 
> proceeding itself.
> Likewise, the new cache operations won't start until exchange procedure has 
> completed.
> However, for DDL we only need to selectively defer operations that are made 
> on the same cache as DDL operation.



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

[jira] [Commented] (IGNITE-7207) Exchange worker dies if index contains non existent field

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7207:
-

is not related to SQL, this is more general problem - any exception on dynamic 
cache start leads to exchange hang.

> Exchange worker dies if index contains non existent field
> -
>
> Key: IGNITE-7207
> URL: https://issues.apache.org/jira/browse/IGNITE-7207
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Stanislav Lukyanov
>Priority: Major
> Attachments: Test.java
>
>
> If {{QueryEntity}} contains an index with a non existent field, 
> {{createCache}} first throws this exception which is correct:
> {noformat}
> [2017-12-14 
> 18:51:23,627][ERROR][exchange-worker-#42%null%][CacheAffinitySharedManager] 
> Failed to initialize cache. Will try to rollback cache start routine. 
> [cacheName=test]
> class org.apache.ignite.IgniteCheckedException: Field not found: a
>   at 
> org.apache.ignite.internal.processors.query.QueryIndexDescriptorImpl.addField(QueryIndexDescriptorImpl.java:124)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.createIndexDescriptor(QueryUtils.java:631)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processIndex(QueryUtils.java:648)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processIndexes(QueryUtils.java:584)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processBinaryMeta(QueryUtils.java:542)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:438)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:687)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:836)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1816)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:751)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:882)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:588)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2278)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> Exception in thread "main" javax.cache.CacheException: class 
> org.apache.ignite.IgniteCheckedException: Field not found: a
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1327)
>   at 
> org.apache.ignite.internal.IgniteKernal.createCache(IgniteKernal.java:2817)
>   at Test.main(Test.java:36)
>   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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: class org.apache.ignite.IgniteCheckedException: Field not found: a
>   at 
> org.apache.ignite.internal.processors.query.QueryIndexDescriptorImpl.addField(QueryIndexDescriptorImpl.java:124)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.createIndexDescriptor(QueryUtils.java:631)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processIndex(QueryUtils.java:648)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processIndexes(QueryUtils.java:584)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processBinaryMeta(QueryUtils.java:542)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:438)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:687)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:836)
>   at 
> 

[jira] [Updated] (IGNITE-7207) Exchange worker dies if index contains non existent field

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7207:

Component/s: (was: sql)

> Exchange worker dies if index contains non existent field
> -
>
> Key: IGNITE-7207
> URL: https://issues.apache.org/jira/browse/IGNITE-7207
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Stanislav Lukyanov
>Priority: Major
> Attachments: Test.java
>
>
> If {{QueryEntity}} contains an index with a non existent field, 
> {{createCache}} first throws this exception which is correct:
> {noformat}
> [2017-12-14 
> 18:51:23,627][ERROR][exchange-worker-#42%null%][CacheAffinitySharedManager] 
> Failed to initialize cache. Will try to rollback cache start routine. 
> [cacheName=test]
> class org.apache.ignite.IgniteCheckedException: Field not found: a
>   at 
> org.apache.ignite.internal.processors.query.QueryIndexDescriptorImpl.addField(QueryIndexDescriptorImpl.java:124)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.createIndexDescriptor(QueryUtils.java:631)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processIndex(QueryUtils.java:648)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processIndexes(QueryUtils.java:584)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processBinaryMeta(QueryUtils.java:542)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:438)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:687)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:836)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1816)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:751)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:882)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:588)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2278)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> Exception in thread "main" javax.cache.CacheException: class 
> org.apache.ignite.IgniteCheckedException: Field not found: a
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1327)
>   at 
> org.apache.ignite.internal.IgniteKernal.createCache(IgniteKernal.java:2817)
>   at Test.main(Test.java:36)
>   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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: class org.apache.ignite.IgniteCheckedException: Field not found: a
>   at 
> org.apache.ignite.internal.processors.query.QueryIndexDescriptorImpl.addField(QueryIndexDescriptorImpl.java:124)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.createIndexDescriptor(QueryUtils.java:631)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processIndex(QueryUtils.java:648)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processIndexes(QueryUtils.java:584)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.processBinaryMeta(QueryUtils.java:542)
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:438)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:687)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:836)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:)
>   at 
> 

[jira] [Assigned] (IGNITE-7537) SQL COPY command: implement CSV format options

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-7537:
---

Assignee: (was: Vladimir Ozerov)

> SQL COPY command: implement CSV format options
> --
>
> Key: IGNITE-7537
> URL: https://issues.apache.org/jira/browse/IGNITE-7537
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Kirill Shirokov
>Priority: Major
>
> The following options can be implemented for the CSV format:
> * Line separator pattern
> * Field separator pattern
> * Set of quote characters
> * Escape sequence start character
> * Line comment character
> Escape sequences support is important for this feature. There is a draft code 
> for handling escape sequences in a branch called ignite-7372 (see IGNITE-7372 
> for details).
> Syntax example:
> {noformat}
> COPY
> ...
> FORMAT CSV
> [FIELDSEP='column-separators-regexp']
> [LINESEP='row-separators-regexp']
> [QUOTE='quote-chars']
> [ESCAPE='escape-char']
> [COMMENT='line-comment-char']
> {noformat}
> We may also want:
> * Line comments handling
> * Spaces trimming
> * Empty lines skipping



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

[jira] [Assigned] (IGNITE-7605) SQL COPY: add more SQL parser tests for positive scenarios

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-7605:
---

Assignee: Vladimir Ozerov  (was: Kirill Shirokov)

> SQL COPY: add more SQL parser tests for positive scenarios
> --
>
> Key: IGNITE-7605
> URL: https://issues.apache.org/jira/browse/IGNITE-7605
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Assignee: Vladimir Ozerov
>Priority: Major
>




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

[jira] [Assigned] (IGNITE-7605) SQL COPY: add more SQL parser tests for positive scenarios

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-7605:
---

Assignee: (was: Vladimir Ozerov)

> SQL COPY: add more SQL parser tests for positive scenarios
> --
>
> Key: IGNITE-7605
> URL: https://issues.apache.org/jira/browse/IGNITE-7605
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Priority: Major
>




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

[jira] [Assigned] (IGNITE-7537) SQL COPY command: implement CSV format options

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-7537:
---

Assignee: Vladimir Ozerov  (was: Kirill Shirokov)

> SQL COPY command: implement CSV format options
> --
>
> Key: IGNITE-7537
> URL: https://issues.apache.org/jira/browse/IGNITE-7537
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Kirill Shirokov
>Assignee: Vladimir Ozerov
>Priority: Major
>
> The following options can be implemented for the CSV format:
> * Line separator pattern
> * Field separator pattern
> * Set of quote characters
> * Escape sequence start character
> * Line comment character
> Escape sequences support is important for this feature. There is a draft code 
> for handling escape sequences in a branch called ignite-7372 (see IGNITE-7372 
> for details).
> Syntax example:
> {noformat}
> COPY
> ...
> FORMAT CSV
> [FIELDSEP='column-separators-regexp']
> [LINESEP='row-separators-regexp']
> [QUOTE='quote-chars']
> [ESCAPE='escape-char']
> [COMMENT='line-comment-char']
> {noformat}
> We may also want:
> * Line comments handling
> * Spaces trimming
> * Empty lines skipping



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

[jira] [Updated] (IGNITE-7281) .NET: Services do not work on .NET Core

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7281:

Fix Version/s: 2.4

> .NET: Services do not work on .NET Core
> ---
>
> Key: IGNITE-7281
> URL: https://issues.apache.org/jira/browse/IGNITE-7281
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Rokhin
>Priority: Major
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> We rely on {{System.Runtime.Remoting.Proxies.RealProxy}} for dynamic proxy 
> generation. However, remoting is not supported on .NET Core.
> Investigate whether we can get rid of RealProxy and generate runtime proxies 
> manually. Basically, we need to emit an interface implementation where every 
> method just delegates to our code.



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