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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5884:

Description: 
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 expose 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.*

  was:
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.*


> 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
>Priority: Critical
>  Labels: usability
> 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 expose 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] [Updated] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Denis Magda (JIRA)]

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

Denis Magda 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

Branch with the changes: 
https://svn.apache.org/repos/asf/ignite/site/ignite-6036

Update Ignite overview on the db-engines once the ticket is ready: 
https://db-engines.com/en/system/Ignite

  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 In-Memory Data Grids page (explain persistence)
## fix Key-Value Store page to reflect native persistence
## fix JCache Provider page to reflect native persistence

Branch with the changes: 
https://svn.apache.org/repos/asf/ignite/site/ignite-6036


> 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
> Branch with the changes: 
> https://svn.apache.org/repos/asf/ignite/site/ignite-6036
> Update Ignite overview on the db-engines once the ticket is ready: 
> https://db-engines.com/en/system/Ignite



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

[jira] [Updated] (IGNITE-6046) Multiple SQL statements in one JDBC command do not work

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6046:

Labels: usability  (was: )

> Multiple SQL statements in one JDBC command do not work
> ---
>
> Key: IGNITE-6046
> URL: https://issues.apache.org/jira/browse/IGNITE-6046
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Reporter: Dmitriy Setrakyan
>Assignee: Vladimir Ozerov
>  Labels: usability
> Fix For: 2.2
>
>
> I have connected to Ignite from DBeaver using our thin JDBC driver. When I 
> execute more than one statement from the SQL Editor, I get an error.
> For example, highlighting and executing these 2 statements gives an error:
> {code:sql}
> INSERT INTO city (id, name) VALUES (2, 'Forest Hill');
> INSERT INTO person (id, name, city_id) VALUES (2, 'John Doe', 3);
> {code}
> Here is the error I get:
> {code}
> [15:25:17,265][SEVERE][sql-connector-#150%null%][JdbcRequestHandler] Failed 
> to execute SQL query [reqId=26, req=JdbcQueryExecuteRequest [schemaName=null, 
> pageSize=1024, maxRows=0, sqlQry=INSERT INTO city (id, name) VALUES (2, 
> 'Forest Hill');
> INSERT INTO person (id, name, city_id) VALUES (2, 'John Doe', 3), args=[]]]
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
> Can not set org.h2.command.Prepared field 
> org.h2.command.CommandContainer.prepared to org.h2.command.CommandList
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1863)
> at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:188)
> at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:122)
> at 
> org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:152)
> at 
> org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:44)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteCheckedException: Can not set 
> org.h2.command.Prepared field org.h2.command.CommandContainer.prepared to 
> org.h2.command.CommandList
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2316)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1860)
> ... 12 more
> Caused by: java.lang.IllegalArgumentException: Can not set 
> org.h2.command.Prepared field org.h2.command.CommandContainer.prepared to 
> org.h2.command.CommandList
> at 
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
> at 
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
> at 
> sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:58)
> at 
> sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:36)
> at java.lang.reflect.Field.get(Field.java:393)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser$Getter.get(GridSqlQueryParser.java:1600)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.prepared(GridSqlQueryParser.java:443)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1298)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1856)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1852)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at 
> 

[jira] [Created] (IGNITE-6116) Easy way to enable metrics for default memory region

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6116:
---

 Summary: Easy way to enable metrics for default memory region
 Key: IGNITE-6116
 URL: https://issues.apache.org/jira/browse/IGNITE-6116
 Project: Ignite
  Issue Type: Improvement
Reporter: Denis Magda


Presently it's a bit challenging to enable memory metrics for the default 
memory region unless you define a new one. Add the following two methods to 
{{MemoryConfiguration}} to address the issue.

{code}
MemoryConfiguration.setDefaultMemoryPolicyMetricsEnabled(boolean)
boolean MemoryConfiguration.isDefaultMemoryPolicyMetricsEnabled()
{code}

Discussion on @dev list: 
http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-memory-and-persistence-metrics-td19582.html



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

[jira] [Updated] (IGNITE-6116) Easy way to enable metrics for default memory region

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6116:

Labels: usability  (was: )

> Easy way to enable metrics for default memory region
> 
>
> Key: IGNITE-6116
> URL: https://issues.apache.org/jira/browse/IGNITE-6116
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Denis Magda
>  Labels: usability
> Fix For: 2.2
>
>
> Presently it's a bit challenging to enable memory metrics for the default 
> memory region unless you define a new one. Add the following two methods to 
> {{MemoryConfiguration}} to address the issue.
> {code}
> MemoryConfiguration.setDefaultMemoryPolicyMetricsEnabled(boolean)
> boolean MemoryConfiguration.isDefaultMemoryPolicyMetricsEnabled()
> {code}
> Discussion on @dev list: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-memory-and-persistence-metrics-td19582.html



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

[jira] [Updated] (IGNITE-6116) Easy way to enable metrics for default memory region

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6116:

Fix Version/s: 2.2

> Easy way to enable metrics for default memory region
> 
>
> Key: IGNITE-6116
> URL: https://issues.apache.org/jira/browse/IGNITE-6116
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Denis Magda
>  Labels: usability
> Fix For: 2.2
>
>
> Presently it's a bit challenging to enable memory metrics for the default 
> memory region unless you define a new one. Add the following two methods to 
> {{MemoryConfiguration}} to address the issue.
> {code}
> MemoryConfiguration.setDefaultMemoryPolicyMetricsEnabled(boolean)
> boolean MemoryConfiguration.isDefaultMemoryPolicyMetricsEnabled()
> {code}
> Discussion on @dev list: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-memory-and-persistence-metrics-td19582.html



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

[jira] [Updated] (IGNITE-6116) Easy way to enable metrics for default memory region

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6116:

Affects Version/s: 2.1

> Easy way to enable metrics for default memory region
> 
>
> Key: IGNITE-6116
> URL: https://issues.apache.org/jira/browse/IGNITE-6116
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Denis Magda
>  Labels: usability
> Fix For: 2.2
>
>
> Presently it's a bit challenging to enable memory metrics for the default 
> memory region unless you define a new one. Add the following two methods to 
> {{MemoryConfiguration}} to address the issue.
> {code}
> MemoryConfiguration.setDefaultMemoryPolicyMetricsEnabled(boolean)
> boolean MemoryConfiguration.isDefaultMemoryPolicyMetricsEnabled()
> {code}
> Discussion on @dev list: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-memory-and-persistence-metrics-td19582.html



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

[jira] [Updated] (IGNITE-6064) Rework control.sh script

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6064:

Labels: usability  (was: )

> Rework control.sh script
> 
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
>  Labels: usability
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if  incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to 
> [ip-address]:[port] etc."
> 5. Document the usage on a special page. Ping Denis Magda when it's time to 
> do that.



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

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5884:
-

Discussion on the @dev list: 
http://apache-ignite-developers.2346864.n4.nabble.com/Default-page-size-must-be-changed-to-4k-Should-it-be-backwards-compatible-td20865.html#a20874

> 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
>Priority: Critical
>  Labels: usability
> 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] [Updated] (IGNITE-5884) Change default pageSize of page memory to 4KB

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5884:

Labels: usability  (was: )

> 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
>  Labels: usability
> 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] [Updated] (IGNITE-5884) Change default pageSize of page memory to 4KB

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5884:

Priority: Critical  (was: Major)

> 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
>Priority: Critical
>  Labels: usability
> 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] [Updated] (IGNITE-6115) Ignore page eviction mode if Ignite persistence is enabled

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6115:

Labels: usability  (was: )

> Ignore page eviction mode if Ignite persistence is enabled
> --
>
> Key: IGNITE-6115
> URL: https://issues.apache.org/jira/browse/IGNITE-6115
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Denis Magda
>  Labels: usability
> Fix For: 2.2
>
>
> If a page eviction mode is defined for a memory region and the Ignite Native 
> Persistence is enabled then the following exception is thrown on a node 
> startup:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter []
>at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1791)
>at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:929)
>at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1896)
>at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1648)
>at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1076)
>at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:994)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:880)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:779)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:618)
>at org.apache.ignite.Ignition.start(Ignition.java:347)
>at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Page eviction is
> not compatible with persistence: 1G_Region
>at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkPolicyEvictionProperties(GridCacheDatabaseSharedManager.java:660)
>at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.validateConfiguration(IgniteCacheDatabaseSharedManager.java:336)
>at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:109)
>at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:358)
>at
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
>at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:696)
>at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1788)
> {code}
> That case has to be processed differently:
> * Ignore the page eviction mode and let the node to proceed with the startup.
> * Print a warning "Page eviction mode for {name} memory region is ignored 
> because Ignite Native Persistence is enabled".
> Discussion on the dev list: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Ignite2-1-Page-eviction-is-not-compatible-with-persistence-when-startup-td20934.html



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

[jira] [Created] (IGNITE-6115) Ignore page eviction mode if Ignite persistence is enabled

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6115:
---

 Summary: Ignore page eviction mode if Ignite persistence is enabled
 Key: IGNITE-6115
 URL: https://issues.apache.org/jira/browse/IGNITE-6115
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.1
Reporter: Denis Magda
 Fix For: 2.2


If a page eviction mode is defined for a memory region and the Ignite Native 
Persistence is enabled then the following exception is thrown on a node startup:
{code}
class org.apache.ignite.IgniteCheckedException: Failed to start processor:
GridProcessorAdapter []
   at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1791)
   at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:929)
   at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1896)
   at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1648)
   at
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1076)
   at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:994)
   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:880)
   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:779)
   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649)
   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:618)
   at org.apache.ignite.Ignition.start(Ignition.java:347)
   at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
Caused by: class org.apache.ignite.IgniteCheckedException: Page eviction is
not compatible with persistence: 1G_Region
   at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkPolicyEvictionProperties(GridCacheDatabaseSharedManager.java:660)
   at
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.validateConfiguration(IgniteCacheDatabaseSharedManager.java:336)
   at
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:109)
   at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:358)
   at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
   at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:696)
   at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1788)
{code}

That case has to be processed differently:
* Ignore the page eviction mode and let the node to proceed with the startup.
* Print a warning "Page eviction mode for {name} memory region is ignored 
because Ignite Native Persistence is enabled".

Discussion on the dev list: 
http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Ignite2-1-Page-eviction-is-not-compatible-with-persistence-when-startup-td20934.html



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

[jira] [Updated] (IGNITE-5836) AffinityFunctionContext should provide consistent previous assignment

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5836:

Labels: usability  (was: )

