[jira] [Created] (IGNITE-6042) Update KafkaStreamer dependencies to Kafka 0.11.x

[Roman Shtykh (JIRA)]

Roman Shtykh created IGNITE-6042:


 Summary: Update KafkaStreamer dependencies to Kafka 0.11.x
 Key: IGNITE-6042
 URL: https://issues.apache.org/jira/browse/IGNITE-6042
 Project: Ignite
  Issue Type: Task
  Components: streaming
Reporter: Roman Shtykh
Assignee: Roman Shtykh
 Fix For: 2.2






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6013) Web agent: refactor processing response from cluster

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6013:


Resolution: Fixed
  Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Web agent: refactor processing response from cluster
> 
>
> Key: IGNITE-6013
> URL: https://issues.apache.org/jira/browse/IGNITE-6013
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>
> RestExecutor.sendRequest() contain following code:
> {code}
> 
> try (Response resp = 
> httpClient.newCall(reqBuilder.build()).execute()) {
> String content = resp.body().string();
> if (resp.isSuccessful()) {
> JsonNode node = mapper.readTree(content);
>  
> {code}
> Problems: 
> # String content = resp.body().string(); >> Generate not needed String.
> # JsonNode node = mapper.readTree(content);  >> Generates a big tree of 
> JsonNodes
>  
> Could be fixed like:
> RestResponseHolder res = MAPPER.readValue(resp.body().byteStream(), 
> RestResponseHolder.class); 
> Where for RestResponseHolder should also created optimized 
> RestResponseHolderDeserializer that will extract response as String without 
> building tree of JsonNodes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6013) Web agent: refactor processing response from cluster

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-6013.


Merge to master.

> Web agent: refactor processing response from cluster
> 
>
> Key: IGNITE-6013
> URL: https://issues.apache.org/jira/browse/IGNITE-6013
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>
> RestExecutor.sendRequest() contain following code:
> {code}
> 
> try (Response resp = 
> httpClient.newCall(reqBuilder.build()).execute()) {
> String content = resp.body().string();
> if (resp.isSuccessful()) {
> JsonNode node = mapper.readTree(content);
>  
> {code}
> Problems: 
> # String content = resp.body().string(); >> Generate not needed String.
> # JsonNode node = mapper.readTree(content);  >> Generates a big tree of 
> JsonNodes
>  
> Could be fixed like:
> RestResponseHolder res = MAPPER.readValue(resp.body().byteStream(), 
> RestResponseHolder.class); 
> Where for RestResponseHolder should also created optimized 
> RestResponseHolderDeserializer that will extract response as String without 
> building tree of JsonNodes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6012) Improve GridJettyRestHandler.processRequest()

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-6012.


> Improve GridJettyRestHandler.processRequest()
> -
>
> Key: IGNITE-6012
> URL: https://issues.apache.org/jira/browse/IGNITE-6012
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.1
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>
> In case of large result  
> {code}
> private void processRequest(String act, HttpServletRequest req, 
> HttpServletResponse res) {
> ...
> json = jsonMapper.writeValueAsString(cmdRes)
> 
> {code}
> Will fail with OOME, beacuse jsonMapper.writeValueAsString(cmdRes) internally 
> will create a StringBuilder and will try to allocate large amount of memory.
> This could be easily fixed by writing object directly to response output 
> stream via. 
> {code}
> jsonMapper.writeValue(out, cmdRes);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5902) Refactor VisorCacheStopTask to support stopping several caches at once

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-5902:


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

Merged to master. Please retest.

> Refactor  VisorCacheStopTask to support stopping several caches at once
> ---
>
> Key: IGNITE-5902
> URL: https://issues.apache.org/jira/browse/IGNITE-5902
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.2
>
>
> Stopping several caches at once much more faster then one-by-one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6039) Update Persistence page on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6039:
--
Description: 
# add Write-Ahead-Log (WAL) sub-section
# add Main Storage sub-section
# add Checkpointing sub-section
# add Redundancy sub-section (describe backups)
# add Durability sub-section (describe restarts)
# add Configuration example
# provide a better diagram if possible

  was:
# add Write-Ahead-Log (WAL) sub-section
# add Main Storage sub-section
# add Checkpointing sub-section
# add Redundancy sub-section (describe backups)
# add Durability sub-section (describe restarts)
# add Configuration example


> Update Persistence page on the website
> --
>
> Key: IGNITE-6039
> URL: https://issues.apache.org/jira/browse/IGNITE-6039
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> # add Write-Ahead-Log (WAL) sub-section
> # add Main Storage sub-section
> # add Checkpointing sub-section
> # add Redundancy sub-section (describe backups)
> # add Durability sub-section (describe restarts)
> # add Configuration example
> # provide a better diagram if possible



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6036:
--
Description: 
Need to make the following changes to the use case section on the website:
# Add new section in the dropdown: Distributed Database
## add Distributed Transactional Database page
## add In-Memory Database page
## add Ignite vs NoSQL Databases
## add Ignite vs RDBMS Databases
# Under In-Memory Caching Section
## add Ignite and In-Memory Data Grids page (explain persistence)
## fix Key-Value Store page to reflect native persistence
## fix JCache Provider page to reflect native persistence


  was:
Need to make the following changes to the use case section on the website:
# Add new section in the dropdown: Distributed Database
## add Distributed Transactional Database page
## add In-Memory Database page
## add Ignite vs NoSQL Databases
## add Ignite vs RDBMS Databases
# Under In-Memory Caching Section
## add Ignite and traditional In-Memory Data Grids page (explain persistence)
## fix Key-Value Store page to reflect native persistence
## fix JCache Provider page to reflect native persistence



> Ignite 2.1 use case changes on the website
> --
>
> Key: IGNITE-6036
> URL: https://issues.apache.org/jira/browse/IGNITE-6036
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Need to make the following changes to the use case section on the website:
> # Add new section in the dropdown: Distributed Database
> ## add Distributed Transactional Database page
> ## add In-Memory Database page
> ## add Ignite vs NoSQL Databases
> ## add Ignite vs RDBMS Databases
> # Under In-Memory Caching Section
> ## add Ignite and In-Memory Data Grids page (explain persistence)
> ## fix Key-Value Store page to reflect native persistence
> ## fix JCache Provider page to reflect native persistence



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6041) Update Gettting Started documentation page

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-6041:
-

 Summary: Update Gettting Started documentation page
 Key: IGNITE-6041
 URL: https://issues.apache.org/jira/browse/IGNITE-6041
 Project: Ignite
  Issue Type: Task
  Components: website
Reporter: Dmitriy Setrakyan
Assignee: Denis Magda


Update Getting Started guide in documentation:
# show enable/disable persistence flag
# add SQL connectivity example (create, insert, select)
# put data grid example right after SQL
# add collocated computation example to the data grid example
# add service grid example



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6040) Update Distributed SQL Database page on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6040:
--
Description: 
# change DDL examples to pure SQL (without Java)
# change DML examples to pure SQL (without Java)
# change Query examples to pure SQL (without Java)
# add Java API section and show 1 Query, 1 DDL, 1 DML example from Java
# add .NET / C# API section and show 1 Query, 1 DDL, 1 DML example from C#
# add Other API section and show 1 Query, 1 DDL, 1 DML example from Python, 
PHP, etc.


  was:
# add Write-Ahead-Log (WAL) sub-section
# add Main Storage sub-section
# add Checkpointing sub-section
# add Redundancy sub-section (describe backups)
# add Durability sub-section (describe restarts)
# add Configuration example


> Update Distributed SQL Database page on the website
> ---
>
> Key: IGNITE-6040
> URL: https://issues.apache.org/jira/browse/IGNITE-6040
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> # change DDL examples to pure SQL (without Java)
> # change DML examples to pure SQL (without Java)
> # change Query examples to pure SQL (without Java)
> # add Java API section and show 1 Query, 1 DDL, 1 DML example from Java
> # add .NET / C# API section and show 1 Query, 1 DDL, 1 DML example from C#
> # add Other API section and show 1 Query, 1 DDL, 1 DML example from Python, 
> PHP, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6040) Update Distributed SQL Database page on the website

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-6040:
-

 Summary: Update Distributed SQL Database page on the website
 Key: IGNITE-6040
 URL: https://issues.apache.org/jira/browse/IGNITE-6040
 Project: Ignite
  Issue Type: Task
  Components: website
Reporter: Dmitriy Setrakyan
Assignee: Denis Magda


# add Write-Ahead-Log (WAL) sub-section
# add Main Storage sub-section
# add Checkpointing sub-section
# add Redundancy sub-section (describe backups)
# add Durability sub-section (describe restarts)
# add Configuration example



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6039) Update Persistence page on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6039:
--
Description: 
# add Write-Ahead-Log (WAL) sub-section
# add Main Storage sub-section
# add Checkpointing sub-section
# add Redundancy sub-section (describe backups)
# add Durability sub-section (describe restarts)
# add Configuration example

  was:
# Change the diagram to reflect native persistence
# add native persistence sub-section
# add native persistence feature


> Update Persistence page on the website
> --
>
> Key: IGNITE-6039
> URL: https://issues.apache.org/jira/browse/IGNITE-6039
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> # add Write-Ahead-Log (WAL) sub-section
> # add Main Storage sub-section
> # add Checkpointing sub-section
> # add Redundancy sub-section (describe backups)
> # add Durability sub-section (describe restarts)
> # add Configuration example



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6038) Update Data Grid page on the website to reflect Persistence

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6038:
--
Summary: Update Data Grid page on the website to reflect Persistence  (was: 
Update Data Grid page on teh website to reflect Persistence)

> Update Data Grid page on the website to reflect Persistence
> ---
>
> Key: IGNITE-6038
> URL: https://issues.apache.org/jira/browse/IGNITE-6038
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> # Change the diagram to reflect native persistence
> # add native persistence sub-section
> # add native persistence feature



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6039) Update Persistence page on the website

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-6039:
-

 Summary: Update Persistence page on the website
 Key: IGNITE-6039
 URL: https://issues.apache.org/jira/browse/IGNITE-6039
 Project: Ignite
  Issue Type: Task
  Components: website
Reporter: Dmitriy Setrakyan
Assignee: Denis Magda


# Change the diagram to reflect native persistence
# add native persistence sub-section
# add native persistence feature



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6037) Ignite 2.1 features changes on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6037:
--
Description: 
Make the following changes to Features:
# add What is Memory Centric
# change Persistence to either "Native Persistence" or "Persistent Store"
# change More to black font and rename to "More..."
# add Beta symbol to Machine Learning

  was:
Make the following changes to Features:
# add What is Memory Centric
# change More to black font and rename to "More..."
# add Beta symbol to Machine Learning