> AffinityFunctionContext should provide consistent previous assignment
> -
>
> Key: IGNITE-5836
> URL: https://issues.apache.org/jira/browse/IGNITE-5836
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Critical
>  Labels: usability
> Fix For: 2.2
>
>
> Currently each cache maintains its own {{AffinityFunctionContext}}. This 
> leads to the case that {{previousAssignment}} can be different for two caches 
> created on different topology versions. In particular, this broke 
> {{FairAffinityFunction}} which was removed because of that.
> We should do the following:
> * Make sure that {{previousAssignment}} is consistent for all caches with 
> same affinity function, regardless of topology versions caches were created 
> on.
> * Add mechanism to enforce equality check for affinity functions. We probably 
> will need to force user to implement {{equals}} for cache node filter and 
> backup filter.
> * When above is done, bring back {{FairAffinityFunction}}.
> This is also discussed on dev list: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Resurrect-FairAffinityFunction-td19987.html



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

[jira] [Commented] (IGNITE-6003) Detecting low memory on ignite node startup

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6003:
-

Discussion on the @dev list: 
http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-5717-improvements-of-MemoryPolicy-default-size-td20264.html

> Detecting low memory on ignite node startup
> ---
>
> Key: IGNITE-6003
> URL: https://issues.apache.org/jira/browse/IGNITE-6003
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
>  Labels: usability
> Fix For: 2.2
>
>
> h2. Motivation
> Starting from version 2.0 Ignite keeps all data in offheap area and allocates 
> this area on startup based on MemoryPolicy settings.
> So several Ignite nodes started on the same machine may allocate an order of 
> magnitude more memory than physically available so putting pressure on such 
> cluster will cause the machine to hang.
> h2. Acceptance Criteria
> # Reliable cross-platform algorithm to detect low memory is developed.
> # Ignite node fails to start with descriptive error message when the 
> algorithm detects low memory which may cause hang.



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

[jira] [Updated] (IGNITE-6003) Detecting low memory on ignite node startup

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6003:

Labels: usability  (was: )

> Detecting low memory on ignite node startup
> ---
>
> Key: IGNITE-6003
> URL: https://issues.apache.org/jira/browse/IGNITE-6003
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
>  Labels: usability
> Fix For: 2.2
>
>
> h2. Motivation
> Starting from version 2.0 Ignite keeps all data in offheap area and allocates 
> this area on startup based on MemoryPolicy settings.
> So several Ignite nodes started on the same machine may allocate an order of 
> magnitude more memory than physically available so putting pressure on such 
> cluster will cause the machine to hang.
> h2. Acceptance Criteria
> # Reliable cross-platform algorithm to detect low memory is developed.
> # Ignite node fails to start with descriptive error message when the 
> algorithm detects low memory which may cause hang.



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

[jira] [Updated] (IGNITE-6099) ODBC: Implement SQLGetInfo for all info types

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6099:

Labels: usability  (was: )

> ODBC: Implement SQLGetInfo for all info types
> -
>
> Key: IGNITE-6099
> URL: https://issues.apache.org/jira/browse/IGNITE-6099
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: usability
> Fix For: 2.2
>
>
> Currently not all the info types supported for {{SQLGetInfo}}. Need to 
> implement fully. Details can be found here - 
> https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetinfo-function



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

[jira] [Commented] (IGNITE-5061) Add ability to enable and disable rebalancing per-node

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-5061:
--

The change looks good to me.

> Add ability to enable and disable rebalancing per-node
> --
>
> Key: IGNITE-5061
> URL: https://issues.apache.org/jira/browse/IGNITE-5061
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Alexander Belyak
> Fix For: 2.2
>
>
> It would be nice to have an ability to enable and disable rebalancing per 
> node. 
> First of all, we need to come up with a simple API to allow this. 
> Corresponding methods most likely should be also added to Ignite MBean.
> We need to discuss on the dev-list whether it is enough to have this setting 
> per-node, or this needs to be done on a per-cache basis.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6024:


GitHub user skalashnikov opened a pull request:

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

IGNITE-6024: support for server-side dml



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

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

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

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


commit 7b3af51a3d6ec538a55c8b0172205a38b87f4e22
Author: skalashnikov 
Date:   2017-08-18T17:13:21Z

IGNITE-6024: support for server-side dml




> 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] [Comment Edited] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-6036 at 8/18/17 5:17 PM:
--

Proposed changes.

*Use Cases*
# Database (section)
## Distributed Database (page)
## In-Memory Database (page)
# In-Memory Caching (section)
## Data Grid (page)
## RDBMS Caching (page)
## Hibernate L2 Cache (page)
## Web Session Clustering (page)
# Ignite with Spark &  Hadoop (section)
## Left the unchanged...
#  Featured Solutions (section)
## Financial Services
## High Tech
## Internet of Things

Some of the changes in *Features*
* Distributed SQL (page - instead of Distributed Database that's in the *Use 
Cases*)
* Key-Value Store (page - instead of Data Grid that's in the *Use Cases*)
* JCache Provider (page)
*  ACID Transactions (page)

*Docs* menu items were revisited and rearranged. Added this section 
*Comparison*:
# Ignite vs NoSQL Databases
# Ignite vs RDBMS 


was (Author: dmagda):
Proposed changes.

*Use Cases*
# Database (section)
* Distributed Database (page)
* In-Memory Database (page)
# In-Memory Caching (section)
* Data Grid (page)
* RDBMS Caching (page)
* Hibernate L2 Cache (page)
* Web Session Clustering (page)
# Ignite with Spark &  Hadoop (section)
* Left the unchanged...
#  Featured Solutions (section)
* Financial Services
* High Tech
* Internet of Things

Some of the changes in *Features*
* Distributed SQL (page - instead of Distributed Database that's in the *Use 
Cases*)
* Key-Value Store (page - instead of Data Grid that's in the *Use Cases*)
* JCache Provider (page)
*  ACID Transactions (page)

*Docs* menu items were revisited and rearranged. Added this section 
*Comparison*:
# Ignite vs NoSQL Databases
# Ignite vs RDBMS 

> 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
> Branch with the changes: 
> https://svn.apache.org/repos/asf/ignite/site/ignite-6036



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

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

[Denis Magda (JIRA)]

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

Denis Magda 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

Branch with the changes: 
https://svn.apache.org/repos/asf/ignite/site/ignite-6036

  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 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
> Branch with the changes: 
> https://svn.apache.org/repos/asf/ignite/site/ignite-6036



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

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6036:
-

Proposed changes.

*Use Cases*
# Database (section)
* Distributed Database (page)
* In-Memory Database (page)
# In-Memory Caching (section)
* Data Grid (page)
* RDBMS Caching (page)
* Hibernate L2 Cache (page)
* Web Session Clustering (page)
# Ignite with Spark &  Hadoop (section)
* Left the unchanged...
#  Featured Solutions (section)
* Financial Services
* High Tech
* Internet of Things

Some of the changes in *Features*
* Distributed SQL (page - instead of Distributed Database that's in the *Use 
Cases*)
* Key-Value Store (page - instead of Data Grid that's in the *Use Cases*)
* JCache Provider (page)
*  ACID Transactions (page)

*Docs* menu items were revisited and rearranged. Added this section 
*Comparison*:
# Ignite vs NoSQL Databases
# Ignite vs RDBMS 

> 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] [Commented] (IGNITE-5872) Replace standard java maps for partition counters with more effective data structures

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-5872:
--

[~agura] Can you please also take a look?

> Replace standard java maps for partition counters with more effective data 
> structures
> -
>
> Key: IGNITE-5872
> URL: https://issues.apache.org/jira/browse/IGNITE-5872
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 2.2
>
>
> Currently we have map of Integer -> Tuple  which is passed for 
> each cache group. This is very inefficient as at causes a lot of boxes and 
> overheads in marshalling.
> This particular map can be replaced with a sorted primitive array.



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

[jira] [Created] (IGNITE-6114) Replace standard java maps for partition counters in continuous queries

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-6114:


 Summary: Replace standard java maps for partition counters in 
continuous queries
 Key: IGNITE-6114
 URL: https://issues.apache.org/jira/browse/IGNITE-6114
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.1
Reporter: Alexey Goncharuk
 Fix For: 2.2


This is a continuation of IGNITE-5872.

We need to replace standard java maps in StartRoutineDiscoveryMessage with the 
maps introduced in IGNITE-5872.



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

[jira] [Commented] (IGNITE-5872) Replace standard java maps for partition counters with more effective data structures

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-5872:
--

Ilya, thanks for the review. I've fixed the issue with prodVer. I also merged 
the latest changes from master and the diff with SchemaIndexCacheVisitorImpl 
has disappeared as it was fixed in the scope of IGNITE-6068.

I think it makes sense to change these maps in continuous queries as a separate 
ticket, otherwise, the change will be too intrusive and hard to verify. The 
ticket is created: IGNITE-6114

> Replace standard java maps for partition counters with more effective data 
> structures
> -
>
> Key: IGNITE-5872
> URL: https://issues.apache.org/jira/browse/IGNITE-5872
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 2.2
>
>
> Currently we have map of Integer -> Tuple  which is passed for 
> each cache group. This is very inefficient as at causes a lot of boxes and 
> overheads in marshalling.
> This particular map can be replaced with a sorted primitive array.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6035:


GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-6035 clean index on cache destroy



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

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

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

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


commit c3e91201623d6bdcfaa460a0c81bddb112eaa3eb
Author: Dmitriy Govorukhin 
Date:   2017-08-18T16:48:28Z

IGNITE-6035 WIP. Dirty fix.




> 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
>Assignee: Dmitriy Govorukhin
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> 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] [Comment Edited] (IGNITE-5872) Replace standard java maps for partition counters with more effective data structures

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh edited comment on IGNITE-5872 at 8/18/17 4:30 PM:
---

I've performed code review and found a few minor issues:
- GridDiscoveryManager.createDiscoCache(...) - shouldn't we do minProdVer = 
loc.version() in the beginning? Otherwise it might be possible in certain 
corner cases that DiscoCache.minProdVer == null.
- SchemaIndexCacheVisitorImpl.processPartition(...) - looks like it was 
modified to fix another, independent issue. I think it needs further 
investigation because fix looks very strange.

And, in general, I would like to see these optimized maps in continuous queries 
as well.


was (Author: ilantukh):
I've performed code review and found a few minor issues:
- GridDiscoveryManager.createDiscoCache(...) - shouldn't we do minProdVer = 
loc.version() in the beginning? Otherwise it might be possible in certain 
corner cases that DiscoCache.minProdVer == null.
- SchemaIndexCacheVisitorImpl.processPartition(...) - looks like it was 
modified to fix another, independent issue. I think it need further 
investigation because fix looks very strange.

And, in general, I would like to see these optimized maps in continuous queries 
as well.

> Replace standard java maps for partition counters with more effective data 
> structures
> -
>
> Key: IGNITE-5872
> URL: https://issues.apache.org/jira/browse/IGNITE-5872
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 2.2
>
>
> Currently we have map of Integer -> Tuple  which is passed for 
> each cache group. This is very inefficient as at causes a lot of boxes and 
> overheads in marshalling.
> This particular map can be replaced with a sorted primitive array.



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

[jira] [Comment Edited] (IGNITE-5872) Replace standard java maps for partition counters with more effective data structures

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh edited comment on IGNITE-5872 at 8/18/17 4:29 PM:
---

I've performed code review and found a few minor issues:
- GridDiscoveryManager.createDiscoCache(...) - shouldn't we do minProdVer = 
loc.version() in the beginning? Otherwise it might be possible in certain 
corner cases that DiscoCache.minProdVer == null.
- SchemaIndexCacheVisitorImpl.processPartition(...) - looks like it was 
modified to fix another, independent issue. I think it need further 
investigation because fix looks very strange.

And, in general, I would like to see these optimized maps in continuous queries 
as well.


was (Author: ilantukh):
I've performed code review and found a few minor issues:
- GridDiscoveryManager.createDiscoCache(...) - why shouldn't we do minProdVer = 
loc.version() in the beginning? Otherwise it might be possible in certain 
corner cases that DiscoCache.minProdVer == null.
- SchemaIndexCacheVisitorImpl.processPartition(...) - looks like it was 
modified to fix another, independent issue. I think it need further 
investigation because fix looks very strange.

And, in general, I would like to see these optimized maps in continuous queries 
as well.

> Replace standard java maps for partition counters with more effective data 
> structures
> -
>
> Key: IGNITE-5872
> URL: https://issues.apache.org/jira/browse/IGNITE-5872
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 2.2
>
>
> Currently we have map of Integer -> Tuple  which is passed for 
> each cache group. This is very inefficient as at causes a lot of boxes and 
> overheads in marshalling.
> This particular map can be replaced with a sorted primitive array.



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

[jira] [Commented] (IGNITE-5872) Replace standard java maps for partition counters with more effective data structures

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-5872:
--

I've performed code review and found a few minor issues:
- GridDiscoveryManager.createDiscoCache(...) - why shouldn't we do minProdVer = 
loc.version() in the beginning? Otherwise it might be possible in certain 
corner cases that DiscoCache.minProdVer == null.
- SchemaIndexCacheVisitorImpl.processPartition(...) - looks like it was 
modified to fix another, independent issue. I think it need further 
investigation because fix looks very strange.

And, in general, I would like to see these optimized maps in continuous queries 
as well.

> Replace standard java maps for partition counters with more effective data 
> structures
> -
>
> Key: IGNITE-5872
> URL: https://issues.apache.org/jira/browse/IGNITE-5872
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 2.2
>
>
> Currently we have map of Integer -> Tuple  which is passed for 
> each cache group. This is very inefficient as at causes a lot of boxes and 
> overheads in marshalling.
> This particular map can be replaced with a sorted primitive array.



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

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

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-5943:
--

Thanks, Eduard, merged your changes to master.

> 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] [Commented] (IGNITE-5943) Communication. Server node may reject client connection during massive clients join

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5943:


Github user asfgit closed the pull request at:

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


> 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] [Commented] (IGNITE-6051) Improve future listeners model in DataStreamerImpl

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-6051:
--

Changes look good to me. I would also like [~yzhdanov] or [~vozerov] to review 
these changes.

> Improve future listeners model in DataStreamerImpl
> --
>
> Key: IGNITE-6051
> URL: https://issues.apache.org/jira/browse/IGNITE-6051
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>
> Improve future listeners model on update not to add the same listener to a 
> future more than once ({{DataStreamerImpl.java:1410}})



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

[jira] [Commented] (IGNITE-3196) Marshaling works wrong for the BigDecimals that have negative scale

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3196:


GitHub user alamar reopened a pull request:

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

Backport IGNITE-3196

Add support for BigDecimals with negative scale in BinaryMarshaller

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

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

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

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


commit a62a0136d295486d95c6e2ab5bba88270d831753
Author: dkarachentsev 
Date:   2016-11-02T16:07:45Z

GG-11655 - Fix merge

commit 348593986b56ddfcec4a4455e49d9b279eae4dc8
Author: devozerov 
Date:   2016-11-05T10:28:03Z

Merge branch 'ignite-1.7.3' into ignite-1.7.4

commit 175da6b7e394dd76c27d5155ff98a5b2ef03bb9d
Author: tledkov-gridgain 
Date:   2016-11-07T06:16:58Z

IGNITE-3432:  check data/meta cache names are different for different IGFS 
instances. This closes #1201

commit ead15193899d08f41491166003cabed0560f0c59
Author: Pavel Tupitsyn 
Date:   2016-11-07T07:49:03Z

IGNITE-4028 Get rid of OP_META in PlatformAbstractTarget

This closes #1192

commit 40ef2f5ae42826fe8fd077e3013e8f55c8512bdd
Author: Dmitriy Govorukhin 
Date:   2016-11-07T09:09:41Z

ignite-4178 support permission builder

commit df670c7d64046d282c053f296c47a4743c58c8b1
Author: Pavel Tupitsyn 
Date:   2016-11-07T09:40:00Z

IGNITE-4118 .NET: Optimistic transaction example

This closes #1200

commit 474f22fda4c7cf4d7b2623c451cd7c10f0d8c636
Author: Pavel Tupitsyn 
Date:   2016-11-07T09:55:20Z

IGNITE-4119 .NET: add TransactionDeadlockException

commit fc7ce5a4d72145f2e8a86debeda264ef0a5b37e3
Author: isapego 
Date:   2016-11-07T10:26:05Z

IGNITE-4090: Added flags so stdint and limits can be used in C++.

commit a98804a249496ba9bafbc96daa7aaf25b3d36724
Author: Igor Sapego 
Date:   2016-11-07T11:00:00Z

IGNITE-4113: Added tests. Added Statement::Set/GetAttribute.

commit b1c7c9bb95c900083702d0ba0362edf3aea5a7b4
Author: sboikov 
Date:   2016-11-07T12:40:36Z

GG-11360 - Implement SQL queries cancellation
Fix for commit 80abd1b: for distributed joins need always send cancel 
request.

commit 319014de075c80fb15e58172cc24e35ce16b56cf
Author: Pavel Tupitsyn 
Date:   2016-11-07T14:53:40Z

IGNITE-4132 .NET: Improve BinaryConfiguration documentation

commit 950bad474ef29f9b808e74034c49a69d57eb2740
Author: dkarachentsev 
Date:   2016-11-08T11:03:34Z

GG-11655 - Restore service compatibility with releases before 1.5.30.

commit 3d19bfc2b66574e3945ce17c7a4dfe77d0070b8d
Author: dkarachentsev 
Date:   2016-11-08T11:04:36Z

Merge remote-tracking branch 'origin/ignite-1.6.11' into ignite-1.6.11

commit 1612b6d66fed032182a41e90da71e6b986ae087b
Author: Pavel Tupitsyn 
Date:   2016-11-08T11:07:54Z

.NET: Fix minor analysis warnings

commit e821dc0083003bc81058b1cb223d8a8a2ee44daf
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:09:21Z

IGNITE-2079 (revert commit) GridCacheIoManager eats exception trail if it 
falls into the directed case

commit c2c82ca44befe4570325dd6cf2ba885e0d90596c
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:10:10Z

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

commit 865bbcf0f41a0c4944e0928f1758d43a0eae82c5
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:18:29Z

Revert "Merge remote-tracking branch 'professional/ignite-1.6.11' into 
ignite-1.6.11"

This reverts commit c2c82ca44befe4570325dd6cf2ba885e0d90596c, reversing
changes made to e821dc0083003bc81058b1cb223d8a8a2ee44daf.

commit 9726421ff9efb2b19813b2fd6ad27a3728b5ab1a
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:59:00Z

  Revert  Revert  Merge remote-tracking branch 'professional/ignite-1.6.11'

commit 5a3a1960fff1dcf32961c45c0ba5149d6748d2fc
Author: Igor Sapego 
Date:   2016-11-08T14:36:35Z

Added license header.

commit f697fb5786fb4ce15f581c465ff0dcb3d2bb7b14
Author: Pavel Tupitsyn 
Date:   2016-11-08T16:13:48Z

IGNITE-4185 .NET: Fix NullReferenceException in IgniteOutputCacheProvider 
when igniteConfiguration is missing

[jira] [Commented] (IGNITE-3196) Marshaling works wrong for the BigDecimals that have negative scale

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3196:


Github user alamar closed the pull request at:

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


> Marshaling works wrong for the BigDecimals that have negative scale
> ---
>
> Key: IGNITE-3196
> URL: https://issues.apache.org/jira/browse/IGNITE-3196
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> Current marshalling procedure of the {{BigDecimal}} assumes that the scale of 
> the {{BigDecimal}} value is always more than or equal to zero. However, scale 
> [can be 
> negative|https://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#scale()].
> This leads to invalid results if we try to marshal-unmarshal {{BigDecimal}} 
> that has a negative scale.



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

[jira] [Commented] (IGNITE-3196) Marshaling works wrong for the BigDecimals that have negative scale

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3196:


Github user alamar closed the pull request at:

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


> Marshaling works wrong for the BigDecimals that have negative scale
> ---
>
> Key: IGNITE-3196
> URL: https://issues.apache.org/jira/browse/IGNITE-3196
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> Current marshalling procedure of the {{BigDecimal}} assumes that the scale of 
> the {{BigDecimal}} value is always more than or equal to zero. However, scale 
> [can be 
> negative|https://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#scale()].
> This leads to invalid results if we try to marshal-unmarshal {{BigDecimal}} 
> that has a negative scale.



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

[jira] [Commented] (IGNITE-3196) Marshaling works wrong for the BigDecimals that have negative scale

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3196:


GitHub user alamar opened a pull request:

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

Backport IGNITE-3196

 support for BigDecimals with negative scale in BinaryMarshaller

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

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

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

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


commit bb3ff120e6995431d10439243d8b163712de0e0e
Author: dkarachentsev 
Date:   2017-04-10T08:40:17Z

IGNITE-2466 - Disable back-pressure for sender data nodes to avoid deadlock.

(cherry picked from commit ba6227b)

commit 960e454b4b68c76ed94ca58a3ee9a9d8e79c2039
Author: dkarachentsev 
Date:   2017-04-10T07:28:15Z

IGNITE-2466 - Use current NIO back pressure mechanism to limit received 
messages. Mark them process only when backups acknowledged.

(cherry picked from commit 220db88)

commit 207ccaa1ff5a021a25dc779b5b2d7bfdb0f3b647
Author: dkarachentsev 
Date:   2017-04-10T08:40:17Z

IGNITE-2466 - Disable back-pressure for sender data nodes to avoid deadlock.

(cherry picked from commit ba6227b)

(cherry picked from commit bb3ff12)

commit 5fbbc37669bcf0557a98d8ab70c3dbb79ebcd340
Author: Andrey V. Mashenkov 
Date:   2017-04-05T12:01:02Z

IGNITE-4917: Fixed failure when accessing BinaryObjectBuilder field value 
serialized with OptimizedMarshaller . This closes #1736.

(cherry picked from commit b8e3d1b)

commit 315ff38eeef96f12954d6ff39c84d58b2b959667
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4879: Fixed System pool starvation while partition evicting.

commit 89e9dbe484312c251f02c9fbe9698c3ac2e03df8
Author: Alexander Fedotov 
Date:   2017-04-10T13:36:33Z

Fix org.apache.ignite.internal.processors.cache.expiry
.IgniteCacheExpiryPolicyAbstractTest#testNearExpiresWithCacheStore

commit 01ceeb13420b68edf12b0262fe0991e84c085dd8
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4863: Disallow change RootLogger log-level if it can have negative 
effect on other loggers. This closes #1687.

commit 02b194268071b179d291b28472cef5d587e7558a
Author: Alexander Fedotov 
Date:   2017-04-11T09:00:59Z

Fix missing test resource directory for
org.apache.ignite.spi.discovery.tcp
.TcpDiscoveryNodeAttributesUpdateOnReconnectTest.testReconnect

commit 20016a20f780eb3c21f249d3cb74d08018c4eea5
Author: Alexander Fedotov 
Date:   2017-04-11T11:54:06Z

Fix org.apache.ignite.internal.processors.cache.expiry
.IgniteCacheExpiryPolicyAbstractTest#testNearExpiresWithCacheStore

commit 6d12bd4b9fbded5e5862b5c3d89b05a5ddd11755
Author: Igor Sapego 
Date:   2017-03-21T14:54:51Z

IGNITE-4200: Added copying of the C++ binaries.

(cherry picked from commit 8b3860f)

commit 0f7ef74216fab64f5d1d2b6d432b552b7fe40d2f
Author: Andrey V. Mashenkov 
Date:   2017-04-12T10:01:25Z

IGNITE-4907: Fixed excessive service instances can be started with dynamic 
deployment. This closes #1766.

commit 465084da5b00dcfc056d338f5d0a24875ca2af08
Author: Andrey V. Mashenkov 
Date:   2017-04-12T10:01:25Z

IGNITE-4907: Fixed excessive service instances can be started with dynamic 
deployment. This closes #1766.

(cherry picked from commit 0f7ef74)

commit a20c307df1dd000309a273ef93231fdc41a2a81c
Author: dkarachentsev 
Date:   2017-04-13T06:31:17Z

IGNITE-4891 - Fix. Key is deserialized during transactional get() even if 
withKeepBinary is set

(Backport from master)

commit 630558dfeb373f237057e394e8f2f63230d59dab
Author: vladisav 
Date:   2017-04-13T10:24:42Z

ignite-4173 IgniteSemaphore with failoverSafe enabled doesn't release 
permits in case permits owner node left topology

Backport from master.

(cherry picked from commit 76485fc)

commit 870b752c095ed3776e91a65b99763142b9f2ebc0
Author: Vladisav Jelisavcic 
Date:   2017-04-11T11:09:12Z

ignite-1977 - fixed IgniteSemaphore fault tolerance.

Backport from master.

(cherry picked from commit 902bf42)

commit cd0b92950c6691c6fc1a26cb4f7e55f5ee459298
Author: Yakov 

[jira] [Commented] (IGNITE-3196) Marshaling works wrong for the BigDecimals that have negative scale

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3196:


GitHub user alamar opened a pull request:

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

Backport IGNITE-3196

Add support for BigDecimals with negative scale in BinaryMarshaller

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

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

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

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


commit a62a0136d295486d95c6e2ab5bba88270d831753
Author: dkarachentsev 
Date:   2016-11-02T16:07:45Z

GG-11655 - Fix merge

commit 348593986b56ddfcec4a4455e49d9b279eae4dc8
Author: devozerov 
Date:   2016-11-05T10:28:03Z

Merge branch 'ignite-1.7.3' into ignite-1.7.4

commit 175da6b7e394dd76c27d5155ff98a5b2ef03bb9d
Author: tledkov-gridgain 
Date:   2016-11-07T06:16:58Z

IGNITE-3432:  check data/meta cache names are different for different IGFS 
instances. This closes #1201

commit ead15193899d08f41491166003cabed0560f0c59
Author: Pavel Tupitsyn 
Date:   2016-11-07T07:49:03Z

IGNITE-4028 Get rid of OP_META in PlatformAbstractTarget

This closes #1192

commit 40ef2f5ae42826fe8fd077e3013e8f55c8512bdd
Author: Dmitriy Govorukhin 
Date:   2016-11-07T09:09:41Z

ignite-4178 support permission builder

commit df670c7d64046d282c053f296c47a4743c58c8b1
Author: Pavel Tupitsyn 
Date:   2016-11-07T09:40:00Z

IGNITE-4118 .NET: Optimistic transaction example

This closes #1200

commit 474f22fda4c7cf4d7b2623c451cd7c10f0d8c636
Author: Pavel Tupitsyn 
Date:   2016-11-07T09:55:20Z

IGNITE-4119 .NET: add TransactionDeadlockException

commit fc7ce5a4d72145f2e8a86debeda264ef0a5b37e3
Author: isapego 
Date:   2016-11-07T10:26:05Z

IGNITE-4090: Added flags so stdint and limits can be used in C++.

commit a98804a249496ba9bafbc96daa7aaf25b3d36724
Author: Igor Sapego 
Date:   2016-11-07T11:00:00Z

IGNITE-4113: Added tests. Added Statement::Set/GetAttribute.

commit b1c7c9bb95c900083702d0ba0362edf3aea5a7b4
Author: sboikov 
Date:   2016-11-07T12:40:36Z

GG-11360 - Implement SQL queries cancellation
Fix for commit 80abd1b: for distributed joins need always send cancel 
request.

commit 319014de075c80fb15e58172cc24e35ce16b56cf
Author: Pavel Tupitsyn 
Date:   2016-11-07T14:53:40Z

IGNITE-4132 .NET: Improve BinaryConfiguration documentation

commit 950bad474ef29f9b808e74034c49a69d57eb2740
Author: dkarachentsev 
Date:   2016-11-08T11:03:34Z

GG-11655 - Restore service compatibility with releases before 1.5.30.

commit 3d19bfc2b66574e3945ce17c7a4dfe77d0070b8d
Author: dkarachentsev 
Date:   2016-11-08T11:04:36Z

Merge remote-tracking branch 'origin/ignite-1.6.11' into ignite-1.6.11

commit 1612b6d66fed032182a41e90da71e6b986ae087b
Author: Pavel Tupitsyn 
Date:   2016-11-08T11:07:54Z

.NET: Fix minor analysis warnings

commit e821dc0083003bc81058b1cb223d8a8a2ee44daf
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:09:21Z

IGNITE-2079 (revert commit) GridCacheIoManager eats exception trail if it 
falls into the directed case

commit c2c82ca44befe4570325dd6cf2ba885e0d90596c
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:10:10Z

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

commit 865bbcf0f41a0c4944e0928f1758d43a0eae82c5
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:18:29Z

Revert "Merge remote-tracking branch 'professional/ignite-1.6.11' into 
ignite-1.6.11"

This reverts commit c2c82ca44befe4570325dd6cf2ba885e0d90596c, reversing
changes made to e821dc0083003bc81058b1cb223d8a8a2ee44daf.

commit 9726421ff9efb2b19813b2fd6ad27a3728b5ab1a
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:59:00Z

  Revert  Revert  Merge remote-tracking branch 'professional/ignite-1.6.11'

commit 5a3a1960fff1dcf32961c45c0ba5149d6748d2fc
Author: Igor Sapego 
Date:   2016-11-08T14:36:35Z

Added license header.

commit f697fb5786fb4ce15f581c465ff0dcb3d2bb7b14
Author: Pavel Tupitsyn 
Date:   2016-11-08T16:13:48Z

IGNITE-4185 .NET: Fix NullReferenceException in IgniteOutputCacheProvider 
when igniteConfiguration is missing

[jira] [Commented] (IGNITE-4643) JdbcDatabaseMetadata.getIndexInfo() method not working

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-4643:
-

2.1. I'll take a look whether it's a safe thing to do.
2.3. Might cause existing clients to fail (a potentially breaking API change) - 
scared to do that one.
2.4. I think we can go without uppercasing results output, but removing 
case-insensitive matching arguments is again a breaking change that's I'm 
afraid to do.

> JdbcDatabaseMetadata.getIndexInfo() method not working
> --
>
> Key: IGNITE-4643
> URL: https://issues.apache.org/jira/browse/IGNITE-4643
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> {{JdbcDatabaseMetadata.getIndexInfo()}} method does not update metadata 
> before creating result set. So if it's a first method invocation on this 
> instance of {{JdbcDatabaseMetadata}}, it fails with NPE. Need to create tests 
> and add {{updateMetaData()}} call in the beginning of the method.



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

[jira] [Commented] (IGNITE-4643) JdbcDatabaseMetadata.getIndexInfo() method not working

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4643:
--

[~ilyak], looks good. My comments:
1. Code style: if / for braces for multi-line statements.
2. I think we have to create separate ticket to enhance DatabaseMetadata for 
jdbc2 (or fix the comments below in this ticket):
2.1. Works with schema name is invalid. {{cacheName != schemaName}}. see 
{{JdbcRequestHandler#getSchemas}}
2.3. {{calatog}} parameter is ignored in all method. An empty results must be 
returned when non=empty catalog argument is passed.
2.4. Uppercase mustn't use on match & results output.

> JdbcDatabaseMetadata.getIndexInfo() method not working
> --
>
> Key: IGNITE-4643
> URL: https://issues.apache.org/jira/browse/IGNITE-4643
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> {{JdbcDatabaseMetadata.getIndexInfo()}} method does not update metadata 
> before creating result set. So if it's a first method invocation on this 
> instance of {{JdbcDatabaseMetadata}}, it fails with NPE. Need to create tests 
> and add {{updateMetaData()}} call in the beginning of the method.



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

[jira] [Created] (IGNITE-6112) Review and update C++ documentation according to new features.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-6112:
---

 Summary: Review and update C++ documentation according to new 
features.
 Key: IGNITE-6112
 URL: https://issues.apache.org/jira/browse/IGNITE-6112
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.1
Reporter: Igor Sapego
Assignee: Igor Sapego


It is needed to spend some time walking through the doc and updating it 
considering the latest features and changes 
https://apacheignite.readme.io/docs/quering-data 

For instance:

1. The configuration section [1] can be switched to the usage of DDL statements 
for tables creation and indexes definition.

2. Information about "_key" and "_value" should be wiped out because presently 
there is a way to set unique names for the whole key and value.



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

[jira] [Commented] (IGNITE-5925) Get row/col for matrices

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5925:


Github user ybabak closed the pull request at:

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


> Get row/col for matrices
> 
>
> Key: IGNITE-5925
> URL: https://issues.apache.org/jira/browse/IGNITE-5925
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> It should be useful to have this api for any matrix especially in BLAS and 
> decompositions.



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

[jira] [Commented] (IGNITE-5925) Get row/col for matrices

[Artem Malykh (JIRA)]

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

Artem Malykh commented on IGNITE-5925:
--

[~chief] Looks good for me

> Get row/col for matrices
> 
>
> Key: IGNITE-5925
> URL: https://issues.apache.org/jira/browse/IGNITE-5925
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> It should be useful to have this api for any matrix especially in BLAS and 
> decompositions.



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

[jira] [Commented] (IGNITE-5925) Get row/col for matrices

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5925:


[~amalykh] Please take a look.

> Get row/col for matrices
> 
>
> Key: IGNITE-5925
> URL: https://issues.apache.org/jira/browse/IGNITE-5925
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> It should be useful to have this api for any matrix especially in BLAS and 
> decompositions.



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

[jira] [Assigned] (IGNITE-5869) Unexpected timeout exception while client connected with different BinaryConfiguration compactFooter param.

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny reassigned IGNITE-5869:
--

Assignee: Vladimir Ozerov  (was: Stanilovsky Evgeny)

> Unexpected timeout exception while client connected with different 
> BinaryConfiguration compactFooter param.
> ---
>
> Key: IGNITE-5869
> URL: https://issues.apache.org/jira/browse/IGNITE-5869
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Assignee: Vladimir Ozerov
> Attachments: TcpClientDiscoveryMarshallerCheckSelfTest.java
>
>
> While client connecting with different from cluster 
> BinaryConfiguration::setCompactFooter param, instead of expecting: 
> "configuration is not equal" exception catch: Join process timed out 
> exception.



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

[jira] [Commented] (IGNITE-5869) Unexpected timeout exception while client connected with different BinaryConfiguration compactFooter param.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5869:


GitHub user zstan opened a pull request:

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

IGNITE-5869 client hangs infinitely while binary configuration differs from 
server



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

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

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

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


commit 4de9de484dc595e816f8024b18c2988d5bd03983
Author: Evgeny Stanilovskiy 
Date:   2017-08-18T12:23:42Z

IGNITE-5869 client hangs infinitely while binary configuration differs from 
server




> Unexpected timeout exception while client connected with different 
> BinaryConfiguration compactFooter param.
> ---
>
> Key: IGNITE-5869
> URL: https://issues.apache.org/jira/browse/IGNITE-5869
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
> Attachments: TcpClientDiscoveryMarshallerCheckSelfTest.java
>
>
> While client connecting with different from cluster 
> BinaryConfiguration::setCompactFooter param, instead of expecting: 
> "configuration is not equal" exception catch: Join process timed out 
> exception.



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

[jira] [Commented] (IGNITE-4643) JdbcDatabaseMetadata.getIndexInfo() method not working

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-4643:
-

https://reviews.ignite.apache.org/ignite/branch/PR%202481

Also ported several tests from Thin driver implementation.
Fixed a problem in Primary Keys metadata.
Fixed several get*Version() methods to return Ignite version/JDBC 4.1 
instead of dummy values.


> JdbcDatabaseMetadata.getIndexInfo() method not working
> --
>
> Key: IGNITE-4643
> URL: https://issues.apache.org/jira/browse/IGNITE-4643
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> {{JdbcDatabaseMetadata.getIndexInfo()}} method does not update metadata 
> before creating result set. So if it's a first method invocation on this 
> instance of {{JdbcDatabaseMetadata}}, it fails with NPE. Need to create tests 
> and add {{updateMetaData()}} call in the beginning of the method.



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

[jira] [Closed] (IGNITE-6107) GridFunc.first(list) throws NPE for null arg, but GridFunc.first(iterable) returns null

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-6107.


Merged to master.

> GridFunc.first(list) throws NPE for null arg, but GridFunc.first(iterable) 
> returns null
> ---
>
> Key: IGNITE-6107
> URL: https://issues.apache.org/jira/browse/IGNITE-6107
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>
> GridFunc.first(list) should return null in case of null argument.



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

[jira] [Updated] (IGNITE-6081) .NET: Cannot get from cache values which were stored in cache with PutAll.

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-6081:
-
Fix Version/s: 2.2

> .NET: Cannot get from cache values which were stored in cache with PutAll.
> --
>
> Key: IGNITE-6081
> URL: https://issues.apache.org/jira/browse/IGNITE-6081
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.2
>
>
> If you try to put multiple non-primitive values with dictionary property to 
> cache using {{PutAll}}, you'd get an exception on attempt to read those 
> values. Code example below:
> {code}
> var entries = new Dictionary();
> for (int i = 0; i < 100; i++)
> entries.Add(i, new SomeType { Id = i });
> var cache = Ignition.GetIgnite().GetCache("CacheName");
> cache.PutAll(entries);
> cache.Get(42);
> {code}
> Pay attention, that {{SomeType}} should have dictionary property.



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

[jira] [Commented] (IGNITE-4643) JdbcDatabaseMetadata.getIndexInfo() method not working

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4643:


GitHub user alamar opened a pull request:

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

IGNITE-4643 Fix NPE in getIndexInfo() with test

Also ported several tests from Thin driver implementation.
Fixed a problem in Primary Keys metadata.
Fixed several get*Version() methods to return Ignite version/JDBC 4.1 
instead of dummy values.

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

$ git pull https://github.com/alamar/ignite ignite-4643

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

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


commit f3bf90943ce9a613296929d8050c55aa0cdc88b0
Author: Ilya Kasnacheev 
Date:   2017-08-18T11:40:42Z

IGNITE-4643 Fix NPE in getIndexInfo() with test

Also ported several tests from Thin driver implementation.
Fixed a problem in Primary Keys metadata.
Fixed several get*Version() methods to return Ignite version/JDBC 4.1 
instead of dummy values.




> JdbcDatabaseMetadata.getIndexInfo() method not working
> --
>
> Key: IGNITE-4643
> URL: https://issues.apache.org/jira/browse/IGNITE-4643
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> {{JdbcDatabaseMetadata.getIndexInfo()}} method does not update metadata 
> before creating result set. So if it's a first method invocation on this 
> instance of {{JdbcDatabaseMetadata}}, it fails with NPE. Need to create tests 
> and add {{updateMetaData()}} call in the beginning of the method.



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

[jira] [Commented] (IGNITE-5860) Client disconnects if server it is connected to goes unresponsive

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5860:


GitHub user dmekhanikov opened a pull request:

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

IGNITE-5860 make client reconnect on router's suspend

Created for testing

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

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

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

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


commit ba6227be49c8a395a5632e9841a6acb65ae340b6
Author: dkarachentsev 
Date:   2017-04-10T08:40:17Z

IGNITE-2466 - Disable back-pressure for sender data nodes to avoid deadlock.

commit bb3ff120e6995431d10439243d8b163712de0e0e
Author: dkarachentsev 
Date:   2017-04-10T08:40:17Z

IGNITE-2466 - Disable back-pressure for sender data nodes to avoid deadlock.

(cherry picked from commit ba6227b)

commit 960e454b4b68c76ed94ca58a3ee9a9d8e79c2039
Author: dkarachentsev 
Date:   2017-04-10T07:28:15Z

IGNITE-2466 - Use current NIO back pressure mechanism to limit received 
messages. Mark them process only when backups acknowledged.

(cherry picked from commit 220db88)

commit 207ccaa1ff5a021a25dc779b5b2d7bfdb0f3b647
Author: dkarachentsev 
Date:   2017-04-10T08:40:17Z

IGNITE-2466 - Disable back-pressure for sender data nodes to avoid deadlock.

(cherry picked from commit ba6227b)

(cherry picked from commit bb3ff12)

commit 5fbbc37669bcf0557a98d8ab70c3dbb79ebcd340
Author: Andrey V. Mashenkov 
Date:   2017-04-05T12:01:02Z

IGNITE-4917: Fixed failure when accessing BinaryObjectBuilder field value 
serialized with OptimizedMarshaller . This closes #1736.

(cherry picked from commit b8e3d1b)

commit 315ff38eeef96f12954d6ff39c84d58b2b959667
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4879: Fixed System pool starvation while partition evicting.

commit 89e9dbe484312c251f02c9fbe9698c3ac2e03df8
Author: Alexander Fedotov 
Date:   2017-04-10T13:36:33Z

Fix org.apache.ignite.internal.processors.cache.expiry
.IgniteCacheExpiryPolicyAbstractTest#testNearExpiresWithCacheStore

commit 01ceeb13420b68edf12b0262fe0991e84c085dd8
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4863: Disallow change RootLogger log-level if it can have negative 
effect on other loggers. This closes #1687.

commit 02b194268071b179d291b28472cef5d587e7558a
Author: Alexander Fedotov 
Date:   2017-04-11T09:00:59Z

Fix missing test resource directory for
org.apache.ignite.spi.discovery.tcp
.TcpDiscoveryNodeAttributesUpdateOnReconnectTest.testReconnect

commit 20016a20f780eb3c21f249d3cb74d08018c4eea5
Author: Alexander Fedotov 
Date:   2017-04-11T11:54:06Z

Fix org.apache.ignite.internal.processors.cache.expiry
.IgniteCacheExpiryPolicyAbstractTest#testNearExpiresWithCacheStore

commit 6d12bd4b9fbded5e5862b5c3d89b05a5ddd11755
Author: Igor Sapego 
Date:   2017-03-21T14:54:51Z

IGNITE-4200: Added copying of the C++ binaries.

(cherry picked from commit 8b3860f)

commit 0f7ef74216fab64f5d1d2b6d432b552b7fe40d2f
Author: Andrey V. Mashenkov 
Date:   2017-04-12T10:01:25Z

IGNITE-4907: Fixed excessive service instances can be started with dynamic 
deployment. This closes #1766.

commit 465084da5b00dcfc056d338f5d0a24875ca2af08
Author: Andrey V. Mashenkov 
Date:   2017-04-12T10:01:25Z

IGNITE-4907: Fixed excessive service instances can be started with dynamic 
deployment. This closes #1766.

(cherry picked from commit 0f7ef74)

commit a20c307df1dd000309a273ef93231fdc41a2a81c
Author: dkarachentsev 
Date:   2017-04-13T06:31:17Z

IGNITE-4891 - Fix. Key is deserialized during transactional get() even if 
withKeepBinary is set

(Backport from master)

commit 630558dfeb373f237057e394e8f2f63230d59dab
Author: vladisav 
Date:   2017-04-13T10:24:42Z

ignite-4173 IgniteSemaphore with failoverSafe enabled doesn't release 
permits in case permits owner node left topology

Backport from master.

(cherry picked from commit 76485fc)

commit 870b752c095ed3776e91a65b99763142b9f2ebc0
Author: Vladisav Jelisavcic 
Date:   

[jira] [Commented] (IGNITE-6101) Try to improve local scans performance

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6101:


GitHub user gvvinblade opened a pull request:

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

IGNITE-6101



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

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

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

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


commit 71b887a7ea8e4b778eb53193b79202fed77a16f7
Author: Igor Seliverstov 
Date:   2017-08-18T11:36:44Z

IGNITE-6101 Try to improve local scans performance




> Try to improve local scans performance
> --
>
> Key: IGNITE-6101
> URL: https://issues.apache.org/jira/browse/IGNITE-6101
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>  Labels: performance
>
> Cutently local scan queries at least two times slower than direct iteration 
> over partition (using BTree cursor). Check if it's possible to decrease the 
> speed difference.



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

[jira] [Commented] (IGNITE-6088) Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on SSLSocket

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6088:
--

[~ezhuravl],
Thank you for your contribution! It looks good for me.

> Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on 
> SSLSocket
> ---
>
> Key: IGNITE-6088
> URL: https://issues.apache.org/jira/browse/IGNITE-6088
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.2
>
>
> UnsupportedOperationException: The method shutdownOutput() is not supported 
> in SSLSocket 



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

[jira] [Updated] (IGNITE-6099) ODBC: Implement SQLGetInfo for all info types

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6099:

Description: Currently not all the info types supported for {{SQLGetInfo}}. 
Need to implement fully. Details can be found here - 
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetinfo-function  
(was: Currently not all the info types supported for {{SQLGetInfo}}. Need to 
implement fully.)

> ODBC: Implement SQLGetInfo for all info types
> -
>
> Key: IGNITE-6099
> URL: https://issues.apache.org/jira/browse/IGNITE-6099
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently not all the info types supported for {{SQLGetInfo}}. Need to 
> implement fully. Details can be found here - 
> https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetinfo-function



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

[jira] [Commented] (IGNITE-5925) Get row/col for matrices

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5925:


GitHub user ybabak opened a pull request:

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

IGNITE-5925: Get row/col for matrices



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

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

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

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


commit 227e1315e0739ab71c83c9889c67e616a997a34b
Author: Yury Babak 
Date:   2017-08-14T17:08:15Z

IGNITE-5925: Get row/col for matrices
WIP

commit 49e5846469d73e356a960e8a26fac82508fc10d1
Author: Yury Babak 
Date:   2017-08-18T10:24:25Z

IGNITE-5925: Get row/col for matrices
- implemented




> Get row/col for matrices
> 
>
> Key: IGNITE-5925
> URL: https://issues.apache.org/jira/browse/IGNITE-5925
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> It should be useful to have this api for any matrix especially in BLAS and 
> decompositions.



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

[jira] [Updated] (IGNITE-6111) SQL: Add ability to do INSERT without specifying the column names

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-6111:
-
Labels: sql  (was: )

> SQL: Add ability to do INSERT without specifying the column names
> -
>
> Key: IGNITE-6111
> URL: https://issues.apache.org/jira/browse/IGNITE-6111
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>  Labels: sql
> Fix For: 2.2
>
>
> Having the following classes
> {code:java}
> class PersonKey {
> private Long id;
> }
> class Person {
> private Long id;
> private String name;
> }
> {code}
> with proper configuration it should be possible to execute queries 
> of the following type passing {{id}} and {{name}} as the arguments
> {code:sql}"insert into Person values(?,?)"{code}



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

[jira] [Created] (IGNITE-6111) SQL: Add ability to do INSERT without specifying the column names

[Alexandr Fedotov (JIRA)]

Alexandr Fedotov created IGNITE-6111:


 Summary: SQL: Add ability to do INSERT without specifying the 
column names
 Key: IGNITE-6111
 URL: https://issues.apache.org/jira/browse/IGNITE-6111
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.1
Reporter: Alexandr Fedotov
 Fix For: 2.2


Having the following classes
{code:java}
class PersonKey {
private Long id;
}

class Person {
private Long id;
private String name;
}
{code}
with proper configuration it should be possible to execute queries 
of the following type passing {{id}} and {{name}} as the arguments
{code:sql}"insert into Person values(?,?)"{code}




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

[jira] [Resolved] (IGNITE-6110) CLONE - SQL: Add ability to do INSERT without specifying the column names

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov resolved IGNITE-6110.
--
Resolution: Duplicate

> CLONE - SQL: Add ability to do INSERT without specifying the column names
> -
>
> Key: IGNITE-6110
> URL: https://issues.apache.org/jira/browse/IGNITE-6110
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexandr Fedotov
>
> Having the following classes
> {code:java}
> class PersonKey {
> private Long id;
> }
> class Person {
> private Long id;
> private String name;
> }
> {code}
> with proper configuration it should be possible to execute queries 
> of the following type passing {{id}} and {{name}} as the arguments
> {code:sql}"insert into Person values(?,?)"{code}



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

[jira] [Resolved] (IGNITE-6109) SQL: Add ability to do INSERT without specifying the column names

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov resolved IGNITE-6109.
--
Resolution: Invalid

> SQL: Add ability to do INSERT without specifying the column names
> -
>
> Key: IGNITE-6109
> URL: https://issues.apache.org/jira/browse/IGNITE-6109
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexandr Fedotov
>
> Having the following classes
> {code:java}
> class PersonKey {
> private Long id;
> }
> class Person {
> private Long id;
> private String name;
> }
> {code}
> with proper configuration it should be possible to execute queries 
> of the following type passing {{id}} and {{name}} as the arguments
> {code:sql}"insert into Person values(?,?)"{code}



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

[jira] [Updated] (IGNITE-6109) SQL: Add ability to do INSERT without specifying the column names

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-6109:
-
Affects Version/s: (was: 2.1)
   Labels:   (was: sql)
Fix Version/s: (was: 2.2)
  Component/s: (was: sql)

> SQL: Add ability to do INSERT without specifying the column names
> -
>
> Key: IGNITE-6109
> URL: https://issues.apache.org/jira/browse/IGNITE-6109
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexandr Fedotov
>
> Having the following classes
> {code:java}
> class PersonKey {
> private Long id;
> }
> class Person {
> private Long id;
> private String name;
> }
> {code}
> with proper configuration it should be possible to execute queries 
> of the following type passing {{id}} and {{name}} as the arguments
> {code:sql}"insert into Person values(?,?)"{code}



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

[jira] [Updated] (IGNITE-6110) CLONE - SQL: Add ability to do INSERT without specifying the column names

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-6110:
-
   Labels:   (was: sql)
Fix Version/s: (was: 2.2)
  Component/s: (was: sql)

> CLONE - SQL: Add ability to do INSERT without specifying the column names
> -
>
> Key: IGNITE-6110
> URL: https://issues.apache.org/jira/browse/IGNITE-6110
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexandr Fedotov
>
> Having the following classes
> {code:java}
> class PersonKey {
> private Long id;
> }
> class Person {
> private Long id;
> private String name;
> }
> {code}
> with proper configuration it should be possible to execute queries 
> of the following type passing {{id}} and {{name}} as the arguments
> {code:sql}"insert into Person values(?,?)"{code}



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

[jira] [Updated] (IGNITE-6110) CLONE - SQL: Add ability to do INSERT without specifying the column names

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-6110:
-
Affects Version/s: (was: 2.1)

> CLONE - SQL: Add ability to do INSERT without specifying the column names
> -
>
> Key: IGNITE-6110
> URL: https://issues.apache.org/jira/browse/IGNITE-6110
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Alexandr Fedotov
>  Labels: sql
> Fix For: 2.2
>
>
> Having the following classes
> {code:java}
> class PersonKey {
> private Long id;
> }
> class Person {
> private Long id;
> private String name;
> }
> {code}
> with proper configuration it should be possible to execute queries 
> of the following type passing {{id}} and {{name}} as the arguments
> {code:sql}"insert into Person values(?,?)"{code}



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

[jira] [Created] (IGNITE-6110) CLONE - SQL: Add ability to do INSERT without specifying the column names

[Alexandr Fedotov (JIRA)]

Alexandr Fedotov created IGNITE-6110:


 Summary: CLONE - SQL: Add ability to do INSERT without specifying 
the column names
 Key: IGNITE-6110
 URL: https://issues.apache.org/jira/browse/IGNITE-6110
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.1
Reporter: Alexandr Fedotov
 Fix For: 2.2


Having the following classes
{code:java}
class PersonKey {
private Long id;
}

class Person {
private Long id;
private String name;
}
{code}
with proper configuration it should be possible to execute queries 
of the following type passing {{id}} and {{name}} as the arguments
{code:sql}"insert into Person values(?,?)"{code}




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

[jira] [Updated] (IGNITE-6109) SQL: Add ability to do INSERT without specifying the column names

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-6109:
-
External issue URL:   (was: 
https://gridgain.freshdesk.com/helpdesk/tickets/3738)

> SQL: Add ability to do INSERT without specifying the column names
> -
>
> Key: IGNITE-6109
> URL: https://issues.apache.org/jira/browse/IGNITE-6109
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>  Labels: sql
> Fix For: 2.2
>
>
> Having the following classes
> {code:java}
> class PersonKey {
> private Long id;
> }
> class Person {
> private Long id;
> private String name;
> }
> {code}
> with proper configuration it should be possible to execute queries 
> of the following type passing {{id}} and {{name}} as the arguments
> {code:sql}"insert into Person values(?,?)"{code}



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

[jira] [Assigned] (IGNITE-6106) Web console: New function descriptions on homepage carousel and getting started dialog

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6106:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

> Web console: New function descriptions on homepage carousel and getting 
> started dialog
> --
>
> Key: IGNITE-6106
> URL: https://issues.apache.org/jira/browse/IGNITE-6106
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.2
>
>




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

[jira] [Created] (IGNITE-6109) SQL: Add ability to do INSERT without specifying the column names

[Alexandr Fedotov (JIRA)]

Alexandr Fedotov created IGNITE-6109:


 Summary: SQL: Add ability to do INSERT without specifying the 
column names
 Key: IGNITE-6109
 URL: https://issues.apache.org/jira/browse/IGNITE-6109
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.1
Reporter: Alexandr Fedotov
 Fix For: 2.2


Having the following classes
{code:java}
class PersonKey {
private Long id;
}

class Person {
private Long id;
private String name;
}
{code}
with proper configuration it should be possible to execute queries 
of the following type passing {{id}} and {{name}} as the arguments
{code:sql}"insert into Person values(?,?)"{code}




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

[jira] [Updated] (IGNITE-6108) Hangs in streamer when using store

[Aleksey Chetaev (JIRA)]

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

Aleksey Chetaev updated IGNITE-6108:

Description: 
I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
different from NONE. 
Configuration: 1 client 4 servers.Cache mode:  transaction. Range 400_000_000. 
Problems: 
* Time for next 100_000_000 entries every is always greater than for the 
previous one.
* We can found hangs for greater that 1 minutes in drivers logs for example 
11:47:21 - 11:48:27 in archive named "log_with_memory_policy".

Time for every 100_000_000 in seconds in log named "logs_without 
memory_policy". 
* 100_000_000 = 209
* 200_000_000 = 323
* 300_000_000 = 547
* 400_000_000 = 722

Yardstick logs in attachments. 

  was:
I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
different from NONE. 
Configuration: 1 client 4 servers.Cache mode:  transaction. Range 400_000_000. 
Problems: 
* Time for next 100_000_000 entries every is always greater than for the 
previous one.
* We can found hangs for greater that 1 minutes in drivers logs for example 
11:47:21 - 11:48:27 in archive named "log_with_memory_policy".

Time for every 100_000_000 in seconds in log named: 
* 100_000_000 = 209
* 200_000_000 = 323
* 300_000_000 = 547
* 400_000_000 = 722

Yardstick logs in attachments. 


> Hangs in streamer when using store
> --
>
> Key: IGNITE-6108
> URL: https://issues.apache.org/jira/browse/IGNITE-6108
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Aleksey Chetaev
>Priority: Critical
> Attachments: logs_without memory_policy.zip, 
> log_with_memory_policy.zip
>
>
> I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
> different from NONE. 
> Configuration: 1 client 4 servers.Cache mode:  transaction. Range 
> 400_000_000. 
> Problems: 
> * Time for next 100_000_000 entries every is always greater than for the 
> previous one.
> * We can found hangs for greater that 1 minutes in drivers logs for example 
> 11:47:21 - 11:48:27 in archive named "log_with_memory_policy".
> Time for every 100_000_000 in seconds in log named "logs_without 
> memory_policy". 
> * 100_000_000 = 209
> * 200_000_000 = 323
> * 300_000_000 = 547
> * 400_000_000 = 722
> Yardstick logs in attachments. 



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

[jira] [Updated] (IGNITE-6108) Hangs in streamer when using store

[Aleksey Chetaev (JIRA)]

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

Aleksey Chetaev updated IGNITE-6108:

Description: 
I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
different from NONE. 
Configuration: 1 client 4 servers.Cache mode:  transaction. Range 400_000_000. 
Problems: 
* Time for next 100_000_000 entries every is always greater than for the 
previous one.
* We can found hangs for greater that 1 minutes in drivers logs. E.x. 11:47:21 
- 11:48:27 in archive named "log_with_memory_policy".

Time for every 100_000_000 in seconds in log named "logs_without 
memory_policy". 
* 100_000_000 = 209
* 200_000_000 = 323
* 300_000_000 = 547
* 400_000_000 = 722

Yardstick logs in attachments. 

  was:
I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
different from NONE. 
Configuration: 1 client 4 servers.Cache mode:  transaction. Range 400_000_000. 
Problems: 
* Time for next 100_000_000 entries every is always greater than for the 
previous one.
* We can found hangs for greater that 1 minutes in drivers logs for example 
11:47:21 - 11:48:27 in archive named "log_with_memory_policy".

Time for every 100_000_000 in seconds in log named "logs_without 
memory_policy". 
* 100_000_000 = 209
* 200_000_000 = 323
* 300_000_000 = 547
* 400_000_000 = 722

Yardstick logs in attachments. 


> Hangs in streamer when using store
> --
>
> Key: IGNITE-6108
> URL: https://issues.apache.org/jira/browse/IGNITE-6108
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Aleksey Chetaev
>Priority: Critical
> Attachments: logs_without memory_policy.zip, 
> log_with_memory_policy.zip
>
>
> I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
> different from NONE. 
> Configuration: 1 client 4 servers.Cache mode:  transaction. Range 
> 400_000_000. 
> Problems: 
> * Time for next 100_000_000 entries every is always greater than for the 
> previous one.
> * We can found hangs for greater that 1 minutes in drivers logs. E.x. 
> 11:47:21 - 11:48:27 in archive named "log_with_memory_policy".
> Time for every 100_000_000 in seconds in log named "logs_without 
> memory_policy". 
> * 100_000_000 = 209
> * 200_000_000 = 323
> * 300_000_000 = 547
> * 400_000_000 = 722
> Yardstick logs in attachments. 



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

[jira] [Updated] (IGNITE-6108) Hangs in streamer when using store

[Aleksey Chetaev (JIRA)]

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

Aleksey Chetaev updated IGNITE-6108:

Description: 
I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
different from NONE. 
Configuration: 1 client 4 servers.Cache mode:  transaction. Range 400_000_000. 
Problems: 
* Time for next 100_000_000 entries every is always greater than for the 
previous one.
* We can found hangs for greater that 1 minutes in drivers logs for example 
11:47:21 - 11:48:27 in archive named "log_with_memory_policy".

Time for every 100_000_000 in seconds in log named: 
* 100_000_000 = 209
* 200_000_000 = 323
* 300_000_000 = 547
* 400_000_000 = 722

Yardstick logs in attachments. 

  was:
I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
different from NONE. 
Configuration: 1 client 4 servers.Cache mode:  transaction. Range 400_000_000. 
Problems: 
* Time for next 100_000_000 entries every is always greater than for the 
previous one.
* We can found hangs for greater that 1 minutes in drivers logs for example 
11:47:21 - 11:48:27 in archive named "log_with_memory_policy".

Yardstick logs in attachments. 


> Hangs in streamer when using store
> --
>
> Key: IGNITE-6108
> URL: https://issues.apache.org/jira/browse/IGNITE-6108
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Aleksey Chetaev
>Priority: Critical
> Attachments: logs_without memory_policy.zip, 
> log_with_memory_policy.zip
>
>
> I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
> different from NONE. 
> Configuration: 1 client 4 servers.Cache mode:  transaction. Range 
> 400_000_000. 
> Problems: 
> * Time for next 100_000_000 entries every is always greater than for the 
> previous one.
> * We can found hangs for greater that 1 minutes in drivers logs for example 
> 11:47:21 - 11:48:27 in archive named "log_with_memory_policy".
> Time for every 100_000_000 in seconds in log named: 
> * 100_000_000 = 209
> * 200_000_000 = 323
> * 300_000_000 = 547
> * 400_000_000 = 722
> Yardstick logs in attachments. 



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

[jira] [Comment Edited] (IGNITE-5355) Create task with release tools

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-5355 at 8/18/17 9:31 AM:
---

[~lexa],
Thank you for your contribution! I've reviewed changes and have some minor 
comments:
* Can you to make sure that org.json.json:20170516 dependency compatible with 
apache license?
* Some minor code style issues (space, name convention and etc);
* Use StringBuilder instead of simple string concatenation in loop;
* Is it possible to add test on this tool?


was (Author: ntikhonov):
[~lexa],
Thank you for your contribution! I've reviewed changes and have some minor 
comments:
* Can you to make sure that org.json.json:20170516 dependency compatible with 
apache license?
* Some minor code style issues (space, name convention and etc);
* Use StringBuilder instead of simple string concatenation in loop.

> Create task with release tools
> --
>
> Key: IGNITE-5355
> URL: https://issues.apache.org/jira/browse/IGNITE-5355
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Aleksey Chetaev
>Assignee: Aleksey Chetaev
>
> 1. Create task for auto-generate HTML formatted releases notes



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

[jira] [Commented] (IGNITE-5355) Create task with release tools

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-5355:
--

[~lexa],
Thank you for your contribution! I've reviewed changes and have some minor 
comments:
* Can you to make sure that org.json.json:20170516 dependency compatible with 
apache license?
* Some minor code style issues (space, name convention and etc);
* Use StringBuilder instead of simple string concatenation in loop.

> Create task with release tools
> --
>
> Key: IGNITE-5355
> URL: https://issues.apache.org/jira/browse/IGNITE-5355
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Aleksey Chetaev
>Assignee: Aleksey Chetaev
>
> 1. Create task for auto-generate HTML formatted releases notes



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

[jira] [Updated] (IGNITE-6108) Hangs in streamer when using store

[Aleksey Chetaev (JIRA)]

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

Aleksey Chetaev updated IGNITE-6108:

Attachment: log_with_memory_policy.zip
logs_without memory_policy.zip

> Hangs in streamer when using store
> --
>
> Key: IGNITE-6108
> URL: https://issues.apache.org/jira/browse/IGNITE-6108
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Aleksey Chetaev
>Priority: Critical
> Attachments: logs_without memory_policy.zip, 
> log_with_memory_policy.zip
>
>
> I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
> different from NONE. 
> Configuration: 1 client 4 servers.Cache mode:  transaction. Range 
> 400_000_000. 
> Problems: 
> * Time for next 100_000_000 entries every is always greater than for the 
> previous one.
> * We can found hangs for greater that 1 minutes in drivers logs for example 
> 11:47:21 - 11:48:27 in archive named "log_with_memory_policy".
> Yardstick logs in attachments. 



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

[jira] [Created] (IGNITE-6108) Hangs in streamer when using store

[Aleksey Chetaev (JIRA)]

Aleksey Chetaev created IGNITE-6108:
---

 Summary: Hangs in streamer when using store
 Key: IGNITE-6108
 URL: https://issues.apache.org/jira/browse/IGNITE-6108
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Aleksey Chetaev
Priority: Critical


I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
different from NONE. 
Configuration: 1 client 4 servers.Cache mode:  transaction. Range 400_000_000. 
Problems: 
* Time for next 100_000_000 entries every is always greater than for the 
previous one.
* We can found hangs for greater that 1 minutes in drivers logs for example 
11:47:21 - 11:48:27 in archive named "log_with_memory_policy".

Yardstick logs in attachments. 



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

[jira] [Issue Comment Deleted] (IGNITE-4756) Print info about partition distribution to log

[Vadim Opolski (JIRA)]

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

Vadim Opolski updated IGNITE-4756:
--
Comment: was deleted

(was: [~tledkov-gridgain] [~avinogradov] Changing logging in progress.)

> Print info about partition distribution to log 
> ---
>
> Key: IGNITE-4756
> URL: https://issues.apache.org/jira/browse/IGNITE-4756
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Taras Ledkov
>Assignee: Vadim Opolski
>Priority: Minor
>  Labels: newbie
> Fix For: 2.2
>
>
> Summarize discussions:
> Add log message in case partitions distribution is not close to even 
> distribution:
> # Add system property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD with default 
> value 0.1 to print warn message only when nodes count differs more then 
> threshold;
> # The statistic is calculated and printed only for the local node;
> # Statistic is placed at the {{GridAffinityAssignmentCache#calculate}} and 
> calculated for new {{idealAssignment}}.
> # Message format is
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=, 
> expectedPrimary=, 
> exectedBackups=, 
> primary=, backups=].
> {noformat}
> e.g. for cache with name "test", 2 backups, 4 partition, 3 nodes:
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=test, 
> expectedPrimary=1.33 (33.3%), exectedBackups=2.66 (66.66%), primary=1 (25%), 
> backups=3(75%)].
> {noformat}



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

[jira] [Issue Comment Deleted] (IGNITE-4756) Print info about partition distribution to log

[Vadim Opolski (JIRA)]

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

Vadim Opolski updated IGNITE-4756:
--
Comment: was deleted

(was: [~tledkov-gridgain] [~avinogradov] Log4JLogger dependency removed from 
core module. Log have been initialize early. I'm working on printing cache 
group name in log and calculating statistics only for loacal node. What's the 
next step?
)

> Print info about partition distribution to log 
> ---
>
> Key: IGNITE-4756
> URL: https://issues.apache.org/jira/browse/IGNITE-4756
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Taras Ledkov
>Assignee: Vadim Opolski
>Priority: Minor
>  Labels: newbie
> Fix For: 2.2
>
>
> Summarize discussions:
> Add log message in case partitions distribution is not close to even 
> distribution:
> # Add system property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD with default 
> value 0.1 to print warn message only when nodes count differs more then 
> threshold;
> # The statistic is calculated and printed only for the local node;
> # Statistic is placed at the {{GridAffinityAssignmentCache#calculate}} and 
> calculated for new {{idealAssignment}}.
> # Message format is
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=, 
> expectedPrimary=, 
> exectedBackups=, 
> primary=, backups=].
> {noformat}
> e.g. for cache with name "test", 2 backups, 4 partition, 3 nodes:
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=test, 
> expectedPrimary=1.33 (33.3%), exectedBackups=2.66 (66.66%), primary=1 (25%), 
> backups=3(75%)].
> {noformat}



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

[jira] [Issue Comment Deleted] (IGNITE-4756) Print info about partition distribution to log

[Vadim Opolski (JIRA)]

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

Vadim Opolski updated IGNITE-4756:
--
Comment: was deleted

(was: [~tledkov-gridgain] [~avinogradov] Added print cache / group name in log 
message. Removing calculating statistics to method calculate in progress.)

> Print info about partition distribution to log 
> ---
>
> Key: IGNITE-4756
> URL: https://issues.apache.org/jira/browse/IGNITE-4756
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Taras Ledkov
>Assignee: Vadim Opolski
>Priority: Minor
>  Labels: newbie
> Fix For: 2.2
>
>
> Summarize discussions:
> Add log message in case partitions distribution is not close to even 
> distribution:
> # Add system property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD with default 
> value 0.1 to print warn message only when nodes count differs more then 
> threshold;
> # The statistic is calculated and printed only for the local node;
> # Statistic is placed at the {{GridAffinityAssignmentCache#calculate}} and 
> calculated for new {{idealAssignment}}.
> # Message format is
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=, 
> expectedPrimary=, 
> exectedBackups=, 
> primary=, backups=].
> {noformat}
> e.g. for cache with name "test", 2 backups, 4 partition, 3 nodes:
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=test, 
> expectedPrimary=1.33 (33.3%), exectedBackups=2.66 (66.66%), primary=1 (25%), 
> backups=3(75%)].
> {noformat}



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