> Ignite 2.1 features changes on the website
> --
>
> Key: IGNITE-6037
> URL: https://issues.apache.org/jira/browse/IGNITE-6037
> Project: Ignite
>  Issue Type: Bug
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Make the following changes to Features:
> # add What is Memory Centric
> # change Persistence to either "Native Persistence" or "Persistent Store"
> # change More to black font and rename to "More..."
> # add Beta symbol to Machine Learning



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6038) Update Data Grid page on teh website to reflect Persistence

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6038:
--
Labels: site  (was: )

> Update Data Grid page on teh website to reflect Persistence
> ---
>
> Key: IGNITE-6038
> URL: https://issues.apache.org/jira/browse/IGNITE-6038
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> # Change the diagram to reflect native persistence
> # add native persistence sub-section
> # add native persistence feature



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6038) Update Data Grid page on teh website to reflect Persistence

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-6038:
-

 Summary: Update Data Grid page on teh website to reflect 
Persistence
 Key: IGNITE-6038
 URL: https://issues.apache.org/jira/browse/IGNITE-6038
 Project: Ignite
  Issue Type: Task
  Components: website
Reporter: Dmitriy Setrakyan
Assignee: Denis Magda


# Change the diagram to reflect native persistence
# add native persistence sub-section
# add native persistence feature



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6037) Ignite 2.1 features changes on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6037:
--
Description: 
Make the following changes to Features:
# add What is Memory Centric
# change More to black font and rename to "More..."
# add Beta symbol to Machine Learning

  was:
Make the following changes to Features->Overview:
# add What is Memory Centric
# add What is Durable Memory


> Ignite 2.1 features changes on the website
> --
>
> Key: IGNITE-6037
> URL: https://issues.apache.org/jira/browse/IGNITE-6037
> Project: Ignite
>  Issue Type: Bug
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Make the following changes to Features:
> # add What is Memory Centric
> # change More to black font and rename to "More..."
> # add Beta symbol to Machine Learning



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6037) Ignite 2.1 features changes on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6037:
--
Summary: Ignite 2.1 features changes on the website  (was: Ignite 2.1 
features overview changes on the website)

> Ignite 2.1 features changes on the website
> --
>
> Key: IGNITE-6037
> URL: https://issues.apache.org/jira/browse/IGNITE-6037
> Project: Ignite
>  Issue Type: Bug
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Make the following changes to Features->Overview:
> # add What is Memory Centric
> # add What is Durable Memory



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6037) Ignite 2.1 features overview changes on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6037:
--
Labels: site  (was: )

> Ignite 2.1 features overview changes on the website
> ---
>
> Key: IGNITE-6037
> URL: https://issues.apache.org/jira/browse/IGNITE-6037
> Project: Ignite
>  Issue Type: Bug
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Make the following changes to Features->Overview:
> # add What is Memory Centric
> # add What is Durable Memory



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6037) Ignite 2.1 features overview changes on the website

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-6037:
-

 Summary: Ignite 2.1 features overview changes on the website
 Key: IGNITE-6037
 URL: https://issues.apache.org/jira/browse/IGNITE-6037
 Project: Ignite
  Issue Type: Bug
  Components: website
Reporter: Dmitriy Setrakyan
Assignee: Denis Magda


Make the following changes to Features->Overview:
# add What is Memory Centric
# add What is Durable Memory



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6036:
--
Issue Type: Task  (was: Bug)

> Ignite 2.1 use case changes on the website
> --
>
> Key: IGNITE-6036
> URL: https://issues.apache.org/jira/browse/IGNITE-6036
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Need to make the following changes to the use case section on the website:
> # Add new section in the dropdown: Distributed Database
> ## add Distributed Transactional Database page
> ## add In-Memory Database page
> ## add Ignite vs NoSQL Databases
> ## add Ignite vs RDBMS Databases
> # Under In-Memory Caching Section
> ## add Ignite and traditional In-Memory Data Grids page (explain persistence)
> ## fix Key-Value Store page to reflect native persistence
> ## fix JCache Provider page to reflect native persistence



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan commented on IGNITE-6036:
---

don't forget to update the site map

> Ignite 2.1 use case changes on the website
> --
>
> Key: IGNITE-6036
> URL: https://issues.apache.org/jira/browse/IGNITE-6036
> Project: Ignite
>  Issue Type: Bug
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Need to make the following changes to the use case section on the website:
> # Add new section in the dropdown: Distributed Database
> ## add Distributed Transactional Database page
> ## add In-Memory Database page
> ## add Ignite vs NoSQL Databases
> ## add Ignite vs RDBMS Databases
> # Under In-Memory Caching Section
> ## add Ignite and traditional In-Memory Data Grids page (explain persistence)
> ## fix Key-Value Store page to reflect native persistence
> ## fix JCache Provider page to reflect native persistence



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6036:
--
Description: 
Need to make the following changes to the use case section on the website:
# Add new section in the dropdown: Distributed Database
## add Distributed Transactional Database page
## add In-Memory Database page
## add Ignite vs NoSQL Databases
## add Ignite vs RDBMS Databases
# Under In-Memory Caching Section
## add Ignite and traditional In-Memory Data Grids page (explain persistence)
## fix Key-Value Store page to reflect native persistence
## fix JCache Provider page to reflect native persistence


  was:
Need to make the following changes to the use case section on the website:
# Add new section in the dropdown: Distributed Database
## add Distributed Transactional Database page
## add In-Memory Database page
## add Ignite vs NoSQL Databases
## add Ignite vs RDBMS Databases
# Under In-Memory Caching Section
## add Ignite and traditional In-Memory DataGrids page (explain persistence)
## fix Key-Value Store page to reflect native persistence
## fix JCache Provider page to reflect native persistence



> Ignite 2.1 use case changes on the website
> --
>
> Key: IGNITE-6036
> URL: https://issues.apache.org/jira/browse/IGNITE-6036
> Project: Ignite
>  Issue Type: Bug
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Need to make the following changes to the use case section on the website:
> # Add new section in the dropdown: Distributed Database
> ## add Distributed Transactional Database page
> ## add In-Memory Database page
> ## add Ignite vs NoSQL Databases
> ## add Ignite vs RDBMS Databases
> # Under In-Memory Caching Section
> ## add Ignite and traditional In-Memory Data Grids page (explain persistence)
> ## fix Key-Value Store page to reflect native persistence
> ## fix JCache Provider page to reflect native persistence



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6036:
--
Labels: site  (was: )

> Ignite 2.1 use case changes on the website
> --
>
> Key: IGNITE-6036
> URL: https://issues.apache.org/jira/browse/IGNITE-6036
> Project: Ignite
>  Issue Type: Bug
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Need to make the following changes to the use case section on the website:
> # Add new section in the dropdown: Distributed Database
> ## add Distributed Transactional Database page
> ## add In-Memory Database page
> ## add Ignite vs NoSQL Databases
> ## add Ignite vs RDBMS Databases
> # Under In-Memory Caching Section
> ## add Ignite and traditional In-Memory DataGrids page (explain persistence)
> ## fix Key-Value Store page to reflect native persistence
> ## fix JCache Provider page to reflect native persistence



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-6036:
-

 Summary: Ignite 2.1 use case changes on the website
 Key: IGNITE-6036
 URL: https://issues.apache.org/jira/browse/IGNITE-6036
 Project: Ignite
  Issue Type: Bug
  Components: website
Reporter: Dmitriy Setrakyan
Assignee: Denis Magda


Need to make the following changes to the use case section on the website:
# Add new section in the dropdown: Distributed Database
## add Distributed Transactional Database page
## add In-Memory Database page
## add Ignite vs NoSQL Databases
## add Ignite vs RDBMS Databases
# Under In-Memory Caching Section
## add Ignite and traditional In-Memory DataGrids page (explain persistence)
## fix Key-Value Store page to reflect native persistence
## fix JCache Provider page to reflect native persistence




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6035) Indexes aren't cleaned on cache clear/destroy

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6035:
---
Labels: MakeTeamcityGreenAgain  (was: )

> Indexes aren't cleaned on cache clear/destroy
> -
>
> Key: IGNITE-6035
> URL: https://issues.apache.org/jira/browse/IGNITE-6035
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>  Labels: MakeTeamcityGreenAgain
>
> Curently on cache clear or destroy cache in a group, where other caches exist 
> (this operation executes cache clear internally) the query indexes (if 
> present) aren't cleaned/destroyed. 
> {{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#clear}} has to call 
> finishUpdate(...)
> This leads issues on next insertions or updates (on attempt to teplace an 
> alreadyu deleted item)
> {{org/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree.java:370}}:
> {noformat}Caused by: java.lang.AssertionError: itemId=0, directCnt=0, 
> page=000100010005 [][][free=970]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:437)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.readPayload(DataPageIO.java:488)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:149)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:101)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2RowFactory.getRow(H2RowFactory.java:62)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:124)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:36)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:123)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:40)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.getRow(BPlusTree.java:4372)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Replace.run0(BPlusTree.java:370)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Replace.run0(BPlusTree.java:330)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4697)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4682)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:342)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:261)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11200(BPlusTree.java:81)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryReplace(BPlusTree.java:2875)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2279)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2006)
>   ... 28 more{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6034) SQL: Optimize GridQueryNextPageResponse memory consumption

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6034:

Summary: SQL: Optimize GridQueryNextPageResponse memory consumption  (was: 
SQL: Optimize GridQueryNextPageResponse message consumption)

> SQL: Optimize GridQueryNextPageResponse memory consumption
> --
>
> Key: IGNITE-6034
> URL: https://issues.apache.org/jira/browse/IGNITE-6034
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.2
>
>
> Currently we store data in {{GridQueryNextPageResponse}} in message wrappers. 
> This can be avoided easily, if we add custom converter interface which could 
> be passed to our direct marshaller facility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6027) SQL: add "last" flag to GridQueryNextPageResponse

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6027:


Github user devozerov closed the pull request at:

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


> SQL: add "last" flag to GridQueryNextPageResponse
> -
>
> Key: IGNITE-6027
> URL: https://issues.apache.org/jira/browse/IGNITE-6027
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.2
>
>
> Sometimes it is impossible to get result set size in advance. Let's add 
> {{last}} flag to support it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6034) SQL: Optimize GridQueryNextPageResponse message consumption

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6034:


GitHub user devozerov opened a pull request:

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

IGNITE-6034



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

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

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

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


commit 50cfab7806275f8719a38276c549f38695b0e9f0
Author: devozerov 
Date:   2017-08-10T18:09:11Z

Writer part.

commit 6d820243389f64cc2324b048e75240271c93d291
Author: devozerov 
Date:   2017-08-10T18:18:21Z

Reader part.

commit 37b228b09983607a24c5db6f93cdefc38ed9081f
Author: devozerov 
Date:   2017-08-10T18:22:12Z

Minors.

commit 74890db63bfe20e472433391b3f1bd8f2e5699a5
Author: devozerov 
Date:   2017-08-10T18:23:38Z

Minors.

commit 6f1b888fa698dc948951a7a22e9c01650712af6a
Author: devozerov 
Date:   2017-08-10T18:28:08Z

Single interface.

commit 977ee1ac7224145f950a775a19b778c0721e6354
Author: devozerov 
Date:   2017-08-10T18:54:02Z

Wired things up. Now need to remove plain types.

commit df031907a1d5520d942258ce3ba86e6c31975114
Author: devozerov 
Date:   2017-08-10T19:09:00Z

WIP.

commit fe3bdc5db94c7daf6e7d6d4ef3c71df474a5880c
Author: devozerov 
Date:   2017-08-10T19:23:04Z

Removed GridKernalContext from "value" signature.

commit 91a0de707e49988c18ee04c924d3f6b29fcb4b22
Author: devozerov 
Date:   2017-08-10T19:25:40Z

Minors.

commit 5da2e2ae23d422693b8cdbfb272d1a6d9d644fe8
Author: devozerov 
Date:   2017-08-10T19:58:10Z

Done.

commit fe8241292ece4ba083faf5fbc1dca83562e6da41
Author: devozerov 
Date:   2017-08-10T20:02:45Z

Minors.




> SQL: Optimize GridQueryNextPageResponse message consumption
> ---
>
> Key: IGNITE-6034
> URL: https://issues.apache.org/jira/browse/IGNITE-6034
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.2
>
>
> Currently we store data in {{GridQueryNextPageResponse}} in message wrappers. 
> This can be avoided easily, if we add custom converter interface which could 
> be passed to our direct marshaller facility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6035) Indexes aren't cleaned on cache clear/destroy

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov updated IGNITE-6035:
-
Description: 
Curently on cache clear or destroy cache in a group, where other caches exist 
(this operation executes cache clear internally) the query indexes (if present) 
aren't cleaned/destroyed. 

{{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#clear}} has to call 
finishUpdate(...)


This leads issues on next insertions or updates (on attempt to teplace an 
alreadyu deleted item)

{{org/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree.java:370}}:

{noformat}Caused by: java.lang.AssertionError: itemId=0, directCnt=0, 
page=000100010005 [][][free=970]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:437)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.readPayload(DataPageIO.java:488)
at 
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:149)
at 
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:101)
at 
org.apache.ignite.internal.processors.query.h2.database.H2RowFactory.getRow(H2RowFactory.java:62)
at 
org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:124)
at 
org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:36)
at 
org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:123)
at 
org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:40)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.getRow(BPlusTree.java:4372)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Replace.run0(BPlusTree.java:370)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Replace.run0(BPlusTree.java:330)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4697)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4682)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:342)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:261)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11200(BPlusTree.java:81)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryReplace(BPlusTree.java:2875)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2279)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2006)
... 28 more{noformat}

> Indexes aren't cleaned on cache clear/destroy
> -
>
> Key: IGNITE-6035
> URL: https://issues.apache.org/jira/browse/IGNITE-6035
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>
> Curently on cache clear or destroy cache in a group, where other caches exist 
> (this operation executes cache clear internally) the query indexes (if 
> present) aren't cleaned/destroyed. 
> {{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#clear}} has to call 
> finishUpdate(...)
> This leads issues on next insertions or updates (on attempt to teplace an 
> alreadyu deleted item)
> {{org/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree.java:370}}:
> {noformat}Caused by: java.lang.AssertionError: itemId=0, directCnt=0, 
> page=000100010005 [][][free=970]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:437)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.readPayload(DataPageIO.java:488)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:149)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:101)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2RowFactory.getRow(H2RowFactory.java:62)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:124)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:36)
>   at 

[jira] [Updated] (IGNITE-6035) Indexes aren't cleaned on cache clear/destroy

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov updated IGNITE-6035:
-
Environment: (was: Curently on cache clear or destroy cache in a group, 
where other caches exist (this operation executes cache clear internally) the 
query indexes (if present) aren't cleaned/destroyed. 

{{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#clear}} has to call 
finishUpdate(...)


This leads issues on next insertions or updates (on attempt to teplace an 
alreadyu deleted item)

{{org/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree.java:370}}:

{noformat}Caused by: java.lang.AssertionError: itemId=0, directCnt=0, 
page=000100010005 [][][free=970]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:437)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.readPayload(DataPageIO.java:488)
at 
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:149)
at 
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:101)
at 
org.apache.ignite.internal.processors.query.h2.database.H2RowFactory.getRow(H2RowFactory.java:62)
at 
org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:124)
at 
org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:36)
at 
org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:123)
at 
org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:40)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.getRow(BPlusTree.java:4372)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Replace.run0(BPlusTree.java:370)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Replace.run0(BPlusTree.java:330)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4697)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4682)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:342)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:261)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11200(BPlusTree.java:81)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryReplace(BPlusTree.java:2875)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2279)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2006)
... 28 more{noformat})

> Indexes aren't cleaned on cache clear/destroy
> -
>
> Key: IGNITE-6035
> URL: https://issues.apache.org/jira/browse/IGNITE-6035
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6035) Indexes aren't cleaned on cache clear/destroy

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-6035:


 Summary: Indexes aren't cleaned on cache clear/destroy
 Key: IGNITE-6035
 URL: https://issues.apache.org/jira/browse/IGNITE-6035
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.1
 Environment: Curently on cache clear or destroy cache in a group, 
where other caches exist (this operation executes cache clear internally) the 
query indexes (if present) aren't cleaned/destroyed. 

{{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#clear}} has to call 
finishUpdate(...)


This leads issues on next insertions or updates (on attempt to teplace an 
alreadyu deleted item)

{{org/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree.java:370}}:

{noformat}Caused by: java.lang.AssertionError: itemId=0, directCnt=0, 
page=000100010005 [][][free=970]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:437)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.readPayload(DataPageIO.java:488)
at 
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:149)
at 
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:101)
at 
org.apache.ignite.internal.processors.query.h2.database.H2RowFactory.getRow(H2RowFactory.java:62)
at 
org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:124)
at 
org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:36)
at 
org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:123)
at 
org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:40)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.getRow(BPlusTree.java:4372)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Replace.run0(BPlusTree.java:370)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Replace.run0(BPlusTree.java:330)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4697)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4682)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:342)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:261)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11200(BPlusTree.java:81)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryReplace(BPlusTree.java:2875)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2279)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2006)
... 28 more{noformat}
Reporter: Igor Seliverstov






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6013) Web agent: refactor processing response from cluster

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6013:


Assignee: Andrey Novikov  (was: Alexey Kuznetsov)

[~anovikov]  please review again, I refactored code to use JsonDeserialize.

> Web agent: refactor processing response from cluster
> 
>
> Key: IGNITE-6013
> URL: https://issues.apache.org/jira/browse/IGNITE-6013
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> RestExecutor.sendRequest() contain following code:
> {code}
> 
> try (Response resp = 
> httpClient.newCall(reqBuilder.build()).execute()) {
> String content = resp.body().string();
> if (resp.isSuccessful()) {
> JsonNode node = mapper.readTree(content);
>  
> {code}
> Problems: 
> # String content = resp.body().string(); >> Generate not needed String.
> # JsonNode node = mapper.readTree(content);  >> Generates a big tree of 
> JsonNodes
>  
> Could be fixed like:
> RestResponseHolder res = MAPPER.readValue(resp.body().byteStream(), 
> RestResponseHolder.class); 
> Where for RestResponseHolder should also created optimized 
> RestResponseHolderDeserializer that will extract response as String without 
> building tree of JsonNodes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6032) ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6032:


GitHub user isapego opened a pull request:

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

IGNITE-6032 ODBC: Added SQL_SCROLL_OPTIONS support for SQLGetInfo



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

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

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

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


commit 9da17772026ff1fcbda98cad0c4fb808cb8c901d
Author: Igor Sapego 
Date:   2017-08-10T17:41:14Z

IGNITE-6032: Test added

commit 3f8dbf6ab4e1eafbb888531362d47788dfdf5a95
Author: Igor Sapego 
Date:   2017-08-10T17:42:11Z

IGNITE-6032: Fix




> ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
> 
>
> Key: IGNITE-6032
> URL: https://issues.apache.org/jira/browse/IGNITE-6032
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently {{SQLGetInfo}} does not support {{SQL_SCROLL_OPTIONS}}. Need to add 
> support.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6034) SQL: Optimize GridQueryNextPageResponse message consumption

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6034:

Labels: performance  (was: persistence)

> SQL: Optimize GridQueryNextPageResponse message consumption
> ---
>
> Key: IGNITE-6034
> URL: https://issues.apache.org/jira/browse/IGNITE-6034
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.2
>
>
> Currently we store data in {{GridQueryNextPageResponse}} in message wrappers. 
> This can be avoided easily, if we add custom converter interface which could 
> be passed to our direct marshaller facility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6019) SQL: client node should not hold the whole data set in-memory when possible

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6019:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-6019



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

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

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

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


commit 12a479fe7d1973bdba5dcdb488d3ff109667d107
Author: Alexander Paschenko 
Date:   2017-08-10T12:48:38Z

IGNITE-6019 Merge indexes iterator

commit 51a62134345731c5464c854c62e8be59fb79a9fd
Author: Alexander Paschenko 
Date:   2017-08-10T14:06:08Z

Minors.

commit 652713cba2498cfa85ad89bf9f0aaf96784cae76
Author: Alexander Paschenko 
Date:   2017-08-10T14:19:08Z

Minors.

commit 76c9e2ad6d2e7d0ab4e73b85fa6c2cda9fb913b3
Author: Alexander Paschenko 
Date:   2017-08-10T17:31:59Z

Added a test.




> SQL: client node should not hold the whole data set in-memory when possible
> ---
>
> Key: IGNITE-6019
> URL: https://issues.apache.org/jira/browse/IGNITE-6019
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Critical
>  Labels: performance
> Fix For: 2.2
>
>
> Our SQL engine requests request data from server nodes in pieces called 
> "page". This allows us to control memory consumption on client side. However, 
> currently our client code is designed in a way that all pages are requested 
> from all servers before a single cursor row is returned to the user. It 
> defeats the whole idea of "cursor" and "page", and could easily crash client 
> node with OOME. 
> We need to fix that and request further pages in a kind of sliding window, 
> keeping no more than "N" pages in memory simultaneously. Note that sometimes 
> it is not possible, e.g. in case of {{DISTINCT}} or non-collocated {{GROUP 
> BY}}. In this case we would have to build the whole result set first anyway. 
> So let's focus on a scenario when the whole result set is not needed.
> As currently everything is requested synchronously page-by-page, in the first 
> version it would be enough to distribute synchronous page requests between 
> cursor reads, without any prefetch. 
> Implementation details:
> 1) Optimization should be applied only to {{skipMergeTbl=true}} cases, when 
> complete result set of map queries is not needed.
> 2) Starting point is {{GridReduceQueryExecutor#query}}, see 
> {{skipMergeTbl=true}} branch - this is where we get all pages eagerly.
> 3) Get no more than one page from the server at a time. We request the page, 
> iterate over it, then request another page.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5736) Add test of backward-compatibility

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-5736:


[~vozerov], could you please review the test and compatibility module?

> Add test of backward-compatibility
> --
>
> Key: IGNITE-5736
> URL: https://issues.apache.org/jira/browse/IGNITE-5736
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> Need to add unit-test to test compatibility with AI 2.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6034) SQL: Optimize GridQueryNextPageResponse message consumption

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6034:

Labels: persistence  (was: )

> SQL: Optimize GridQueryNextPageResponse message consumption
> ---
>
> Key: IGNITE-6034
> URL: https://issues.apache.org/jira/browse/IGNITE-6034
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: persistence
> Fix For: 2.2
>
>
> Currently we store data in {{GridQueryNextPageResponse}} in message wrappers. 
> This can be avoided easily, if we add custom converter interface which could 
> be passed to our direct marshaller facility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6034) SQL: Optimize GridQueryNextPageResponse message consumption

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6034:
---

 Summary: SQL: Optimize GridQueryNextPageResponse message 
consumption
 Key: IGNITE-6034
 URL: https://issues.apache.org/jira/browse/IGNITE-6034
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.2


Currently we store data in {{GridQueryNextPageResponse}} in message wrappers. 
This can be avoided easily, if we add custom converter interface which could be 
passed to our direct marshaller facility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6032) ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6032:

Description: Currently {{SQLGetInfo}} does not support 
{{SQL_SCROLL_OPTIONS}}. Need to add support.  (was: Currently {{SQLGetInfo}} 
does not support {{SQLGetInfo}}.)

> ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
> 
>
> Key: IGNITE-6032
> URL: https://issues.apache.org/jira/browse/IGNITE-6032
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently {{SQLGetInfo}} does not support {{SQL_SCROLL_OPTIONS}}. Need to add 
> support.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6032) ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6032:

Description: Currently {{SQLGetInfo}} does not support {{SQLGetInfo}}.  
(was: Currently {{SQLGetInfo}} returns {{SLQ_NO_DATA}} if called on NULL data. 
According to specification, it should return {{SQL_SUCCESS}} in this case.)

> ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
> 
>
> Key: IGNITE-6032
> URL: https://issues.apache.org/jira/browse/IGNITE-6032
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently {{SQLGetInfo}} does not support {{SQLGetInfo}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6032) ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6032:

Summary: ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo  (was: 
ODBC: SQLGetData should return SQL_SUCCESS if called on NULL column)

> ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
> 
>
> Key: IGNITE-6032
> URL: https://issues.apache.org/jira/browse/IGNITE-6032
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently {{SQLGetData}} returns {{SLQ_NO_DATA}} if called on NULL data. 
> According to specification, it should return {{SQL_SUCCESS}} in this case.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6032) ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6032:

Description: Currently {{SQLGetInfo}} returns {{SLQ_NO_DATA}} if called on 
NULL data. According to specification, it should return {{SQL_SUCCESS}} in this 
case.  (was: Currently {{SQLGetData}} returns {{SLQ_NO_DATA}} if called on NULL 
data. According to specification, it should return {{SQL_SUCCESS}} in this 
case.)

> ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
> 
>
> Key: IGNITE-6032
> URL: https://issues.apache.org/jira/browse/IGNITE-6032
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently {{SQLGetInfo}} returns {{SLQ_NO_DATA}} if called on NULL data. 
> According to specification, it should return {{SQL_SUCCESS}} in this case.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6029) Refactor WAL Record serialization and introduce RecordV2Serializer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6029:


GitHub user Jokser opened a pull request:

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

IGNITE-6029 WAL Record serialization refactoring

And initial stuff for Record V2 serializer.

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

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

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

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


commit 605198854104e04f343630e2fcec8fe78103be3e
Author: Pavel Kovalenko 
Date:   2017-08-10T17:18:59Z

IGNITE-6029 Record serializer refactoring and initial stuff for Record V2 
serialization.




> Refactor WAL Record serialization and introduce RecordV2Serializer
> --
>
> Key: IGNITE-6029
> URL: https://issues.apache.org/jira/browse/IGNITE-6029
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
> Fix For: 2.2
>
>
> Currently RecordSerializer interface and default RecordV1Serializer 
> implementation are not well extendable. We should refactor RecordSerializer 
> interface and introduce new RecordV2Serializer with very base functionality - 
> delegate everything to RecordV1Serializer.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6024) SQL: execute DML statements on the server when possible

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov reassigned IGNITE-6024:
--

Assignee: Sergey Kalashnikov

> SQL: execute DML statements on the server when possible
> ---
>
> Key: IGNITE-6024
> URL: https://issues.apache.org/jira/browse/IGNITE-6024
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: performance
> Fix For: 2.2
>
>
> Currently we execute DML statements as follows:
> 1) Get query result set to the client
> 2) Construct entry processors and send them to servers in batches
> This approach is inefficient as it causes a lot of unnecessary network 
> communication  Instead, we should execute DML statements directly on server 
> nodes when it is possible.
> Implementation considerations:
> 1) Determine set of queries which could be processed in this way. E.g., 
> {{LIMIT/OFFSET}}, {{GROUP BY}}, {{ORDER BY}}, {{DISTINCT}}, etc. are out of 
> question - they must go through the client anyway. Probably 
> {{skipMergeTable}} flag is a good starting point (good, not precise!)
> 2) Send request to every server and execute local DML right there
> 3) No failover support at the moment - throw "partial update" exception if 
> topology is unstable
> 4) Handle partition reservation carefully
> 5) Transactions: we still have single coordinator - this is a client. When 
> MVCC and TX SQL is ready, client will assign proper counters to server 
> requests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5382) SQL: frequent switch between schemas cause severe slowdown

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-5382:


[~vozerov], as we discussed, I've updated the patch with implementation of 
individual statements cleanup with simple synchronization to prevent closing 
PreparedStatement that are in use.
Please take a look.

> SQL: frequent switch between schemas cause severe slowdown
> --
>
> Key: IGNITE-5382
> URL: https://issues.apache.org/jira/browse/IGNITE-5382
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: important, performance
> Fix For: 2.2
>
>
> We have thread-bound cached connection to H2 database which is bound to 
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command, 
> which is rather expensive and may cause slowdown when queries form different 
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be 
> careful with concurrency and resource leaks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-4991) Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is set

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4991:
--

Looks good for me.

> Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is 
> set
> -
>
> Key: IGNITE-4991
> URL: https://issues.apache.org/jira/browse/IGNITE-4991
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>  Labels: newbie
> Fix For: 2.2
>
>
> {{IgniteKernal#ackSystemProperties}} and {{IgniteKernal#ackVmArguments}} 
> print out system properties that can contain sensitive data. This print outs 
> should be disabled when {{IGNITE_TO_STRING_INCLUDE_SENSITIVE}} system 
> property is set to {{true}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-4991) Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is set

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4991:


GitHub user ezhuravl opened a pull request:

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

IGNITE-4991 Do not print out system properties when IGNITE_TO_STRING_…

…INCLUDE_SENSITIVE is set to false

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

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

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

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


commit 4f90b6fd77bd23fa818620f0757b792ba388ef93
Author: Evgenii Zhuravlev 
Date:   2017-08-10T15:54:57Z

IGNITE-4991 Do not print out system properties when 
IGNITE_TO_STRING_INCLUDE_SENSITIVE is set to false




> Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is 
> set
> -
>
> Key: IGNITE-4991
> URL: https://issues.apache.org/jira/browse/IGNITE-4991
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>  Labels: newbie
> Fix For: 2.2
>
>
> {{IgniteKernal#ackSystemProperties}} and {{IgniteKernal#ackVmArguments}} 
> print out system properties that can contain sensitive data. This print outs 
> should be disabled when {{IGNITE_TO_STRING_INCLUDE_SENSITIVE}} system 
> property is set to {{true}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6033) Add sorted and multithreaded modes in checkpoint algorithm

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-6033:
--

 Summary: Add sorted and multithreaded modes in checkpoint algorithm
 Key: IGNITE-6033
 URL: https://issues.apache.org/jira/browse/IGNITE-6033
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Affects Versions: 2.1
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.2


Sequential writes to SSD are faster than random. When we write checkpoint, we 
iterate through hash table, which is actually random order. We should add an 
option to write pages sorted by page index. It should be configured in 
PersistentStoreConfiguration.
Also, we already have PersistentStoreConfiguration#checkpointingThreads option, 
but we don't use it - we create thread pool, but submit only one task to it. 
This should be fixed as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6030) Allow enabling persistence per-cache

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6030:
--
Description: Also, when cache native persistence is disabled, we need to 
make sure that different {{CacheStores}} can be configured on per-cache basis.

> Allow enabling persistence per-cache
> 
>
> Key: IGNITE-6030
> URL: https://issues.apache.org/jira/browse/IGNITE-6030
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
> Fix For: 2.2
>
>
> Also, when cache native persistence is disabled, we need to make sure that 
> different {{CacheStores}} can be configured on per-cache basis.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6032) ODBC: SQLGetData should return SQL_SUCCESS if called on NULL column

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-6032:
---

 Summary: ODBC: SQLGetData should return SQL_SUCCESS if called on 
NULL column
 Key: IGNITE-6032
 URL: https://issues.apache.org/jira/browse/IGNITE-6032
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.1
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.2


Currently {{SQLGetData}} returns {{SLQ_NO_DATA}} if called on NULL data. 
According to specification, it should return {{SQL_SUCCESS}} in this case.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5233) JDBC thin Driver: implement metadata support

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-5233 at 8/10/17 3:25 PM:
---

Comments are fixed except:
10. & 23. For {{getFunctions}} methods the separate ticket is filed: 
IGNITE-6028.
17. Ignite and H2 don't support user-defined SQL types.
22. There is the ticket for the Client Info: IGNITE-5425.

[Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2079%2Fhead]
 are OK.

Also, I propose to add full API tests for metadata with the ticket: IGNITE-5339.

[~vozerov], please take a look.


was (Author: tledkov-gridgain):
Comments are fixed except:
10. & 23. For {{getFunctions}} methods the separate ticket is filed: 
IGNITE-6028.
17. Ignite and H2 don't support user-defined SQL types.
22. There is the ticket for the Client Info: IGNITE-5425.

[Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2079%2Fhead]
 are OK.

Also, I propose to add full API tests for metadata with the ticket: IGNITE-5339.

> JDBC thin Driver: implement metadata support 
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5233) JDBC thin Driver: implement metadata support

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-5233 at 8/10/17 3:25 PM:
---

Comments are fixed except:
10. & 23. For {{getFunctions}} methods the separate ticket is filed: 
IGNITE-6028.
17. Ignite and H2 don't support user-defined SQL types.
22. There is the ticket for the Client Info: IGNITE-5425.

[Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2079%2Fhead]
 are OK.

Also, I propose to add full API tests for metadata with the ticket: IGNITE-5339.