[jira] [Issue Comment Deleted] (IGNITE-4756) Print info about partition distribution to log

[Vadim Opolski (JIRA)]

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

Vadim Opolski updated IGNITE-4756:
--
Comment: was deleted

(was: [~tledkov-gridgain] [~avinogradov]] Review please - 
https://reviews.ignite.apache.org/ignite/review/IGNT-CR-277)

> Print info about partition distribution to log 
> ---
>
> Key: IGNITE-4756
> URL: https://issues.apache.org/jira/browse/IGNITE-4756
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Taras Ledkov
>Assignee: Vadim Opolski
>Priority: Minor
>  Labels: newbie
> Fix For: 2.2
>
>
> Summarize discussions:
> Add log message in case partitions distribution is not close to even 
> distribution:
> # Add system property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD with default 
> value 0.1 to print warn message only when nodes count differs more then 
> threshold;
> # The statistic is calculated and printed only for the local node;
> # Statistic is placed at the {{GridAffinityAssignmentCache#calculate}} and 
> calculated for new {{idealAssignment}}.
> # Message format is
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=, 
> expectedPrimary=, 
> exectedBackups=, 
> primary=, backups=].
> {noformat}
> e.g. for cache with name "test", 2 backups, 4 partition, 3 nodes:
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=test, 
> expectedPrimary=1.33 (33.3%), exectedBackups=2.66 (66.66%), primary=1 (25%), 
> backups=3(75%)].
> {noformat}



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