was (Author: tledkov-gridgain):
Comments are fixed except:
10. & 23. For {{getFunctions}} methods the separate ticket is filed: 
IGNITE-6028.
17. Ignite and H2 don't support user-defined SQL types.
22. There is the ticket for the Client Info: IGNITE-5425.

[Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2079%2Fhead]
 are OK.

> JDBC thin Driver: implement metadata support 
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5233) JDBC thin Driver: implement metadata support

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-5233:
--

Comments are fixed except:
10. & 23. For {{getFunctions}} methods the separate ticket is filed: 
IGNITE-6028.
17. Ignite and H2 don't support user-defined SQL types.
22. There is the ticket for the Client Info: IGNITE-5425.

[Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2079%2Fhead]
 are OK.

> JDBC thin Driver: implement metadata support 
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-3084) Spark Data Frames Support in Apache Ignite

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov reassigned IGNITE-3084:
---

Assignee: Nikolay Izhikov  (was: Valentin Kulichenko)

> Spark Data Frames Support in Apache Ignite
> --
>
> Key: IGNITE-3084
> URL: https://issues.apache.org/jira/browse/IGNITE-3084
> Project: Ignite
>  Issue Type: Task
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>  Labels: bigdata
> Fix For: 2.2
>
>
> Apache Spark already benefits from integration with Apache Ignite. The latter 
> provides shared RDDs, an implementation of Spark RDD, that help Spark to 
> share a state between Spark workers and execute SQL queries much faster. The 
> next logical step is to enable support for modern Spark Data Frames API in a 
> similar way.
> As a contributor, you will be fully in charge of the integration of Spark 
> Data Frame API and Apache Ignite.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6031) Web Console: Improve grouping of fields on Cluster Configuration Tab (By importance / alphabetically)

[Vica Abramova (JIRA)]

Vica Abramova created IGNITE-6031:
-

 Summary: Web Console: Improve grouping of fields on Cluster 
Configuration Tab (By importance / alphabetically)
 Key: IGNITE-6031
 URL: https://issues.apache.org/jira/browse/IGNITE-6031
 Project: Ignite
  Issue Type: Improvement
  Components: UI, wizards
Reporter: Vica Abramova






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5843) Ignite PDS: We don't save cache configuration if we get it on join

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-5843:
--

Looks good.

> Ignite PDS: We don't save cache configuration if we get it on join
> --
>
> Key: IGNITE-5843
> URL: https://issues.apache.org/jira/browse/IGNITE-5843
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.2
>
>
> We don't save cache configuration when we get it on join (new node joins 
> cluster with cache which is not presented on config or on disk).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6027) SQL: add "last" flag to GridQueryNextPageResponse

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6027:


GitHub user devozerov opened a pull request:

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

IGNITE-6027



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

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

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

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


commit f7afc0dc7ae3954aaf55d5ef1fa6e28afc974011
Author: devozerov 
Date:   2017-08-10T13:23:08Z

Added last page to the response.

commit d465d11ce0efbe35a58e3e78e2cb5895b9b80444
Author: devozerov 
Date:   2017-08-10T14:04:08Z

Done.

commit d1fdb746c9be80072a50c3de5534215e7ad53983
Author: devozerov 
Date:   2017-08-10T14:13:11Z

Done.

commit 00ccadb0c8c157e1c03a0d57c4751b4d85ff322c
Author: devozerov 
Date:   2017-08-10T14:14:25Z

Minors.




> SQL: add "last" flag to GridQueryNextPageResponse
> -
>
> Key: IGNITE-6027
> URL: https://issues.apache.org/jira/browse/IGNITE-6027
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.2
>
>
> Sometimes it is impossible to get result set size in advance. Let's add 
> {{last}} flag to support it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5884) Change default pageSize of page memory to 4KB

[Ivan Rakov (JIRA)]

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

Ivan Rakov reassigned IGNITE-5884:
--

Assignee: Ivan Rakov

> Change default pageSize of page memory to 4KB
> -
>
> Key: IGNITE-5884
> URL: https://issues.apache.org/jira/browse/IGNITE-5884
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.2
>
> Attachments: CpBenchmark.java, iostat.log, ssdlab.log
>
>
> Checkpoint write speed is suboptimal with default 2K page on most UNIX-driven 
> enviroments with SSD disk. There are several reasons for this:
> 1) Page size of linux page cache is 4k by default on most kernels (you can 
> check yours by "getconf PAGE_SIZE" command). With 2k random writes 
> vm.dirty_ratio threshold is reached two times faster than with 4k random 
> writes.
> 2) Most SSD manufacturers don't reveal actual disk page size, but they 
> recommend to write at least 4k at once. Also, 4k blocks are used during 
> benchmarking SSD random writes. 
> Related question: 
> https://superuser.com/questions/1168014/nvme-ssd-why-is-4k-writing-faster-than-reading
> Article by Emmanuel Goossaert describing why writing less than a page is 
> сounterproductive: 
> http://codecapsule.com/2014/02/12/coding-for-ssds-part-3-pages-blocks-and-the-flash-translation-layer/
> I've prepared a checkpoint emulation benchmark (code and results attached). 
> Run on production-level hardware (CentOS, 100 GB RAM, total LFS size is 
> 100GB, vm.dirty_ratio=10) showed that checkpointing with 4k pages is much 
> more efficient than with 2k.
> *Important: backwards compatibility must be ensured with LFS files created 
> with old 2k default page size.*



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5943) Communication. Server node may reject client connection during massive clients join

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev edited comment on IGNITE-5943 at 8/10/17 2:08 PM:


PR - https://github.com/apache/ignite/pull/2423
Test Run - 
https://ci.ignite.apache.org/viewQueued.html?itemId=764991=queuedBuildOverviewTab


was (Author: edshanggg):
PR - https://github.com/apache/ignite/pull/2423
Test Run - 
https://ci.ignite.apache.org/viewQueued.html?itemId=764905=queuedBuildOverviewTab

> Communication. Server node may reject client connection during massive 
> clients join
> ---
>
> Key: IGNITE-5943
> URL: https://issues.apache.org/jira/browse/IGNITE-5943
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Eduard Shangareev
>Assignee: Yakov Zhdanov
>Priority: Critical
> Fix For: 2.2
>
>
> There is a race between a client join discovery event on server nodes and the 
> moment when a client starts to establish outgoing communication connections. 
> It would cause to rejecting communication connections on server nodes (for 
> example. on requesting data from caches).
> The issue happens on really big topologies (> 300 nodes) or when many clients 
> join simultaneously.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6030) Allow enabling persistence per-cache

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-6030:


 Summary: Allow enabling persistence per-cache
 Key: IGNITE-6030
 URL: https://issues.apache.org/jira/browse/IGNITE-6030
 Project: Ignite
  Issue Type: New Feature
  Components: persistence
Affects Versions: 2.1
Reporter: Alexey Goncharuk
 Fix For: 2.2






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5943) Communication. Server node may reject client connection during massive clients join

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev reassigned IGNITE-5943:
-

Assignee: Yakov Zhdanov  (was: Eduard Shangareev)

> Communication. Server node may reject client connection during massive 
> clients join
> ---
>
> Key: IGNITE-5943
> URL: https://issues.apache.org/jira/browse/IGNITE-5943
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Eduard Shangareev
>Assignee: Yakov Zhdanov
>Priority: Critical
> Fix For: 2.2
>
>
> There is a race between a client join discovery event on server nodes and the 
> moment when a client starts to establish outgoing communication connections. 
> It would cause to rejecting communication connections on server nodes (for 
> example. on requesting data from caches).
> The issue happens on really big topologies (> 300 nodes) or when many clients 
> join simultaneously.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6029) Refactor WAL Record serialization and introduce RecordV2Serializer

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-6029:
---

 Summary: Refactor WAL Record serialization and introduce 
RecordV2Serializer
 Key: IGNITE-6029
 URL: https://issues.apache.org/jira/browse/IGNITE-6029
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.1
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.2


Currently RecordSerializer interface and default RecordV1Serializer 
implementation are not well extendable. We should refactor RecordSerializer 
interface and introduce new RecordV2Serializer with very base functionality - 
delegate everything to RecordV1Serializer.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6028) JDBC thin Driver: support metadata getFunctions methods

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-6028:


 Summary: JDBC thin Driver: support metadata getFunctions methods
 Key: IGNITE-6028
 URL: https://issues.apache.org/jira/browse/IGNITE-6028
 Project: Ignite
  Issue Type: Task
  Components: jdbc
Affects Versions: 2.1
Reporter: Taras Ledkov
Priority: Minor
 Fix For: 2.2


The methods of the {{JdbcThinDatabaseMetadata}} must be supported:
{{getFunctions}}
{{getFunctionColumns}}
{{getNumericFunctions}}
{{getStringFunctions}}
{{getSystemFunctions}}
{{getTimeDateFunctions}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6027) SQL: add "last" flag to GridQueryNextPageResponse

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6027:
---

 Summary: SQL: add "last" flag to GridQueryNextPageResponse
 Key: IGNITE-6027
 URL: https://issues.apache.org/jira/browse/IGNITE-6027
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.2


Sometimes it is impossible to get result set size in advance. Let's add 
{{last}} flag to support it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6018) Introduce WAL backward compatibility for new DataPage insert/update records

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-6018:

Priority: Major  (was: Blocker)

> Introduce WAL backward compatibility for new DataPage insert/update records
> ---
>
> Key: IGNITE-6018
> URL: https://issues.apache.org/jira/browse/IGNITE-6018
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
> Fix For: 2.2
>
>
> Once we store reference to DataRecord for DataPage insert/update records we 
> should be able to read/write both versions of that records (with reference or 
> with payload) for backward compatibility purposes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6026) init cluster for Ignite Persistence by xml

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin commented on IGNITE-6026:
--

Hi Alex,

The main idea from the API perspective is that Ignite Persistence is 
transparent for the API. After you enable persistence all your APIs including 
get/put, SQL, etc would work as before. 

Enable Persistence with 1 line:




And then activate cluster explicitly - 
With script:
${IGNITE_HOME}/bin/control.sh --activate

OR in the code:
ignite.active(true);


Best regards, 
Alexey


> init cluster for Ignite Persistence by xml 
> ---
>
> Key: IGNITE-6026
> URL: https://issues.apache.org/jira/browse/IGNITE-6026
> Project: Ignite
>  Issue Type: Wish
>  Components: cache, examples, persistence
>Affects Versions: 2.1
> Environment: ignite in docker with zk
>Reporter: Alex Negashev
>  Labels: documentation
>
> Hello! We use Ignite 2.1 and would like to use Ignite Persistence, how i can 
> do this without java code? xml only.
> Example attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6026) init cluster for Ignite Persistence by xml

[Alex Negashev (JIRA)]

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

Alex Negashev updated IGNITE-6026:
--
Description: 
Hello! We use Ignite 2.1 and would like to use Ignite Persistence, how i can do 
this without java code? xml only.
Example attached.

  was:
Hello! We use Ignite 2.1 and would like to use Ignite Persistence, how i can do 
this with out java code? xml only.
Example attached.


> init cluster for Ignite Persistence by xml 
> ---
>
> Key: IGNITE-6026
> URL: https://issues.apache.org/jira/browse/IGNITE-6026
> Project: Ignite
>  Issue Type: Wish
>  Components: cache, examples, persistence
>Affects Versions: 2.1
> Environment: ignite in docker with zk
>Reporter: Alex Negashev
>  Labels: documentation
>
> Hello! We use Ignite 2.1 and would like to use Ignite Persistence, how i can 
> do this without java code? xml only.
> Example attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6026) init cluster for Ignite Persistence by xml

[Alex Negashev (JIRA)]

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

Alex Negashev updated IGNITE-6026:
--
Summary: init cluster for Ignite Persistence by xml   (was: init cluster 
for Ignite  Ignite Persistence by xml )

> init cluster for Ignite Persistence by xml 
> ---
>
> Key: IGNITE-6026
> URL: https://issues.apache.org/jira/browse/IGNITE-6026
> Project: Ignite
>  Issue Type: Wish
>  Components: cache, examples, persistence
>Affects Versions: 2.1
> Environment: ignite in docker with zk
>Reporter: Alex Negashev
>  Labels: documentation
>
> Hello! We use Ignite 2.1 and would like to use Ignite Persistence, how i can 
> do this with out java code? xml only.
> Example attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5963) Ignite Cache 6: Flaky failure IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-5963:
--

Thanks, Nikolay, I merged your changes to master.

>  Ignite Cache 6: Flaky failure 
> IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC
> --
>
> Key: IGNITE-5963
> URL: https://issues.apache.org/jira/browse/IGNITE-5963
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Test sometimes fails on teamcity, please see
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-6026696383836355176=testDetails
> {noformat}
> java.lang.AssertionError: Exception has not been thrown.
> at 
> org.apache.ignite.testframework.GridTestUtils.assertThrowsWithCause(GridTestUtils.java:425)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:464)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:455)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:697)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:669)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnSuspend(IgniteOptimisticTxSuspendResumeTest.java:455)
> {noformat}
> Test was created under issue IGNITE-5712
> Does not reprocuced locally (30 runs on Win10).
> But on CI server success rate is 94%



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5963) Ignite Cache 6: Flaky failure IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5963:


Github user asfgit closed the pull request at:

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


>  Ignite Cache 6: Flaky failure 
> IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC
> --
>
> Key: IGNITE-5963
> URL: https://issues.apache.org/jira/browse/IGNITE-5963
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Test sometimes fails on teamcity, please see
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-6026696383836355176=testDetails
> {noformat}
> java.lang.AssertionError: Exception has not been thrown.
> at 
> org.apache.ignite.testframework.GridTestUtils.assertThrowsWithCause(GridTestUtils.java:425)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:464)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:455)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:697)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:669)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnSuspend(IgniteOptimisticTxSuspendResumeTest.java:455)
> {noformat}
> Test was created under issue IGNITE-5712
> Does not reprocuced locally (30 runs on Win10).
> But on CI server success rate is 94%



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6026) init cluster for Ignite Ignite Persistence by xml

[Alex Negashev (JIRA)]

Alex Negashev created IGNITE-6026:
-

 Summary: init cluster for Ignite  Ignite Persistence by xml 
 Key: IGNITE-6026
 URL: https://issues.apache.org/jira/browse/IGNITE-6026
 Project: Ignite
  Issue Type: Wish
  Components: cache, examples, persistence
Affects Versions: 2.1
 Environment: ignite in docker with zk
Reporter: Alex Negashev


Hello! We use Ignite 2.1 and would like to use Ignite Persistence, how i can do 
this with out java code? xml only.
Example attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5995) ODBC: SQLGetData gets data for the next row instead of current

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5995:


Github user isapego closed the pull request at:

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


> ODBC: SQLGetData gets data for the next row instead of current
> --
>
> Key: IGNITE-5995
> URL: https://issues.apache.org/jira/browse/IGNITE-5995
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> {{SQLGetData}} when called after {{SQLFetch}} should retrieve data from the 
> same row as {{SQLFetch}}. But currently, {{SQLGetData}} retrieves data from 
> the next row.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5991) SQL: lazy ResultSet for map query

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5991:
-

After consulting with H2 maintainers [1], the following solution was found: 
1) Add {{lazy}} hint to API
2) Apply it only to cases when there is only one map query
3) Set lazy execution flag on mapper on per-query basis through 
{{Session.setLazyQueryExecution}}
4) Create new thread pool - query engine obtains locks which must be released 
in the same thread
5) Handle {{GridQueryNextPageResponse.allRows == -1}} properly on client's 
side, currently it leads to extra {{GridQueryNextPageRequest}}

[1] https://github.com/h2database/h2database/issues/588

> SQL: lazy ResultSet for map query
> -
>
> Key: IGNITE-5991
> URL: https://issues.apache.org/jira/browse/IGNITE-5991
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.2
>
>
> Currently we move the whole {{ResultSet}} to memory when executing SQL query 
> on mapper. If result set is large enough, this could easily bring server down 
> due to high GC pressure or even OOME. 
> To avoid that we should stream H2's {{ResultSet}} to our own consumer, which 
> will construct a page and send it to the client  When a page is sent, 
> consumer will block current thread until "next page request" is received. 
> This approach has disadvantage - query thread will be blocked. However, 
> implementation should be fairly easy and will allow us to avoid OOMEs on 
> server. In future we will improve it to minimize blocking (or even avoid it 
> completely).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5991) SQL: lazy ResultSet for map query

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5991:

Summary: SQL: lazy ResultSet for map query  (was: SQL: create prototype for 
map query execution without moving full ResultSet to memory)

> SQL: lazy ResultSet for map query
> -
>
> Key: IGNITE-5991
> URL: https://issues.apache.org/jira/browse/IGNITE-5991
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.2
>
>
> Currently we move the whole {{ResultSet}} to memory when executing SQL query 
> on mapper. If result set is large enough, this could easily bring server down 
> due to high GC pressure or even OOME. 
> To avoid that we should stream H2's {{ResultSet}} to our own consumer, which 
> will construct a page and send it to the client  When a page is sent, 
> consumer will block current thread until "next page request" is received. 
> This approach has disadvantage - query thread will be blocked. However, 
> implementation should be fairly easy and will allow us to avoid OOMEs on 
> server. In future we will improve it to minimize blocking (or even avoid it 
> completely).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6013) Web agent: refactor processing response from cluster

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-6013:
--

Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Web agent: refactor processing response from cluster
> 
>
> Key: IGNITE-6013
> URL: https://issues.apache.org/jira/browse/IGNITE-6013
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>
> RestExecutor.sendRequest() contain following code:
> {code}
> 
> try (Response resp = 
> httpClient.newCall(reqBuilder.build()).execute()) {
> String content = resp.body().string();
> if (resp.isSuccessful()) {
> JsonNode node = mapper.readTree(content);
>  
> {code}
> Problems: 
> # String content = resp.body().string(); >> Generate not needed String.
> # JsonNode node = mapper.readTree(content);  >> Generates a big tree of 
> JsonNodes
>  
> Could be fixed like:
> RestResponseHolder res = MAPPER.readValue(resp.body().byteStream(), 
> RestResponseHolder.class); 
> Where for RestResponseHolder should also created optimized 
> RestResponseHolderDeserializer that will extract response as String without 
> building tree of JsonNodes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6013) Web agent: refactor processing response from cluster

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-6013:


Hi [~kuaw26],
I think will be better to create generic deserializer for such fields and bind 
it using annotation JsonDeserialize. What do you think about this?

> Web agent: refactor processing response from cluster
> 
>
> Key: IGNITE-6013
> URL: https://issues.apache.org/jira/browse/IGNITE-6013
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> RestExecutor.sendRequest() contain following code:
> {code}
> 
> try (Response resp = 
> httpClient.newCall(reqBuilder.build()).execute()) {
> String content = resp.body().string();
> if (resp.isSuccessful()) {
> JsonNode node = mapper.readTree(content);
>  
> {code}
> Problems: 
> # String content = resp.body().string(); >> Generate not needed String.
> # JsonNode node = mapper.readTree(content);  >> Generates a big tree of 
> JsonNodes
>  
> Could be fixed like:
> RestResponseHolder res = MAPPER.readValue(resp.body().byteStream(), 
> RestResponseHolder.class); 
> Where for RestResponseHolder should also created optimized 
> RestResponseHolderDeserializer that will extract response as String without 
> building tree of JsonNodes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5901) Ignite PDS Indexing Suite: IgniteWalRecoveryTest.testWalRolloverMultithreadedLogOnly is now flaky on TC with AsynchronousCloseException

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-5901:


Assignee: Alexey Goncharuk

> Ignite PDS Indexing Suite: 
> IgniteWalRecoveryTest.testWalRolloverMultithreadedLogOnly is now flaky on TC 
> with AsynchronousCloseException
> ---
>
> Key: IGNITE-5901
> URL: https://issues.apache.org/jira/browse/IGNITE-5901
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Goncharuk
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
>  
> http://ci.ignite.apache.org/viewLog.html?buildId=746981=buildResultsDiv=Ignite20Tests_IgnitePdsIndexing#testNameId2317518850927682700
> {noformat}
> class org.apache.ignite.internal.pagemem.wal.StorageException: null
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2037)
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$1700(FileWriteAheadLogManager.java:1636)
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.fsync(FileWriteAheadLogManager.java:538)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1922)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1686)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:481)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:441)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1167)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:656)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2334)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2311)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1029)
> at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:872)
> at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:536)
> at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:531)
> at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> Caused by: java.nio.channels.AsynchronousCloseException
> at 
> java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:205)
> at sun.nio.ch.FileChannelImpl.force(FileChannelImpl.java:380)
> at 
> org.apache.ignite.internal.processors.cache.persistence.file.RandomAccessFileIO.force(RandomAccessFileIO.java:92)
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2034)
> ... 17 more
> {noformat}
> Locally test is passing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5736) Add test of backward-compatibility

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-5736:


[PR-2425|https://github.com/apache/ignite/pull/2425] contains changes of 3 
tasks:
IGNITE-5732 Provide API to test compatibility with old releases
IGNITE-5097 BinaryMarshaller should write ints in "varint" encoding where it 
makes sense (parent issue)
IGNITE-5736 Add test of backward-compatibility (current issue)

[Upsource review 
created.|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-274]

[Upsource link to VarintArraysSizeCompatibilityTest 
only.|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-274?filePath=/modules/compatibility/src/test/java/org/apache/ignite/compatibility/binary/VarintArraysSizeCompatibilityTest.java]

> Add test of backward-compatibility
> --
>
> Key: IGNITE-5736
> URL: https://issues.apache.org/jira/browse/IGNITE-5736
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> Need to add unit-test to test compatibility with AI 2.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (IGNITE-5736) Add test of backward-compatibility

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-5736:
---
Comment: was deleted

(was: [Link to VarintArraysSizeCompatibilityTest 
only.|https://github.com/daradurvs/ignite/blob/44e50af75b438b3524babe93b0fa64067bb26105/modules/compatibility/src/test/java/org/apache/ignite/compatibility/binary/VarintArraysSizeCompatibilityTest.java])

> Add test of backward-compatibility
> --
>
> Key: IGNITE-5736
> URL: https://issues.apache.org/jira/browse/IGNITE-5736
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> Need to add unit-test to test compatibility with AI 2.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5233) JDBC thin Driver: implement metadata support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5233:
-

[~tledkov-gridgain]. my comments:
1) {{JdbcThinPreparedStatement.getParameterMetaData}} - metadata must be cached 
on first access.
2) {{JdbcThinIpcIo.tablesMeta}} - unused argument
3) {{JdbcParamMeta}} -> {{JdbcParameterMeta}}
4) {{JdbcThinParameterMetaData}} -> {{JdbcThinParameterMetadata}}
5) {{JdbcThinParameterMetaData}} - no bounds check (including invalid zero of 
negatove values), please refactor it to a single method which will throw 
SQLException if parameter is invalid
6) {{JdbcThinDatabaseMetadata.getDatabaseProductVersion}} - what is "4.1.0"?
7) {{JdbcThinDatabaseMetadata.getDatabaseProductName}} - "Ignite Cache"? What 
is that? There is no such a product
8) {{JdbcThinDatabaseMetadata.getDriverName}} - should be "Ignite JDBC Thin 
Driver"
9) {{JdbcThinDatabaseMetadata.supportsConvert}} - are we really do not support 
conversions?
10) {{JdbcThinDatabaseMetadata.get*Functions}} - are we really do not support 
any?
11) {{JdbcThinDatabaseMetadata.supports*SQLGrammar}} - why false?
12) {{JdbcThinDatabaseMetadata.supports*SQL}} - why false?
13) {{JdbcThinDatabaseMetadata.supportsFullOuterJoins}} - we do not support them
14) {{JdbcThinDatabaseMetadata.supportsSchemasIn*}} - why false?
15) {{JdbcThinDatabaseMetadata.getTypeInfo}} - why empty?
16) {{JdbcThinDatabaseMetadata.supportsResultSetType}} - why true? We support 
only forward_only read_only type.
17) {{JdbcThinDatabaseMetadata.getUDTs}} - we need a ticket for this.
18) {{JdbcThinDatabaseMetadata.getDatabaseMajorVersion}} - why 1??? 
19) {{JdbcThinDatabaseMetadata.getDatabaseMinorVersion}} - why 0??? 
20) {{JdbcThinDatabaseMetadata.supportsStatementPooling}} - why false?
21) {{JdbcThinDatabaseMetadata.supportsStoredFunctionsUsingCallSyntax}} - is it 
really false?
22) {{JdbcThinDatabaseMetadata.getClientInfoProperties}} - shouldn't we list 
our connection string properties here?
23) {{JdbcThinDatabaseMetadata.getFunctions}} - why empty?

> JDBC thin Driver: implement metadata support 
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6012) Improve GridJettyRestHandler.processRequest()

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-6012:
--

Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Improve GridJettyRestHandler.processRequest()
> -
>
> Key: IGNITE-6012
> URL: https://issues.apache.org/jira/browse/IGNITE-6012
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.1
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>
> In case of large result  
> {code}
> private void processRequest(String act, HttpServletRequest req, 
> HttpServletResponse res) {
> ...
> json = jsonMapper.writeValueAsString(cmdRes)
> 
> {code}
> Will fail with OOME, beacuse jsonMapper.writeValueAsString(cmdRes) internally 
> will create a StringBuilder and will try to allocate large amount of memory.
> This could be easily fixed by writing object directly to response output 
> stream via. 
> {code}
> jsonMapper.writeValue(out, cmdRes);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6012) Improve GridJettyRestHandler.processRequest()

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-6012:


Hi [~kuaw26],
Reviewed your changes, added some minor fixes. Please merge. 

> Improve GridJettyRestHandler.processRequest()
> -
>
> Key: IGNITE-6012
> URL: https://issues.apache.org/jira/browse/IGNITE-6012
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.1
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> In case of large result  
> {code}
> private void processRequest(String act, HttpServletRequest req, 
> HttpServletResponse res) {
> ...
> json = jsonMapper.writeValueAsString(cmdRes)
> 
> {code}
> Will fail with OOME, beacuse jsonMapper.writeValueAsString(cmdRes) internally 
> will create a StringBuilder and will try to allocate large amount of memory.
> This could be easily fixed by writing object directly to response output 
> stream via. 
> {code}
> jsonMapper.writeValue(out, cmdRes);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5963) Ignite Cache 6: Flaky failure IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5963:


Cycled TC run passed. 30 runs are successfull. Failures in other test came from 
my issue [IGNITE-5759]

>  Ignite Cache 6: Flaky failure 
> IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC
> --
>
> Key: IGNITE-5963
> URL: https://issues.apache.org/jira/browse/IGNITE-5963
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Test sometimes fails on teamcity, please see
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-6026696383836355176=testDetails
> {noformat}
> java.lang.AssertionError: Exception has not been thrown.
> at 
> org.apache.ignite.testframework.GridTestUtils.assertThrowsWithCause(GridTestUtils.java:425)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:464)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:455)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:697)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:669)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnSuspend(IgniteOptimisticTxSuspendResumeTest.java:455)
> {noformat}
> Test was created under issue IGNITE-5712
> Does not reprocuced locally (30 runs on Win10).
> But on CI server success rate is 94%



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5963) Ignite Cache 6: Flaky failure IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-5963:
-

[~avinogradov] Can you review my changes?

>  Ignite Cache 6: Flaky failure 
> IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend on TC
> --
>
> Key: IGNITE-5963
> URL: https://issues.apache.org/jira/browse/IGNITE-5963
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Test sometimes fails on teamcity, please see
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-6026696383836355176=testDetails
> {noformat}
> java.lang.AssertionError: Exception has not been thrown.
> at 
> org.apache.ignite.testframework.GridTestUtils.assertThrowsWithCause(GridTestUtils.java:425)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:464)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$15.applyx(IgniteOptimisticTxSuspendResumeTest.java:455)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:697)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:669)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnSuspend(IgniteOptimisticTxSuspendResumeTest.java:455)
> {noformat}
> Test was created under issue IGNITE-5712
> Does not reprocuced locally (30 runs on Win10).
> But on CI server success rate is 94%



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6025) SQL: improve CREATE INDEX performance

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6025:

Component/s: persistence

> SQL: improve CREATE INDEX performance
> -
>
> Key: IGNITE-6025
> URL: https://issues.apache.org/jira/browse/IGNITE-6025
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.2
>
>
> When bulk data load is performed, it is considered a good practice to bypass 
> certain facilities of underlying engine to achieve greater throughput. E.g., 
> TX or MVCC managers can by bypassed, global table lock can be held instead of 
> fine-grained page/row/field locks, etc.. 
> Another widely used technique is to drop table indexes and re-build them form 
> scratch when load finished. This is now possible with help of {{CREATE 
> INDEX}} command which could be executed in runtime. However, experiments with 
> large data sets shown that {{DROP INDEX}} -> load -> {{CREATE INDEX}} is 
> *much slower* than simple load to indexed table. The reasons for this are 
> both inefficient implementation of {{CREATE INDEX}} command, as well as some 
> storage architectural decisions.
> 1) Index is created by a single thread; probably multiple threads could speed 
> it up and the cost of higher CPU usage. But how to split iteration between 
> several threads?
> 2) Cache iteration happens through primary index. So we read an index page, 
> but to read entries we have to navigate to data page. If single data page is 
> referenced from N places in the index tree, we will read it N times. This 
> leads to bad cache locality in memory-only case, and to excessive disk IO in 
> case of persistence. This could be avoided, if we iterate over data pages, 
> and index all data from a single page at once.
> 3) Another widely used technique is building BTree in bottom-up approach. 
> That is, we sort all data rows first, then build leafs, then go one level up, 
> etc.. This approach could give us the best build performance possible, 
> especially if p.2 is implemented. However it is the most difficult 
> optimization, which will require implementation of spilling to disk if result 
> set is too large.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6025) SQL: improve CREATE INDEX performance

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6025:

Labels: performance  (was: )

> SQL: improve CREATE INDEX performance
> -
>
> Key: IGNITE-6025
> URL: https://issues.apache.org/jira/browse/IGNITE-6025
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.2
>
>
> When bulk data load is performed, it is considered a good practice to bypass 
> certain facilities of underlying engine to achieve greater throughput. E.g., 
> TX or MVCC managers can by bypassed, global table lock can be held instead of 
> fine-grained page/row/field locks, etc.. 
> Another widely used technique is to drop table indexes and re-build them form 
> scratch when load finished. This is now possible with help of {{CREATE 
> INDEX}} command which could be executed in runtime. However, experiments with 
> large data sets shown that {{DROP INDEX}} -> load -> {{CREATE INDEX}} is 
> *much slower* than simple load to indexed table. The reasons for this are 
> both inefficient implementation of {{CREATE INDEX}} command, as well as some 
> storage architectural decisions.
> 1) Index is created by a single thread; probably multiple threads could speed 
> it up and the cost of higher CPU usage. But how to split iteration between 
> several threads?
> 2) Cache iteration happens through primary index. So we read an index page, 
> but to read entries we have to navigate to data page. If single data page is 
> referenced from N places in the index tree, we will read it N times. This 
> leads to bad cache locality in memory-only case, and to excessive disk IO in 
> case of persistence. This could be avoided, if we iterate over data pages, 
> and index all data from a single page at once.
> 3) Another widely used technique is building BTree in bottom-up approach. 
> That is, we sort all data rows first, then build leafs, then go one level up, 
> etc.. This approach could give us the best build performance possible, 
> especially if p.2 is implemented. However it is the most difficult 
> optimization, which will require implementation of spilling to disk if result 
> set is too large.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6025) SQL: improve CREATE INDEX performance

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6025:
---

 Summary: SQL: improve CREATE INDEX performance
 Key: IGNITE-6025
 URL: https://issues.apache.org/jira/browse/IGNITE-6025
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
 Fix For: 2.2


When bulk data load is performed, it is considered a good practice to bypass 
certain facilities of underlying engine to achieve greater throughput. E.g., TX 
or MVCC managers can by bypassed, global table lock can be held instead of 
fine-grained page/row/field locks, etc.. 

Another widely used technique is to drop table indexes and re-build them form 
scratch when load finished. This is now possible with help of {{CREATE INDEX}} 
command which could be executed in runtime. However, experiments with large 
data sets shown that {{DROP INDEX}} -> load -> {{CREATE INDEX}} is *much 
slower* than simple load to indexed table. The reasons for this are both 
inefficient implementation of {{CREATE INDEX}} command, as well as some storage 
architectural decisions.