[jira] [Issue Comment Deleted] (IGNITE-4756) Print info about partition distribution to log

[Vadim Opolski (JIRA)]

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

Vadim Opolski updated IGNITE-4756:
--
Comment: was deleted

(was: [~tledkov-gridgain] [~avinogradov] Added local node filtering in 
calculating statistics.)

> Print info about partition distribution to log 
> ---
>
> Key: IGNITE-4756
> URL: https://issues.apache.org/jira/browse/IGNITE-4756
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Taras Ledkov
>Assignee: Vadim Opolski
>Priority: Minor
>  Labels: newbie
> Fix For: 2.2
>
>
> Summarize discussions:
> Add log message in case partitions distribution is not close to even 
> distribution:
> # Add system property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD with default 
> value 0.1 to print warn message only when nodes count differs more then 
> threshold;
> # The statistic is calculated and printed only for the local node;
> # Statistic is placed at the {{GridAffinityAssignmentCache#calculate}} and 
> calculated for new {{idealAssignment}}.
> # Message format is
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=, 
> expectedPrimary=, 
> exectedBackups=, 
> primary=, backups=].
> {noformat}
> e.g. for cache with name "test", 2 backups, 4 partition, 3 nodes:
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=test, 
> expectedPrimary=1.33 (33.3%), exectedBackups=2.66 (66.66%), primary=1 (25%), 
> backups=3(75%)].
> {noformat}



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