1) Index is created by a single thread; probably multiple threads could speed 
it up and the cost of higher CPU usage. But how to split iteration between 
several threads?
2) Cache iteration happens through primary index. So we read an index page, but 
to read entries we have to navigate to data page. If single data page is 
referenced from N places in the index tree, we will read it N times. This leads 
to bad cache locality in memory-only case, and to excessive disk IO in case of 
persistence. This could be avoided, if we iterate over data pages, and index 
all data from a single page at once.
3) Another widely used technique is building BTree in bottom-up approach. That 
is, we sort all data rows first, then build leafs, then go one level up, etc.. 
This approach could give us the best build performance possible, especially if 
p.2 is implemented. However it is the most difficult optimization, which will 
require implementation of spilling to disk if result set is too large.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6024) SQL: execute DML statements on the server when possible

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6024:

Labels: performance  (was: )

> SQL: execute DML statements on the server when possible
> ---
>
> Key: IGNITE-6024
> URL: https://issues.apache.org/jira/browse/IGNITE-6024
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.2
>
>
> Currently we execute DML statements as follows:
> 1) Get query result set to the client
> 2) Construct entry processors and send them to servers in batches
> This approach is inefficient as it causes a lot of unnecessary network 
> communication  Instead, we should execute DML statements directly on server 
> nodes when it is possible.
> Implementation considerations:
> 1) Determine set of queries which could be processed in this way. E.g., 
> {{LIMIT/OFFSET}}, {{GROUP BY}}, {{ORDER BY}}, {{DISTINCT}}, etc. are out of 
> question - they must go through the client anyway. Probably 
> {{skipMergeTable}} flag is a good starting point (good, not precise!)
> 2) Send request to every server and execute local DML right there
> 3) No failover support at the moment - throw "partial update" exception if 
> topology is unstable
> 4) Handle partition reservation carefully
> 5) Transactions: we still have single coordinator - this is a client. When 
> MVCC and TX SQL is ready, client will assign proper counters to server 
> requests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6024) SQL: execute DML statements on the server when possible

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6024:
---

 Summary: SQL: execute DML statements on the server when possible
 Key: IGNITE-6024
 URL: https://issues.apache.org/jira/browse/IGNITE-6024
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
 Fix For: 2.2


Currently we execute DML statements as follows:
1) Get query result set to the client
2) Construct entry processors and send them to servers in batches

This approach is inefficient as it causes a lot of unnecessary network 
communication  Instead, we should execute DML statements directly on server 
nodes when it is possible.

Implementation considerations:
1) Determine set of queries which could be processed in this way. E.g., 
{{LIMIT/OFFSET}}, {{GROUP BY}}, {{ORDER BY}}, {{DISTINCT}}, etc. are out of 
question - they must go through the client anyway. Probably {{skipMergeTable}} 
flag is a good starting point (good, not precise!)
2) Send request to every server and execute local DML right there
3) No failover support at the moment - throw "partial update" exception if 
topology is unstable
4) Handle partition reservation carefully
5) Transactions: we still have single coordinator - this is a client. When MVCC 
and TX SQL is ready, client will assign proper counters to server requests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4784) Web Console: Revise demo mode

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-4784:


Assignee: Dmitriy Shabalin  (was: Vica Abramova)

> Web Console: Revise demo mode
> -
>
> Key: IGNITE-4784
> URL: https://issues.apache.org/jira/browse/IGNITE-4784
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Dmitriy Shabalin
> Fix For: 2.2
>
>
> Let's add animated blue line.
> Demo: https://marvelapp.com/32e928b
> # Link 'Close Demo' should be red onhover.
> # Let's delete btn 'Close Demo' on demo mode
> # We should use affix behaviour (*y)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4784) Web Console: Revise demo mode

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4784:
-
Fix Version/s: 2.2

> Web Console: Revise demo mode
> -
>
> Key: IGNITE-4784
> URL: https://issues.apache.org/jira/browse/IGNITE-4784
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
> Fix For: 2.2
>
>
> Let's add animated blue line.
> Demo: https://marvelapp.com/32e928b
> # Link 'Close Demo' should be red onhover.
> # Let's delete btn 'Close Demo' on demo mode
> # We should use affix behaviour (*y)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6004) SQL: add "inlineSize" to QuerySqlField annotation

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6004 at 8/10/17 9:00 AM:
---

[Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2420%2Fhead]
 are OK with me.

[~vozerov], [~skalashnikov], please review the patch.


was (Author: tledkov-gridgain):
Waits for [tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2420%2Fhead].

[~vozerov], [~skalashnikov], please review the patch.

> SQL: add "inlineSize" to QuerySqlField annotation
> -
>
> Key: IGNITE-6004
> URL: https://issues.apache.org/jira/browse/IGNITE-6004
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>  Labels: usability
> Fix For: 2.2
>
>
> "inlineSize" is very important optimization allowing to avoid excessive data 
> page reads when using index. However, it can only be set through 
> {{QueryEntity}} -> {{QueryIndex}} chain, and cannot be set through 
> {{\@QuerySqlField}} annotation.
> Let's fix that and add {{int indexInlineSize}} parameter to that annotation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6023) Index inline should be enabled by default for fixed-length data types

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6023:
---

 Summary: Index inline should be enabled by default for 
fixed-length data types
 Key: IGNITE-6023
 URL: https://issues.apache.org/jira/browse/IGNITE-6023
 Project: Ignite
  Issue Type: Improvement
  Components: persistence, sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
 Fix For: 2.2


Currently index inline is not enabled by default. This is ok for variable 
length types such as strings because we cannot enforce their length at the 
moment (it would require changes to DDL). But for fixed-length data types it is 
perfectly OK to enable inline by default:
- int
- long
- date



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6023) Index inline should be enabled by default for fixed-length data types

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6023:

Labels: performance usability  (was: )

> Index inline should be enabled by default for fixed-length data types
> -
>
> Key: IGNITE-6023
> URL: https://issues.apache.org/jira/browse/IGNITE-6023
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance, usability
> Fix For: 2.2
>
>
> Currently index inline is not enabled by default. This is ok for variable 
> length types such as strings because we cannot enforce their length at the 
> moment (it would require changes to DDL). But for fixed-length data types it 
> is perfectly OK to enable inline by default:
> - int
> - long
> - date



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6022) SQL: add native batch execution support for DML statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6022:

Issue Type: Improvement  (was: Bug)

> SQL: add native batch execution support for DML statements
> --
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.2
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases 
> number of network hops. However, we do not have any batch execution support 
> on the server side. It means that for batch of N similar statements, every 
> statement will go through the whole execution chain - parsing, splitting, 
> communication with servers. And while parsing and splitting might be avoided 
> with help of statement cache, the most heavy part - network communication - 
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible 
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse 
> the same request multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6021) SQL: support asynchronous page prefetch on client side

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6021:

Labels: performance  (was: )

> SQL: support asynchronous page prefetch on client side
> --
>
> Key: IGNITE-6021
> URL: https://issues.apache.org/jira/browse/IGNITE-6021
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.2
>
>
> This ticket should be done after IGNITE-6019. We should allow users to 
> control how many pages to prefetch when executing queries. New API should be 
> constructed carefully, taking in count the following considerations:
> 1) Sometimes user wants to get the first page ASAP, e.g. to display it on UI. 
> In this case prefetch size should be 0. This is the best candidate for 
> default value.
> 2) Sometimes user wants to get all results ASAP. E.g. for batch processing. 
> In this case we should change our communication logic - instead of "request - 
> response" model, we should employ "request - all responses" model, when we 
> start query execution, and server pushes everything to the client without 
> waiting for "next page request". This should be some special value, e.g. "-1".
> 3) And sometimes user want to have some real prefetch. E.g. because 
> individual row processing on a client side is expensive, and user may benefit 
> from concurrent fetching. In this case user should be able to set some 
> positive integer defining how many pages to request in advance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6022) SQL: add native batch execution support for DML statements

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6022:
---

 Summary: SQL: add native batch execution support for DML statements
 Key: IGNITE-6022
 URL: https://issues.apache.org/jira/browse/IGNITE-6022
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
 Fix For: 2.2


We have batch execution support for JDBC and ODBC drivers. This decreases 
number of network hops. However, we do not have any batch execution support on 
the server side. It means that for batch of N similar statements, every 
statement will go through the whole execution chain - parsing, splitting, 
communication with servers. And while parsing and splitting might be avoided 
with help of statement cache, the most heavy part - network communication - is 
still there.

We need to investigate how to optimize the flow for batch updates. Possible 
improvements:
1) Execute statements with certain degree of parallelism;
2) Send several query execution requests to the server at once;
3) Ensure that caches are used properly for batching - we should not parse the 
same request multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6022) SQL: add native batch execution support for DML statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6022:

Labels: performance  (was: )

> SQL: add native batch execution support for DML statements
> --
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.2
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases 
> number of network hops. However, we do not have any batch execution support 
> on the server side. It means that for batch of N similar statements, every 
> statement will go through the whole execution chain - parsing, splitting, 
> communication with servers. And while parsing and splitting might be avoided 
> with help of statement cache, the most heavy part - network communication - 
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible 
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse 
> the same request multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6019) SQL: client node should not hold the whole data set in-memory when possible

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6019:

Issue Type: Improvement  (was: Bug)

> SQL: client node should not hold the whole data set in-memory when possible
> ---
>
> Key: IGNITE-6019
> URL: https://issues.apache.org/jira/browse/IGNITE-6019
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Critical
>  Labels: performance
> Fix For: 2.2
>
>
> Our SQL engine requests request data from server nodes in pieces called 
> "page". This allows us to control memory consumption on client side. However, 
> currently our client code is designed in a way that all pages are requested 
> from all servers before a single cursor row is returned to the user. It 
> defeats the whole idea of "cursor" and "page", and could easily crash client 
> node with OOME. 
> We need to fix that and request further pages in a kind of sliding window, 
> keeping no more than "N" pages in memory simultaneously. Note that sometimes 
> it is not possible, e.g. in case of {{DISTINCT}} or non-collocated {{GROUP 
> BY}}. In this case we would have to build the whole result set first anyway. 
> So let's focus on a scenario when the whole result set is not needed.
> As currently everything is requested synchronously page-by-page, in the first 
> version it would be enough to distribute synchronous page requests between 
> cursor reads, without any prefetch. 
> Implementation details:
> 1) Optimization should be applied only to {{skipMergeTbl=true}} cases, when 
> complete result set of map queries is not needed.
> 2) Starting point is {{GridReduceQueryExecutor#query}}, see 
> {{skipMergeTbl=true}} branch - this is where we get all pages eagerly.
> 3) Get no more than one page from the server at a time. We request the page, 
> iterate over it, then request another page.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)