[jira] [Created] (IGNITE-6107) GridFunc.first(list) throws NPE for null arg, but GridFunc.first(iterable) returns null

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-6107:


 Summary: GridFunc.first(list) throws NPE for null arg, but 
GridFunc.first(iterable) returns null
 Key: IGNITE-6107
 URL: https://issues.apache.org/jira/browse/IGNITE-6107
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.1
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.2


GridFunc.first(list) should return null in case of null argument.



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

[jira] [Updated] (IGNITE-6106) Web console: New function descriptions on homepage carousel and getting started dialog

[Alexey Kuznetsov (JIRA)]

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

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

> Web console: New function descriptions on homepage carousel and getting 
> started dialog
> --
>
> Key: IGNITE-6106
> URL: https://issues.apache.org/jira/browse/IGNITE-6106
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.2
>
>




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

[jira] [Commented] (IGNITE-4643) JdbcDatabaseMetadata.getIndexInfo() method not working

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-4643:
-

It seems that JdbcDatabaseMetadata is also lacking a lot of diagnostic calls 
which return sensible values in e.g. thin client.

> JdbcDatabaseMetadata.getIndexInfo() method not working
> --
>
> Key: IGNITE-4643
> URL: https://issues.apache.org/jira/browse/IGNITE-4643
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> {{JdbcDatabaseMetadata.getIndexInfo()}} method does not update metadata 
> before creating result set. So if it's a first method invocation on this 
> instance of {{JdbcDatabaseMetadata}}, it fails with NPE. Need to create tests 
> and add {{updateMetaData()}} call in the beginning of the method.



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

[jira] [Assigned] (IGNITE-6106) Web console: New function descriptions on homepage carousel and getting started dialog

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-6106:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

Added showing description for multicluster support.

> Web console: New function descriptions on homepage carousel and getting 
> started dialog
> --
>
> Key: IGNITE-6106
> URL: https://issues.apache.org/jira/browse/IGNITE-6106
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Minor
>




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

[jira] [Created] (IGNITE-6106) Web console: New function descriptions on homepage carousel and getting started dialog

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-6106:
-

 Summary: Web console: New function descriptions on homepage 
carousel and getting started dialog
 Key: IGNITE-6106
 URL: https://issues.apache.org/jira/browse/IGNITE-6106
 Project: Ignite
  Issue Type: Task
  Components: wizards
Affects Versions: 2.1
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko
Priority: Minor






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

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

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin reassigned IGNITE-6035:
--

Assignee: Dmitriy Govorukhin

> 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
>Assignee: Dmitriy Govorukhin
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> 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)