[jira] [Closed] (IGNITE-6476) Webconsole demo fails to import metadata

2017-09-21 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov closed IGNITE-6476.


> Webconsole demo fails to import metadata
> 
>
> Key: IGNITE-6476
> URL: https://issues.apache.org/jira/browse/IGNITE-6476
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Ilya Borisov
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
>
> *What happens:*
> When I try to import domain models in demo mode, web throws an error:
> {code}
> [2017-09-22 10:58:41,251][ERROR][pool-4-thread-1][AgentMetadataDemo] DEMO: 
> Failed to start test drive for metadata!
> java.sql.SQLException: No suitable driver found for 
> jdbc:h2:mem:demo-db;DB_CLOSE_DELAY=-1
> at java.sql.DriverManager.getConnection(DriverManager.java:689)
> at java.sql.DriverManager.getConnection(DriverManager.java:247)
> at 
> org.apache.ignite.console.demo.AgentMetadataDemo.testDrive(AgentMetadataDemo.java:61)
> at 
> org.apache.ignite.console.agent.handlers.DatabaseListener.connect(DatabaseListener.java:199)
> at 
> org.apache.ignite.console.agent.handlers.DatabaseListener.schemas(DatabaseListener.java:221)
> at 
> org.apache.ignite.console.agent.handlers.DatabaseListener$1.execute(DatabaseListener.java:83)
> at 
> org.apache.ignite.console.agent.handlers.AbstractListener$1.run(AbstractListener.java:71)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:748)
> {code}
> *Expected behavior:*
> Webagent should return requested metadata without throwing errors.



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


[jira] [Updated] (IGNITE-6476) Webconsole demo fails to import metadata

2017-09-21 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov updated IGNITE-6476:
-
Fix Version/s: 2.3

> Webconsole demo fails to import metadata
> 
>
> Key: IGNITE-6476
> URL: https://issues.apache.org/jira/browse/IGNITE-6476
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Ilya Borisov
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
>
> *What happens:*
> When I try to import domain models in demo mode, web throws an error:
> {code}
> [2017-09-22 10:58:41,251][ERROR][pool-4-thread-1][AgentMetadataDemo] DEMO: 
> Failed to start test drive for metadata!
> java.sql.SQLException: No suitable driver found for 
> jdbc:h2:mem:demo-db;DB_CLOSE_DELAY=-1
> at java.sql.DriverManager.getConnection(DriverManager.java:689)
> at java.sql.DriverManager.getConnection(DriverManager.java:247)
> at 
> org.apache.ignite.console.demo.AgentMetadataDemo.testDrive(AgentMetadataDemo.java:61)
> at 
> org.apache.ignite.console.agent.handlers.DatabaseListener.connect(DatabaseListener.java:199)
> at 
> org.apache.ignite.console.agent.handlers.DatabaseListener.schemas(DatabaseListener.java:221)
> at 
> org.apache.ignite.console.agent.handlers.DatabaseListener$1.execute(DatabaseListener.java:83)
> at 
> org.apache.ignite.console.agent.handlers.AbstractListener$1.run(AbstractListener.java:71)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:748)
> {code}
> *Expected behavior:*
> Webagent should return requested metadata without throwing errors.



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


[jira] [Updated] (IGNITE-6476) Webconsole demo fails to import metadata

2017-09-21 Thread Ilya Borisov (JIRA)

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

Ilya Borisov updated IGNITE-6476:
-
Description: 
*What happens:*
When I try to import domain models in demo mode, web throws an error:

[2017-09-22 10:58:41,251][ERROR][pool-4-thread-1][AgentMetadataDemo] DEMO: 
Failed to start test drive for metadata!
java.sql.SQLException: No suitable driver found for 
jdbc:h2:mem:demo-db;DB_CLOSE_DELAY=-1
at java.sql.DriverManager.getConnection(DriverManager.java:689)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at 
org.apache.ignite.console.demo.AgentMetadataDemo.testDrive(AgentMetadataDemo.java:61)
at 
org.apache.ignite.console.agent.handlers.DatabaseListener.connect(DatabaseListener.java:199)
at 
org.apache.ignite.console.agent.handlers.DatabaseListener.schemas(DatabaseListener.java:221)
at 
org.apache.ignite.console.agent.handlers.DatabaseListener$1.execute(DatabaseListener.java:83)
at 
org.apache.ignite.console.agent.handlers.AbstractListener$1.run(AbstractListener.java:71)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:748)


*Expected behavior:*
Webagent should return requested metadata without throwing errors.

  was:
*What happens:*
When I try to import domain models in demo mode, web throws an error:
{{
[2017-09-22 10:58:41,251][ERROR][pool-4-thread-1][AgentMetadataDemo] DEMO: 
Failed to start test drive for metadata!
java.sql.SQLException: No suitable driver found for 
jdbc:h2:mem:demo-db;DB_CLOSE_DELAY=-1
at java.sql.DriverManager.getConnection(DriverManager.java:689)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at 
org.apache.ignite.console.demo.AgentMetadataDemo.testDrive(AgentMetadataDemo.java:61)
at 
org.apache.ignite.console.agent.handlers.DatabaseListener.connect(DatabaseListener.java:199)
at 
org.apache.ignite.console.agent.handlers.DatabaseListener.schemas(DatabaseListener.java:221)
at 
org.apache.ignite.console.agent.handlers.DatabaseListener$1.execute(DatabaseListener.java:83)
at 
org.apache.ignite.console.agent.handlers.AbstractListener$1.run(AbstractListener.java:71)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:748)
}}

*Expected behavior:*
Webagent should return requested metadata without throwing errors.


> Webconsole demo fails to import metadata
> 
>
> Key: IGNITE-6476
> URL: https://issues.apache.org/jira/browse/IGNITE-6476
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Ilya Borisov
>Assignee: Alexey Kuznetsov
>
> *What happens:*
> When I try to import domain models in demo mode, web throws an error:
> [2017-09-22 10:58:41,251][ERROR][pool-4-thread-1][AgentMetadataDemo] DEMO: 
> Failed to start test drive for metadata!
> java.sql.SQLException: No suitable driver found for 
> jdbc:h2:mem:demo-db;DB_CLOSE_DELAY=-1
> at java.sql.DriverManager.getConnection(DriverManager.java:689)
> at java.sql.DriverManager.getConnection(DriverManager.java:247)
> at 
> org.apache.ignite.console.demo.AgentMetadataDemo.testDrive(AgentMetadataDemo.java:61)
> at 
> org.apache.ignite.console.agent.handlers.DatabaseListener.connect(DatabaseListener.java:199)
> at 
> org.apache.ignite.console.agent.handlers.DatabaseListener.schemas(DatabaseListener.java:221)
> at 
> org.apache.ignite.console.agent.handlers.DatabaseListener$1.execute(DatabaseListener.java:83)
> at 
> org.apache.ignite.console.agent.handlers.AbstractListener$1.run(AbstractListener.java:71)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:748)
> *Expected behavior:*
> Webagent should return requested metadata without throwing errors.



--
This message was sent by 

[jira] [Created] (IGNITE-6476) Webconsole demo fails to import metadata

2017-09-21 Thread Ilya Borisov (JIRA)
Ilya Borisov created IGNITE-6476:


 Summary: Webconsole demo fails to import metadata
 Key: IGNITE-6476
 URL: https://issues.apache.org/jira/browse/IGNITE-6476
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.1
Reporter: Ilya Borisov
Assignee: Alexey Kuznetsov


*What happens:*
When I try to import domain models in demo mode, web throws an error:
{{
[2017-09-22 10:58:41,251][ERROR][pool-4-thread-1][AgentMetadataDemo] DEMO: 
Failed to start test drive for metadata!
java.sql.SQLException: No suitable driver found for 
jdbc:h2:mem:demo-db;DB_CLOSE_DELAY=-1
at java.sql.DriverManager.getConnection(DriverManager.java:689)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at 
org.apache.ignite.console.demo.AgentMetadataDemo.testDrive(AgentMetadataDemo.java:61)
at 
org.apache.ignite.console.agent.handlers.DatabaseListener.connect(DatabaseListener.java:199)
at 
org.apache.ignite.console.agent.handlers.DatabaseListener.schemas(DatabaseListener.java:221)
at 
org.apache.ignite.console.agent.handlers.DatabaseListener$1.execute(DatabaseListener.java:83)
at 
org.apache.ignite.console.agent.handlers.AbstractListener$1.run(AbstractListener.java:71)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:748)
}}

*Expected behavior:*
Webagent should return requested metadata without throwing errors.



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


[jira] [Commented] (IGNITE-5767) Web console: use byte array type instead of java.lang.Object for binary JDBC types

2017-09-21 Thread Dmitry Karachentsev (JIRA)

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

Dmitry Karachentsev commented on IGNITE-5767:
-

Must be used `[B` type, not `byte[]`.

> Web console: use byte array type instead of java.lang.Object for binary JDBC 
> types
> --
>
> Key: IGNITE-5767
> URL: https://issues.apache.org/jira/browse/IGNITE-5767
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Denis Kholodov
>Assignee: Andrey Novikov
> Fix For: 2.3
>
>
> Schema importer should use {{[B}} query entity field type instead of 
> {{java.lang.Object}} for the following SQL types: {{BINARY}}, {{VARBINARY}} 
> and {{LONGVARBINARY}}.



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


[jira] [Commented] (IGNITE-6286) org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters

2017-09-21 Thread Sergey Chernolyas (JIRA)

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

Sergey Chernolyas commented on IGNITE-6286:
---

Reproduce exception by test IgniteSqlParameterQueryTest

__
[2017-09-21 
23:17:58,873][ERROR][query-#184%query.IgniteSqlParameterQueryTest0%][GridMapQueryExecutor]
 Failed to execute local query.
class org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:970)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1029)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1008)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:660)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:506)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:206)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor$2.onMessage(GridMapQueryExecutor.java:166)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2332)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.h2.jdbc.JdbcSQLException: Шестнадцатиричная строка содержит 
нечетное количество символов: "100"
Hexadecimal string with odd number of characters: "100"; SQL statement:
SELECT
__Z0._VAL __C0_0
FROM "Bookmark".BOOKMARK __Z0
WHERE __Z0.STOCKCOUNT = ?1 [90003-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
at org.h2.value.Value.convertTo(Value.java:957)
at org.h2.expression.Comparison.getValue(Comparison.java:264)
at org.h2.expression.Expression.getBooleanValue(Expression.java:178)
at org.h2.command.dml.Select.isConditionMet(Select.java:299)
at org.h2.command.dml.Select.access$600(Select.java:64)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1455)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
at org.h2.result.LazyResult.next(LazyResult.java:59)
at org.h2.command.dml.Select.queryFlat(Select.java:519)
at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
at org.h2.command.dml.Query.query(Query.java:352)
at org.h2.command.dml.Query.query(Query.java:333)
at org.h2.command.CommandContainer.query(CommandContainer.java:113)
at org.h2.command.Command.executeQuery(Command.java:201)
at 
org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:963)


> org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters
> --
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>
> Incorrect binding of  parameter's value for SQL queries with parameters. 
> The  incorrection leads to exception "org.h2.jdbc.JdbcSQLException: 
> Hexadecimal string with odd number of characters"



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


[jira] [Assigned] (IGNITE-6382) .NET: Set up NDepend analysis on TeamCity

2017-09-21 Thread Vitaliy Osipov (JIRA)

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

Vitaliy Osipov reassigned IGNITE-6382:
--

Assignee: Vitaliy Osipov

> .NET: Set up NDepend analysis on TeamCity
> -
>
> Key: IGNITE-6382
> URL: https://issues.apache.org/jira/browse/IGNITE-6382
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Vitaliy Osipov
>  Labels: .NET
>
> NDepend provided 6 build machine licenses to Apache Ignite: 
> https://svn.apache.org/repos/private/pmc/ignite/licenses/NDepend.txt
> 1) Install NDepend on Windows agents 
> (https://www.ndepend.com/docs/teamcity-integration-ndepend)
> 2) Set up NDepend project, adjust rules
> 3) Add NDepend analysis to {{Platform .NET Inspections}}: 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgnitePlatformNetInspections
> 4) Update wiki with instructions: 
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite.NET+Development



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


[jira] [Assigned] (IGNITE-6382) .NET: Set up NDepend analysis on TeamCity

2017-09-21 Thread Vitaliy Osipov (JIRA)

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

Vitaliy Osipov reassigned IGNITE-6382:
--

Assignee: Vitaliy Osipov

> .NET: Set up NDepend analysis on TeamCity
> -
>
> Key: IGNITE-6382
> URL: https://issues.apache.org/jira/browse/IGNITE-6382
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Vitaliy Osipov
>  Labels: .NET
>
> NDepend provided 6 build machine licenses to Apache Ignite: 
> https://svn.apache.org/repos/private/pmc/ignite/licenses/NDepend.txt
> 1) Install NDepend on Windows agents 
> (https://www.ndepend.com/docs/teamcity-integration-ndepend)
> 2) Set up NDepend project, adjust rules
> 3) Add NDepend analysis to {{Platform .NET Inspections}}: 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgnitePlatformNetInspections
> 4) Update wiki with instructions: 
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite.NET+Development



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


[jira] [Assigned] (IGNITE-6382) .NET: Set up NDepend analysis on TeamCity

2017-09-21 Thread Vitaliy Osipov (JIRA)

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

Vitaliy Osipov reassigned IGNITE-6382:
--

Assignee: (was: Vitaliy Osipov)

> .NET: Set up NDepend analysis on TeamCity
> -
>
> Key: IGNITE-6382
> URL: https://issues.apache.org/jira/browse/IGNITE-6382
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
>
> NDepend provided 6 build machine licenses to Apache Ignite: 
> https://svn.apache.org/repos/private/pmc/ignite/licenses/NDepend.txt
> 1) Install NDepend on Windows agents 
> (https://www.ndepend.com/docs/teamcity-integration-ndepend)
> 2) Set up NDepend project, adjust rules
> 3) Add NDepend analysis to {{Platform .NET Inspections}}: 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgnitePlatformNetInspections
> 4) Update wiki with instructions: 
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite.NET+Development



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


[jira] [Assigned] (IGNITE-6382) .NET: Set up NDepend analysis on TeamCity

2017-09-21 Thread Vitaliy Osipov (JIRA)

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

Vitaliy Osipov reassigned IGNITE-6382:
--

Assignee: (was: Vitaliy Osipov)

> .NET: Set up NDepend analysis on TeamCity
> -
>
> Key: IGNITE-6382
> URL: https://issues.apache.org/jira/browse/IGNITE-6382
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
>
> NDepend provided 6 build machine licenses to Apache Ignite: 
> https://svn.apache.org/repos/private/pmc/ignite/licenses/NDepend.txt
> 1) Install NDepend on Windows agents 
> (https://www.ndepend.com/docs/teamcity-integration-ndepend)
> 2) Set up NDepend project, adjust rules
> 3) Add NDepend analysis to {{Platform .NET Inspections}}: 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgnitePlatformNetInspections
> 4) Update wiki with instructions: 
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite.NET+Development



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


[jira] [Assigned] (IGNITE-6382) .NET: Set up NDepend analysis on TeamCity

2017-09-21 Thread Vitaliy Osipov (JIRA)

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

Vitaliy Osipov reassigned IGNITE-6382:
--

Assignee: Vitaliy Osipov

> .NET: Set up NDepend analysis on TeamCity
> -
>
> Key: IGNITE-6382
> URL: https://issues.apache.org/jira/browse/IGNITE-6382
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Vitaliy Osipov
>  Labels: .NET
>
> NDepend provided 6 build machine licenses to Apache Ignite: 
> https://svn.apache.org/repos/private/pmc/ignite/licenses/NDepend.txt
> 1) Install NDepend on Windows agents 
> (https://www.ndepend.com/docs/teamcity-integration-ndepend)
> 2) Set up NDepend project, adjust rules
> 3) Add NDepend analysis to {{Platform .NET Inspections}}: 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgnitePlatformNetInspections
> 4) Update wiki with instructions: 
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite.NET+Development



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


[jira] [Commented] (IGNITE-6473) Introduce a constant of default persistence store directory name

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6473:


GitHub user daradurvs opened a pull request:

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

IGNITE-6473 Introduce a constant of default persistence store directory name

… name

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

$ git pull https://github.com/daradurvs/ignite ignite-6473

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

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


commit b7f7c5b685fa1581bacd9a72710125810407b677
Author: Vyacheslav Daradur 
Date:   2017-09-21T18:49:18Z

ignite-6473: introduced the constant of default persistence directory name




> Introduce a constant of default persistence store directory name
> 
>
> Key: IGNITE-6473
> URL: https://issues.apache.org/jira/browse/IGNITE-6473
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.3
>
>
> Found that the name of default persistence store ("db") is hardcoded in 
> {{FilePageStoreManager}} and in some related unit tests.
> This may lead to issues in case of changing the directory name.
> Need to introduce a constant of default persistence store directory name, for 
> example:
> {code}public static final String DEFAULT_PERSISTENCE_STORE_DIR_NAME = 
> "db";{code}



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


[jira] [Updated] (IGNITE-6473) Introduce a constant of default persistence store directory name

2017-09-21 Thread Vyacheslav Daradur (JIRA)

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

Vyacheslav Daradur updated IGNITE-6473:
---
Description: 
Found that the name of default persistence store ("db") is hardcoded in 
{{FilePageStoreManager}} and in some related unit tests.
This may lead to issues in case of changing the directory name.
Need to introduce a constant of default persistence store directory name, for 
example:
{code}public static final String DEFAULT_PERSISTENCE_STORE_DIR_NAME = 
"db";{code}

  was:
Found that the name of default persistence store ("db") is hardcoded in 
{{FilePageStoreManager}} and in some related unit tests.
This may lead to issues in case of changing the directory name.
Need to introduce a constant of default persistence store directory name, for 
example:
{{public static final String DEFAULT_PERSISTENCE_STORE_DIR_NAME = "db";}}


> Introduce a constant of default persistence store directory name
> 
>
> Key: IGNITE-6473
> URL: https://issues.apache.org/jira/browse/IGNITE-6473
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.3
>
>
> Found that the name of default persistence store ("db") is hardcoded in 
> {{FilePageStoreManager}} and in some related unit tests.
> This may lead to issues in case of changing the directory name.
> Need to introduce a constant of default persistence store directory name, for 
> example:
> {code}public static final String DEFAULT_PERSISTENCE_STORE_DIR_NAME = 
> "db";{code}



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


[jira] [Updated] (IGNITE-6473) Introduce a constant of default persistence store directory name

2017-09-21 Thread Vyacheslav Daradur (JIRA)

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

Vyacheslav Daradur updated IGNITE-6473:
---
Description: 
Found that the name of default persistence store ("db") is hardcoded in 
{{FilePageStoreManager}} and in some related unit tests.
This may lead to issues in case of changing the directory name.
Need to introduce a constant of default persistence store directory name, for 
example:
{{public static final String DEFAULT_PERSISTENCE_STORE_DIR_NAME = "db";}}

  was:
Found that the name of default persistence store ("db") is hardcoded in 
{{FilePageStoreManager}} and in some related unit tests.
This may lead to issues in case of changing the directory name.
Need to introduce a constant of default persistence store directory name, for 
example:


> Introduce a constant of default persistence store directory name
> 
>
> Key: IGNITE-6473
> URL: https://issues.apache.org/jira/browse/IGNITE-6473
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.3
>
>
> Found that the name of default persistence store ("db") is hardcoded in 
> {{FilePageStoreManager}} and in some related unit tests.
> This may lead to issues in case of changing the directory name.
> Need to introduce a constant of default persistence store directory name, for 
> example:
> {{public static final String DEFAULT_PERSISTENCE_STORE_DIR_NAME = "db";}}



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


[jira] [Created] (IGNITE-6473) Introduce a constant of default persistence store directory name

2017-09-21 Thread Vyacheslav Daradur (JIRA)
Vyacheslav Daradur created IGNITE-6473:
--

 Summary: Introduce a constant of default persistence store 
directory name
 Key: IGNITE-6473
 URL: https://issues.apache.org/jira/browse/IGNITE-6473
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Affects Versions: 2.2
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
 Fix For: 2.3


Found that the name of default persistence store ("db") is hardcoded in 
{{FilePageStoreManager}} and in some related unit tests.
This may lead to issues in case of changing the directory name.
Need to introduce a constant of default persistence store directory name, for 
example:



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


[jira] [Commented] (IGNITE-4173) IgniteSemaphore with failoverSafe enabled doesn't release permits in case permits owner node left topology

2017-09-21 Thread Evgenii Zhuravlev (JIRA)

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

Evgenii Zhuravlev commented on IGNITE-4173:
---

[~vladisav] Vladisav, I've checked test  
SemaphoreFailoverSafeReleasePermitsTest  and noticed that if you get semaphore 
second time after the first node that acquired it was stopped, that leads to 
the impossibility of acquiring it. Could you describe why in test it 
Initializes second semaphore before the first one is broken?




> IgniteSemaphore with failoverSafe enabled doesn't release permits in case 
> permits owner node left topology
> --
>
> Key: IGNITE-4173
> URL: https://issues.apache.org/jira/browse/IGNITE-4173
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Andrey Gura
>Assignee: Vladisav Jelisavcic
> Fix For: 2.0
>
>
> {{IgniteSemaphore}} with {{failoverSafe}} enabled doesn't release permits in 
> case permits owner node left topology.
> See reproducer in test class {{SemaphoreFailoverSafeReleasePermitsTest}}.



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


[jira] [Commented] (IGNITE-6213) Unexpected setting local deployment owner anyone node

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6213:


GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-6213 remove locDepOwner flag, and mark as deprecated



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

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

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

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


commit 6349c172547e0280e020aa3b02440b2975d7f328
Author: Dmitriy Govorukhin 
Date:   2017-09-21T17:16:58Z

IGNITE-6213 remove locDepOwner flag, and mark as deprecated




> Unexpected setting local deployment owner anyone node
> -
>
> Key: IGNITE-6213
> URL: https://issues.apache.org/jira/browse/IGNITE-6213
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Dmitriy Govorukhin
> Fix For: 2.3
>
>
> In my test I have seen, when one node tune up {{locDepOwner}} flag suddenly.
> {noformat}
> 16:55:47.868 
> [ DEBUG] 
> [ o.a.i.i.p.c.GridCacheDeploymentManager] 
> [ T:] - Prepared grid cache deployable 
> [ dep=GridDeploymentInfoBean 
> [ clsLdrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553, depMode=SHARED, 
> userVer=0, locDepOwner=true, participants=null], 
> deployable=GridNearAtomicSingleUpdateRequest 
> [ key=UserKeyCacheObjectImpl 
> [ part=111, val=4翿翿, hasValBytes=true], 
> super=GridNearAtomicSingleUpdateRequest 
> [ key=UserKeyCacheObjectImpl 
> [ part=111, val=4翿翿, hasValBytes=true], 
> parent=GridNearAtomicAbstractSingleUpdateRequest 
> [ nodeId=45acc827-8a2d-47d3-aa04-94936ad25ac2, futId=81921, 
> topVer=AffinityTopologyVersion 
> [ topVer=4, minorTopVer=0], parent=GridNearAtomicAbstractUpdateRequest 
> [ res=null, flags=]
> {noformat}
> By the reason global participant was been registered:
> {noformat}
> 16:55:47.871 
> [  DEBUG] 
> [  o.a.i.i.m.d.GridDeploymentPerVersionStore] 
> [  T:] - Explicitly added participant 
> [  dep=SharedDeployment 
> [  rmv=false, super=GridDeployment 
> [  ts=1503050146264, depMode=SHARED, clsLdr=GridDeploymentClassLoader 
> [  id=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, singleNode=false, 
> nodeLdrMap={12bb727e-4815-4ab2-8f8c-cc6fd52c8553=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
>  
> 101abc71-83b4-4a87-bb07-14e4cbc7226e=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
>  
> 9d30737f-44d2-4414-b84d-25f032484290=e70b3c4fd51-9d30737f-44d2-4414-b84d-25f032484290},
>  p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false], 
> clsLdrId=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, userVer=0, 
> loc=false, sampleClsName=com.sbt.dpl.gridgain.index.InvokeIndexAdder, 
> pendingUndeploy=false, undeployed=false, usage=0]], 
> nodeId=12bb727e-4815-4ab2-8f8c-cc6fd52c8553, 
> ldrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553]
> {noformat}
> And after that I am geting the Exception when try to get class from node 
> where the class was not located:
> {noformat}
> 16:55:50.684 [ERROR] [o.a.i.i.p.job.GridJobProcessor] [T:] - Task was not 
> deployed or was redeployed since task execution 
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>  
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>  codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e, 
> seqNum=1503050088642, depMode=SHARED, dep=null]
> org.apache.ignite.IgniteDeploymentException: Task was not deployed or was 
> redeployed since task execution 
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>  
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>  codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e, 
> seqNum=1503050088642, depMode=SHARED, dep=null]
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1160)
>  ~[ignite-core-2.1.3.jar:2.1.3]
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
>  [ignite-core-2.1.3.jar:2.1.3]
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
>  [ignite-core-2.1.3.jar:2.1.3]
>   at 
> 

[jira] [Assigned] (IGNITE-6213) Unexpected setting local deployment owner anyone node

2017-09-21 Thread Dmitriy Govorukhin (JIRA)

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

Dmitriy Govorukhin reassigned IGNITE-6213:
--

Assignee: Dmitriy Govorukhin  (was: Vladislav Pyatkov)

> Unexpected setting local deployment owner anyone node
> -
>
> Key: IGNITE-6213
> URL: https://issues.apache.org/jira/browse/IGNITE-6213
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Dmitriy Govorukhin
> Fix For: 2.3
>
>
> In my test I have seen, when one node tune up {{locDepOwner}} flag suddenly.
> {noformat}
> 16:55:47.868 
> [ DEBUG] 
> [ o.a.i.i.p.c.GridCacheDeploymentManager] 
> [ T:] - Prepared grid cache deployable 
> [ dep=GridDeploymentInfoBean 
> [ clsLdrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553, depMode=SHARED, 
> userVer=0, locDepOwner=true, participants=null], 
> deployable=GridNearAtomicSingleUpdateRequest 
> [ key=UserKeyCacheObjectImpl 
> [ part=111, val=4翿翿, hasValBytes=true], 
> super=GridNearAtomicSingleUpdateRequest 
> [ key=UserKeyCacheObjectImpl 
> [ part=111, val=4翿翿, hasValBytes=true], 
> parent=GridNearAtomicAbstractSingleUpdateRequest 
> [ nodeId=45acc827-8a2d-47d3-aa04-94936ad25ac2, futId=81921, 
> topVer=AffinityTopologyVersion 
> [ topVer=4, minorTopVer=0], parent=GridNearAtomicAbstractUpdateRequest 
> [ res=null, flags=]
> {noformat}
> By the reason global participant was been registered:
> {noformat}
> 16:55:47.871 
> [  DEBUG] 
> [  o.a.i.i.m.d.GridDeploymentPerVersionStore] 
> [  T:] - Explicitly added participant 
> [  dep=SharedDeployment 
> [  rmv=false, super=GridDeployment 
> [  ts=1503050146264, depMode=SHARED, clsLdr=GridDeploymentClassLoader 
> [  id=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, singleNode=false, 
> nodeLdrMap={12bb727e-4815-4ab2-8f8c-cc6fd52c8553=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
>  
> 101abc71-83b4-4a87-bb07-14e4cbc7226e=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
>  
> 9d30737f-44d2-4414-b84d-25f032484290=e70b3c4fd51-9d30737f-44d2-4414-b84d-25f032484290},
>  p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false], 
> clsLdrId=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, userVer=0, 
> loc=false, sampleClsName=com.sbt.dpl.gridgain.index.InvokeIndexAdder, 
> pendingUndeploy=false, undeployed=false, usage=0]], 
> nodeId=12bb727e-4815-4ab2-8f8c-cc6fd52c8553, 
> ldrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553]
> {noformat}
> And after that I am geting the Exception when try to get class from node 
> where the class was not located:
> {noformat}
> 16:55:50.684 [ERROR] [o.a.i.i.p.job.GridJobProcessor] [T:] - Task was not 
> deployed or was redeployed since task execution 
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>  
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>  codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e, 
> seqNum=1503050088642, depMode=SHARED, dep=null]
> org.apache.ignite.IgniteDeploymentException: Task was not deployed or was 
> redeployed since task execution 
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>  
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>  codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e, 
> seqNum=1503050088642, depMode=SHARED, dep=null]
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1160)
>  ~[ignite-core-2.1.3.jar:2.1.3]
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
>  [ignite-core-2.1.3.jar:2.1.3]
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
>  [ignite-core-2.1.3.jar:2.1.3]
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
>  [ignite-core-2.1.3.jar:2.1.3]
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
>  [ignite-core-2.1.3.jar:2.1.3]
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
>  [ignite-core-2.1.3.jar:2.1.3]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_80]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_80]
>   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_80]
> {noformat}



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


[jira] [Commented] (IGNITE-6294) ODBC: Propagate SQLSTATE error codes

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6294:


Github user asfgit closed the pull request at:

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


> ODBC: Propagate SQLSTATE error codes
> 
>
> Key: IGNITE-6294
> URL: https://issues.apache.org/jira/browse/IGNITE-6294
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> We should propagate SQLSTATE to ODBC usrs when it's server-side part is ready 
> [1].
> [1] IGNITE-5620



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


[jira] [Commented] (IGNITE-6059) Use any distributed matrix in K-Means

2017-09-21 Thread Mikhail Lipkovich (JIRA)

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

Mikhail Lipkovich commented on IGNITE-6059:
---

Hi Yury,
I see there is an implementation of KMeansDistributedClusterer which works with 
SparseDistributedMatrix. Do you expect this clusterer to work with absolutely 
_any_ implementation of AbstractMatrix or what are your expectations?
I would like to participate in ML-related activities. Please let me know if you 
think there is a task which is better suitable for a newbie
Thanks

> Use any distributed matrix in K-Means
> -
>
> Key: IGNITE-6059
> URL: https://issues.apache.org/jira/browse/IGNITE-6059
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
> Fix For: 2.3
>
>
> Currently k-means work only with row/col matrix.



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


[jira] [Commented] (IGNITE-6397) .NET: Thin client: basic cache operations

2017-09-21 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn commented on IGNITE-6397:


All done except {{RemoveAll}}.

> .NET: Thin client: basic cache operations
> -
>
> Key: IGNITE-6397
> URL: https://issues.apache.org/jira/browse/IGNITE-6397
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, platforms
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> We need to implement base cache operations, such as "remove", "replace", 
> "putIfAbsent". 



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


[jira] [Commented] (IGNITE-5732) Provide API to test compatibility with old releases

2017-09-21 Thread Anton Vinogradov (JIRA)

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

Anton Vinogradov commented on IGNITE-5732:
--

[~daradurvs],

Looks good to me. 
Please recheck TC and I'll megre improvement. 

> Provide API to test compatibility with old releases
> ---
>
> Key: IGNITE-5732
> URL: https://issues.apache.org/jira/browse/IGNITE-5732
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.3
>
>
> Need to provide an opportunity to test compatibility with old releases.
> The main idea is the method {code}startGrid(ver){code} in the testing 
> framework, which would start an instance via downloaded "jar" from the Maven 
> repo.



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


[jira] [Commented] (IGNITE-6472) Remove unused GridOffHeapProcessor

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6472:


GitHub user sarutak opened a pull request:

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

IGNITE-6472 Removed unusad GridOffHeapProcessor

GridOffHeapProcessor seems to be no longer used.
Can we remove this?
Please correct me if I'm wrong.

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

$ git pull https://github.com/sarutak/ignite remove-unused-class

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

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


commit af158c10f3a299f853526deb80ccaae142f84f03
Author: Kousuke Saruta 
Date:   2017-09-21T16:03:29Z

Removed unusad GridOffHeapProcessor.java




> Remove unused GridOffHeapProcessor
> --
>
> Key: IGNITE-6472
> URL: https://issues.apache.org/jira/browse/IGNITE-6472
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Kousuke Saruta
>Assignee: Kousuke Saruta
>Priority: Minor
>
> GridOffHeapProcessor seems to be no longer used.
> Can we remove this?
> Please correct me if I'm wrong.



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


[jira] [Created] (IGNITE-6472) Remove unused GridOffHeapProcessor

2017-09-21 Thread Kousuke Saruta (JIRA)
Kousuke Saruta created IGNITE-6472:
--

 Summary: Remove unused GridOffHeapProcessor
 Key: IGNITE-6472
 URL: https://issues.apache.org/jira/browse/IGNITE-6472
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.2
Reporter: Kousuke Saruta
Assignee: Kousuke Saruta
Priority: Minor


GridOffHeapProcessor seems to be no longer used.
Can we remove this?
Please correct me if I'm wrong.



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


[jira] [Created] (IGNITE-6471) .NET: Flags should have plural names

2017-09-21 Thread Pavel Tupitsyn (JIRA)
Pavel Tupitsyn created IGNITE-6471:
--

 Summary: .NET: Flags should have plural names
 Key: IGNITE-6471
 URL: https://issues.apache.org/jira/browse/IGNITE-6471
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 3.0


{{[Flags]}} enums should have plural names.

For example, {{CachePeekMode}} should be renamed to {{CachePeekModes}}.
Also, {{int GetSize(params CachePeekMode[] modes)}} should be changed to {{int 
GetSize(CachePeekModes modes)}}: flags can be combined with bitwise OR.



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


[jira] [Commented] (IGNITE-6460) Wrong consistentId for lightweight ClusterNode instances

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6460:


Github user asfgit closed the pull request at:

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


> Wrong consistentId for lightweight ClusterNode instances
> 
>
> Key: IGNITE-6460
> URL: https://issues.apache.org/jira/browse/IGNITE-6460
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Alexey Goncharuk
> Fix For: 2.3
>
>
> I have introduced new constructor for TcpDiscoveryNode to create lightweight 
> instances to store them on disc or etc.
> But to save consistentId we need not only keep it in field, but also add to 
> node attributes.



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


[jira] [Commented] (IGNITE-6316) SQL: Add ALTER TABLE tests with persistence

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6316:


Github user asfgit closed the pull request at:

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


> SQL: Add ALTER TABLE tests with persistence
> ---
>
> Key: IGNITE-6316
> URL: https://issues.apache.org/jira/browse/IGNITE-6316
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>
> Scenario:
> 1) Start a node with persistence and pre-configured cache and {{QueryEntity}}
> 2) Add a column through {{ALTER TABLE}}
> 3) Restart the node
> 4) Make sure that new column is still there



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


[jira] [Resolved] (IGNITE-6470) Wrong casting of long value to int leads to incorrect results

2017-09-21 Thread Andrey Gura (JIRA)

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

Andrey Gura resolved IGNITE-6470.
-
Resolution: Fixed

> Wrong casting of long value to int leads to incorrect results
> -
>
> Key: IGNITE-6470
> URL: https://issues.apache.org/jira/browse/IGNITE-6470
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 2.3
>
>
> Wrong casting of {{long}} value to {{int}} leads to incorrect results:
> {code:java}
> /** {@inheritDoc} */
> @Override public int pages() {
> if (!inited)
> return 0;
> 
> // allocated.get() returns long value. We should cast it to int after 
> division.
> return (int)((allocated.get() - headerSize()) / pageSize);
> }
> {code}



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


[jira] [Commented] (IGNITE-6470) Wrong casting of long value to int leads to incorrect results

2017-09-21 Thread Andrey Gura (JIRA)

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

Andrey Gura commented on IGNITE-6470:
-

Fixed and merged to master branch.

> Wrong casting of long value to int leads to incorrect results
> -
>
> Key: IGNITE-6470
> URL: https://issues.apache.org/jira/browse/IGNITE-6470
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 2.3
>
>
> Wrong casting of {{long}} value to {{int}} leads to incorrect results:
> {code:java}
> /** {@inheritDoc} */
> @Override public int pages() {
> if (!inited)
> return 0;
> 
> // allocated.get() returns long value. We should cast it to int after 
> division.
> return (int)((allocated.get() - headerSize()) / pageSize);
> }
> {code}



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


[jira] [Updated] (IGNITE-6470) Wrong casting of long value to int leads to incorrect results

2017-09-21 Thread Andrey Gura (JIRA)

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

Andrey Gura updated IGNITE-6470:

Description: 
Wrong casting of {{long}} value to {{int}} leads to incorrect results:

{code:java}
/** {@inheritDoc} */
@Override public int pages() {
if (!inited)
return 0;

// allocated.get() returns long value. We should cast it to int after 
division.
return (int)((allocated.get() - headerSize()) / pageSize);
}

{code}

  was:
Wrong casting of long value to int leads to incorrect results:

{code:java}
/** {@inheritDoc} */
@Override public int pages() {
if (!inited)
return 0;

// allocated.get() returns long value. We should cast it to int after 
division.
return (int)((allocated.get() - headerSize()) / pageSize);
}

{code}


> Wrong casting of long value to int leads to incorrect results
> -
>
> Key: IGNITE-6470
> URL: https://issues.apache.org/jira/browse/IGNITE-6470
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 2.3
>
>
> Wrong casting of {{long}} value to {{int}} leads to incorrect results:
> {code:java}
> /** {@inheritDoc} */
> @Override public int pages() {
> if (!inited)
> return 0;
> 
> // allocated.get() returns long value. We should cast it to int after 
> division.
> return (int)((allocated.get() - headerSize()) / pageSize);
> }
> {code}



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


[jira] [Created] (IGNITE-6470) Wrong casting of long value to int leads to incorrect results

2017-09-21 Thread Andrey Gura (JIRA)
Andrey Gura created IGNITE-6470:
---

 Summary: Wrong casting of long value to int leads to incorrect 
results
 Key: IGNITE-6470
 URL: https://issues.apache.org/jira/browse/IGNITE-6470
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Andrey Gura
Assignee: Andrey Gura
 Fix For: 2.3


Wrong casting of long value to int leads to incorrect results:

{code:java}
/** {@inheritDoc} */
@Override public int pages() {
if (!inited)
return 0;

// allocated.get() returns long value. We should cast it to int after 
division.
return (int)((allocated.get() - headerSize()) / pageSize);
}

{code}



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


[jira] [Resolved] (IGNITE-6228) Avoid closing page store file with ClosedByInterruptException when user thread is interrupted

2017-09-21 Thread Alexey Goncharuk (JIRA)

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

Alexey Goncharuk resolved IGNITE-6228.
--
Resolution: Fixed

Thanks, Alexei, merged to master

> Avoid closing page store file with ClosedByInterruptException when user 
> thread is interrupted
> -
>
> Key: IGNITE-6228
> URL: https://issues.apache.org/jira/browse/IGNITE-6228
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Alexei Scherbakov
> Fix For: 2.3
>
> Attachments: RestartGridTest.java
>
>
> If cache proxy is in synchronous mode, user thread may be interrupted during 
> read from file page store file. This will cause closing of partition file 
> with ClosedByInterruptException.
> Example stacktrace:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Runtime failure on lookup 
> row: 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@717729d
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1070)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.find(IgniteCacheOffheapManagerImpl.java:1476)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.find(GridCacheOffheapManager.java:1276)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.read(IgniteCacheOffheapManagerImpl.java:394)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:371)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2952)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1012)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:868)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1680)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:875)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.RestartGridTest$TestService.execute(RestartGridTest.java:160)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$2.run(GridServiceProcessor.java:1160)
>   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: Read error
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:356)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:287)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:272)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:570)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:488)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:129)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.treeMeta(BPlusTree.java:822)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$7700(BPlusTree.java:81)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Get.init(BPlusTree.java:2392)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind(BPlusTree.java:1099)
>   at 

[jira] [Updated] (IGNITE-6466) Ignite PDS1: Test testGetForInitialWrite failed in IgnitePdsCheckpointSimulationWithRealCpDisabledTest

2017-09-21 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov updated IGNITE-6466:
---
Affects Version/s: 2.3

> Ignite PDS1: Test testGetForInitialWrite failed in 
> IgnitePdsCheckpointSimulationWithRealCpDisabledTest 
> ---
>
> Key: IGNITE-6466
> URL: https://issues.apache.org/jira/browse/IGNITE-6466
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Assertion in 
> {noformat}
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.pagemem.PageUtils.getShort(PageUtils.java:94)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getPageEntrySize(DataPageIO.java:138)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.printPageLayout(DataPageIO.java:388)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.printPage(DataPageIO.java:1448)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.printPage(PageIO.java:571)
> at 
> org.apache.ignite.internal.pagemem.wal.record.PageSnapshot.toString(PageSnapshot.java:90)
> at java.lang.String.valueOf(String.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testGetForInitialWrite(IgnitePdsCheckpointSimulationWithRealCpDisabledTest.java:275)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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


[jira] [Issue Comment Deleted] (IGNITE-6286) org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters

2017-09-21 Thread Sergey Chernolyas (JIRA)

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

Sergey Chernolyas updated IGNITE-6286:
--
Comment: was deleted

(was: The topic contains explanation of the exception.)

> org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters
> --
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>
> Incorrect binding of  parameter's value for SQL queries with parameters. 
> The  incorrection leads to exception "org.h2.jdbc.JdbcSQLException: 
> Hexadecimal string with odd number of characters"



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


[jira] [Updated] (IGNITE-6286) org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters

2017-09-21 Thread Sergey Chernolyas (JIRA)

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

Sergey Chernolyas updated IGNITE-6286:
--
Summary: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number 
of characters  (was: Incorrect binding of  parameter's value in SQL query with 
parameters)

> org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters
> --
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>
> Incorrect binding of  parameter's value for SQL queries with parameters. 
> The  incorrection leads to exception "org.h2.jdbc.JdbcSQLException: 
> Hexadecimal string with odd number of characters"



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


[jira] [Updated] (IGNITE-6286) Incorrect binding of parameter's value in SQL query with parameters

2017-09-21 Thread Sergey Chernolyas (JIRA)

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

Sergey Chernolyas updated IGNITE-6286:
--
Summary: Incorrect binding of  parameter's value in SQL query with 
parameters  (was: Incorrect binding of  parameter's value in SQL query)

> Incorrect binding of  parameter's value in SQL query with parameters
> 
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>
> Incorrect binding of  parameter's value. See 
> https://github.com/apache/ignite/blob/ignite-2.1/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java#L510
> The code leads to problem. See explanation in  
> https://groups.google.com/forum/#!topic/h2-database/fiUw3tqRb1o



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


[jira] [Updated] (IGNITE-6286) incorrect 'setObject' call

2017-09-21 Thread Sergey Chernolyas (JIRA)

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

Sergey Chernolyas updated IGNITE-6286:
--
Description: 
Incorrect binding of  parameter's value. See 
https://github.com/apache/ignite/blob/ignite-2.1/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java#L510

The code leads to problem. See explanation in  
https://groups.google.com/forum/#!topic/h2-database/fiUw3tqRb1o

  was:
Incorrect set value of parameter. See 
https://github.com/apache/ignite/blob/ignite-2.1/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java#L510

The code leads to problem. See explanation in  
https://groups.google.com/forum/#!topic/h2-database/fiUw3tqRb1o


> incorrect 'setObject' call
> --
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>
> Incorrect binding of  parameter's value. See 
> https://github.com/apache/ignite/blob/ignite-2.1/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java#L510
> The code leads to problem. See explanation in  
> https://groups.google.com/forum/#!topic/h2-database/fiUw3tqRb1o



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


[jira] [Updated] (IGNITE-6286) Incorrect binding of parameter's value in SQL query

2017-09-21 Thread Sergey Chernolyas (JIRA)

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

Sergey Chernolyas updated IGNITE-6286:
--
Summary: Incorrect binding of  parameter's value in SQL query  (was: 
incorrect 'setObject' call)

> Incorrect binding of  parameter's value in SQL query
> 
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>
> Incorrect binding of  parameter's value. See 
> https://github.com/apache/ignite/blob/ignite-2.1/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java#L510
> The code leads to problem. See explanation in  
> https://groups.google.com/forum/#!topic/h2-database/fiUw3tqRb1o



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


[jira] [Commented] (IGNITE-6465) JDBC thin: SQLSTATE is not set for BatchUpdateException

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6465:


Github user asfgit closed the pull request at:

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


> JDBC thin: SQLSTATE is not set for BatchUpdateException
> ---
>
> Key: IGNITE-6465
> URL: https://issues.apache.org/jira/browse/IGNITE-6465
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> Vendor code is propagated to {{BatchUpdateException}}, but {{SQLSTATE}} is 
> set to {{null}}.



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


[jira] [Commented] (IGNITE-6294) ODBC: Propagate SQLSTATE error codes

2017-09-21 Thread Sergey Kalashnikov (JIRA)

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

Sergey Kalashnikov commented on IGNITE-6294:


[~isapego], I reviewed the code. Please see my comments in upsource

> ODBC: Propagate SQLSTATE error codes
> 
>
> Key: IGNITE-6294
> URL: https://issues.apache.org/jira/browse/IGNITE-6294
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> We should propagate SQLSTATE to ODBC usrs when it's server-side part is ready 
> [1].
> [1] IGNITE-5620



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


[jira] [Created] (IGNITE-6468) ODBC: Add tests for SQLGetInfo

2017-09-21 Thread Igor Sapego (JIRA)
Igor Sapego created IGNITE-6468:
---

 Summary: ODBC: Add tests for SQLGetInfo
 Key: IGNITE-6468
 URL: https://issues.apache.org/jira/browse/IGNITE-6468
 Project: Ignite
  Issue Type: Improvement
  Components: odbc
Affects Versions: 2.1
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.3


Since we fully implemented {{SQLGetInfo}} (IGNITE-6099) we need proper tests 
for it. 



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


[jira] [Updated] (IGNITE-5918) Adding and searching objects in index tree produces a lot of garbage

2017-09-21 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-5918:

Component/s: (was: sql)
 general

> Adding and searching objects in index tree produces a lot of garbage
> 
>
> Key: IGNITE-5918
> URL: https://issues.apache.org/jira/browse/IGNITE-5918
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Mikhail Cherkasov
>Assignee: Igor Seliverstov
>  Labels: performance
> Fix For: 2.3
>
>
> Adding and searching objects in index tree produces a lot of garbage and this 
> can lead to big GC pauses.
> Tests with data streaming of object with 5 string indexes show that ignite 
> server spends about 15-25% CPU time in GC.
> The problem is that ignite deserialize objects for comparing, while for the 
> primitive type and strings comparing can be implemented for bytes.



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


[jira] [Commented] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6448:


Github user asfgit closed the pull request at:

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


> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.3
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   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)
> {noformat}
> 2. When I try to get all data from Person:
> {noformat}select * from person;{noformat}
> I get the table without new field but if try to get only this field from 
> table it works.



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


[jira] [Commented] (IGNITE-6466) Ignite PDS1: Test testGetForInitialWrite failed in IgnitePdsCheckpointSimulationWithRealCpDisabledTest

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6466:


GitHub user dspavlov opened a pull request:

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

IGNITE-6466:Ignite PDS1: Test testGetForInitialWrite failed

IgnitePdsCheckpointSimulationWithRealCpDisabledTest

Data page IO print fixed

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

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

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

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


commit 8923eb2e7340faeff7e4a2c09e494a62bb0bf5ea
Author: dpavlov 
Date:   2017-09-21T14:32:59Z

IGNITE-6466:Ignite PDS1: Test testGetForInitialWrite failed in 
IgnitePdsCheckpointSimulationWithRealCpDisabledTest




> Ignite PDS1: Test testGetForInitialWrite failed in 
> IgnitePdsCheckpointSimulationWithRealCpDisabledTest 
> ---
>
> Key: IGNITE-6466
> URL: https://issues.apache.org/jira/browse/IGNITE-6466
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Assertion in 
> {noformat}
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.pagemem.PageUtils.getShort(PageUtils.java:94)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getPageEntrySize(DataPageIO.java:138)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.printPageLayout(DataPageIO.java:388)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.printPage(DataPageIO.java:1448)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.printPage(PageIO.java:571)
> at 
> org.apache.ignite.internal.pagemem.wal.record.PageSnapshot.toString(PageSnapshot.java:90)
> at java.lang.String.valueOf(String.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testGetForInitialWrite(IgnitePdsCheckpointSimulationWithRealCpDisabledTest.java:275)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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


[jira] [Assigned] (IGNITE-6286) incorrect 'setObject' call

2017-09-21 Thread Sergey Chernolyas (JIRA)

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

Sergey Chernolyas reassigned IGNITE-6286:
-

Assignee: Sergey Chernolyas

> incorrect 'setObject' call
> --
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>
> Incorrect set value of parameter. See 
> https://github.com/apache/ignite/blob/ignite-2.1/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java#L510
> The code leads to problem. See explanation in  
> https://groups.google.com/forum/#!topic/h2-database/fiUw3tqRb1o



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


[jira] [Created] (IGNITE-6467) Ignite cache 6: new test testConcurrentStartServersAndClients() has flaky junit assertion after cache get

2017-09-21 Thread Dmitriy Pavlov (JIRA)
Dmitriy Pavlov created IGNITE-6467:
--

 Summary: Ignite cache 6: new test 
testConcurrentStartServersAndClients() has flaky junit assertion after cache get
 Key: IGNITE-6467
 URL: https://issues.apache.org/jira/browse/IGNITE-6467
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Pavlov
Assignee: Semen Boikov


Ignite cache 6: CacheExchangeMergeTest.testConcurrentStartServersAndClients 
fails with probability >10% in master and in PRs

https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=741151191800314619=testDetails

latest failure from master
https://ci.ignite.apache.org/viewLog.html?buildId=843261=buildResultsDiv=Ignite20Tests_IgniteCache6#testNameId741151191800314619

{noformat}
Invalid value [node=distributed.CacheExchangeMergeTest0, client=false, order=1, 
cache=c1] expected:<0> but was:
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkNodeCaches(CacheExchangeMergeTest.java:1343)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkCaches0(CacheExchangeMergeTest.java:1213)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkCaches(CacheExchangeMergeTest.java:1195)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.concurrentStart(CacheExchangeMergeTest.java:446)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.testConcurrentStartServersAndClients(CacheExchangeMergeTest.java:414)
Caused by: junit.framework.AssertionFailedError: Invalid value 
[node=distributed.CacheExchangeMergeTest0, client=false, order=1, cache=c1] 
expected:<0> but was:
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.TestCase.assertEquals(TestCase.java:244)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest$16.run(CacheExchangeMergeTest.java:1312)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{nofromat}



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


[jira] [Updated] (IGNITE-6467) Ignite cache 6: new test testConcurrentStartServersAndClients() has flaky junit assertion after cache get

2017-09-21 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov updated IGNITE-6467:
---
Description: 
Ignite cache 6: CacheExchangeMergeTest.testConcurrentStartServersAndClients 
fails with probability >10% in master and in PRs

https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=741151191800314619=testDetails

latest failure from master
https://ci.ignite.apache.org/viewLog.html?buildId=843261=buildResultsDiv=Ignite20Tests_IgniteCache6#testNameId741151191800314619

{noformat}
Invalid value [node=distributed.CacheExchangeMergeTest0, client=false, order=1, 
cache=c1] expected:<0> but was:
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkNodeCaches(CacheExchangeMergeTest.java:1343)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkCaches0(CacheExchangeMergeTest.java:1213)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkCaches(CacheExchangeMergeTest.java:1195)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.concurrentStart(CacheExchangeMergeTest.java:446)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.testConcurrentStartServersAndClients(CacheExchangeMergeTest.java:414)
Caused by: junit.framework.AssertionFailedError: Invalid value 
[node=distributed.CacheExchangeMergeTest0, client=false, order=1, cache=c1] 
expected:<0> but was:
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.TestCase.assertEquals(TestCase.java:244)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest$16.run(CacheExchangeMergeTest.java:1312)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}

  was:
Ignite cache 6: CacheExchangeMergeTest.testConcurrentStartServersAndClients 
fails with probability >10% in master and in PRs

https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=741151191800314619=testDetails

latest failure from master
https://ci.ignite.apache.org/viewLog.html?buildId=843261=buildResultsDiv=Ignite20Tests_IgniteCache6#testNameId741151191800314619

{noformat}
Invalid value [node=distributed.CacheExchangeMergeTest0, client=false, order=1, 
cache=c1] expected:<0> but was:
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkNodeCaches(CacheExchangeMergeTest.java:1343)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkCaches0(CacheExchangeMergeTest.java:1213)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkCaches(CacheExchangeMergeTest.java:1195)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.concurrentStart(CacheExchangeMergeTest.java:446)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.testConcurrentStartServersAndClients(CacheExchangeMergeTest.java:414)
Caused by: junit.framework.AssertionFailedError: Invalid value 
[node=distributed.CacheExchangeMergeTest0, client=false, order=1, cache=c1] 
expected:<0> but was:
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.TestCase.assertEquals(TestCase.java:244)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest$16.run(CacheExchangeMergeTest.java:1312)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{nofromat}


> Ignite cache 6: new test testConcurrentStartServersAndClients() has flaky 
> junit assertion after cache get
> -
>
> Key: IGNITE-6467
> URL: 

[jira] [Commented] (IGNITE-6465) JDBC thin: SQLSTATE is not set for BatchUpdateException

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6465:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-6465: JDBC thin: set SQLSTATE for BatchUpdateException



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

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

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

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


commit e91036d6cce0b53158ccee993e8491a1fffd466b
Author: tledkov-gridgain 
Date:   2017-09-21T13:29:24Z

IGNITE-6465: JDBC thin: set SQLSTATE for BatchUpdateException




> JDBC thin: SQLSTATE is not set for BatchUpdateException
> ---
>
> Key: IGNITE-6465
> URL: https://issues.apache.org/jira/browse/IGNITE-6465
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> Vendor code is propagated to {{BatchUpdateException}}, but {{SQLSTATE}} is 
> set to {{null}}.



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


[jira] [Created] (IGNITE-6466) Ignite PDS1: Test testGetForInitialWrite failed in IgnitePdsCheckpointSimulationWithRealCpDisabledTest

2017-09-21 Thread Dmitriy Pavlov (JIRA)
Dmitriy Pavlov created IGNITE-6466:
--

 Summary: Ignite PDS1: Test testGetForInitialWrite failed in 
IgnitePdsCheckpointSimulationWithRealCpDisabledTest 
 Key: IGNITE-6466
 URL: https://issues.apache.org/jira/browse/IGNITE-6466
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov
 Fix For: 2.3


Assertion in 
{noformat}
java.lang.AssertionError
at org.apache.ignite.internal.pagemem.PageUtils.getShort(PageUtils.java:94)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getPageEntrySize(DataPageIO.java:138)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.printPageLayout(DataPageIO.java:388)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.printPage(DataPageIO.java:1448)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.printPage(PageIO.java:571)
at 
org.apache.ignite.internal.pagemem.wal.record.PageSnapshot.toString(PageSnapshot.java:90)
at java.lang.String.valueOf(String.java:2849)
at 
org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testGetForInitialWrite(IgnitePdsCheckpointSimulationWithRealCpDisabledTest.java:275)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}



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


[jira] [Created] (IGNITE-6465) JDBC thin: SQLSTATE is not set for BatchUpdateException

2017-09-21 Thread Taras Ledkov (JIRA)
Taras Ledkov created IGNITE-6465:


 Summary: JDBC thin: SQLSTATE is not set for BatchUpdateException
 Key: IGNITE-6465
 URL: https://issues.apache.org/jira/browse/IGNITE-6465
 Project: Ignite
  Issue Type: Bug
  Components: jdbc
Affects Versions: 2.1
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.3


Vendor code is propagated to {{BatchUpdateException}}, but {{SQLSTATE}} is set 
to {{null}}.



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


[jira] [Commented] (IGNITE-5732) Provide API to test compatibility with old releases

2017-09-21 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov commented on IGNITE-5732:


[~daradurvs],  thank you. This simple test can help to indicate uncompatiblity 
problems very quickly after changes done by contributors. I look forward to 
include this test into 'Ignite 2.0 Tests' into '-> run all' chain on TC

Feel free to contact me if you need any help.

Link to related discussion at dev list: 
http://apache-ignite-developers.2346864.n4.nabble.com/Binary-compatibility-of-persistent-storage-td22419.html


> Provide API to test compatibility with old releases
> ---
>
> Key: IGNITE-5732
> URL: https://issues.apache.org/jira/browse/IGNITE-5732
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.3
>
>
> Need to provide an opportunity to test compatibility with old releases.
> The main idea is the method {code}startGrid(ver){code} in the testing 
> framework, which would start an instance via downloaded "jar" from the Maven 
> repo.



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


[jira] [Commented] (IGNITE-6434) Error in checkpointer during topology change

2017-09-21 Thread Eduard Shangareev (JIRA)

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

Eduard Shangareev commented on IGNITE-6434:
---

PR
https://github.com/apache/ignite/pull/2718

Test
https://ci.ignite.apache.org/viewQueued.html?itemId=844316

> Error in checkpointer during topology change
> 
>
> Key: IGNITE-6434
> URL: https://issues.apache.org/jira/browse/IGNITE-6434
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Critical
>
> {code}
> 2017-09-11 21:35:22.195 
> [ERROR][db-checkpoint-thread-#101%node1%][o.a.i.i.p.c.p.GridCacheDatabaseSharedManager]
>  Runtime error caught during grid runnable execution: GridWorker 
> [name=db-checkpoint-thread, igniteInstanceName=node1, finished=false, 
> hashCode=1326137503, interrupted=false, 
> runner=db-checkpoint-thread-#101%node1%]
> java.lang.IllegalStateException: Failed to add new partition to the 
> partitions state (no enough space reserved) [partId=459, reserved=459]
>   at 
> org.apache.ignite.internal.pagemem.wal.record.CacheState.addPartitionState(CacheState.java:50)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2189)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:1954)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:1879)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> ~[ignite-core-2.1.4.jar:2.1.4]
>   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_121]
> {code}
> After checkpoint thread died.



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


[jira] [Comment Edited] (IGNITE-5357) Replicated cache reads load balancing.

2017-09-21 Thread Mikhail Lipkovich (JIRA)

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

Mikhail Lipkovich edited comment on IGNITE-5357 at 9/21/17 12:53 PM:
-

Hi Alexei,
I'm working on this task but I faced with one question which I can't resolve. I 
found the piece of code that as I understand should be updated to resolve the 
task. But there is a {{canRemap}} flag which has an unclear meaning for me. 
Please find below method {{GridPartitionedSingleGetFuture#affinityNode}}:
{code}
if (!canRemap) {
for (ClusterNode node : affNodes) {
if (cctx.discovery().alive(node))
return node;
}

return null;
}
else
return affNodes.get(0);
{code}
It's commented that {{canRemap}} is a flag indicating that get should be done 
on a locked topology version but it's not clear for me how it is related to the 
piece of code above. Should I somehow take care about this flag during 
implementation of requested functionality or I can just ignore it?

Thanks


was (Author: mlipkovich):
Hi Alexei,
I'm working on this task but I faced with one question which I can't resolve. I 
found the piece of code that should be updated. But there is a {{canRemap}} 
flag which has an unclear meaning for me. Please find below method 
{{GridPartitionedSingleGetFuture#affinityNode}}:
{code}
if (!canRemap) {
for (ClusterNode node : affNodes) {
if (cctx.discovery().alive(node))
return node;
}

return null;
}
else
return affNodes.get(0);
{code}
It's commented that {{canRemap}} is a flag indicating that get should be done 
on a locked topology version but it's not clear for me how it is related to the 
piece of code above. Should I somehow take care about this flag during 
implementation of requested functionality or I can just ignore it?

Thanks

> Replicated cache reads load balancing.
> --
>
> Key: IGNITE-5357
> URL: https://issues.apache.org/jira/browse/IGNITE-5357
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Mikhail Lipkovich
>  Labels: newbie
> Fix For: 2.3
>
>
> Currently all read requests from client node to replicated cache will go 
> through primary node for key.
> Need to select random affinity node in topology and send request here (only 
> if readFromBackups=true)
> If where are server nodes collocated on same host with client, must select 
> target node from them.



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


[jira] [Comment Edited] (IGNITE-5357) Replicated cache reads load balancing.

2017-09-21 Thread Mikhail Lipkovich (JIRA)

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

Mikhail Lipkovich edited comment on IGNITE-5357 at 9/21/17 12:52 PM:
-

Hi Alexei,
I'm working on this task but I faced with one question which I can't resolve. I 
found the piece of code that should be updated. But there is a {{canRemap}} 
flag which has an unclear meaning for me. Please find below method 
{{GridPartitionedSingleGetFuture#affinityNode}}:
{code}
if (!canRemap) {
for (ClusterNode node : affNodes) {
if (cctx.discovery().alive(node))
return node;
}

return null;
}
else
return affNodes.get(0);
{code}
It's commented that {{canRemap}} is a flag indicating that get should be done 
on a locked topology version but it's not clear for me how it is related to the 
piece of code above. Should I somehow take care about this flag during 
implementation of requested functionality or I can just ignore it?

Thanks


was (Author: mlipkovich):
Hi Alexei,
I'm working on this task but I faced with one question which I can't resolve. 
There is a {{canRemap}} flag which has an unclear meaning for me. Here is the 
relevant piece of code that I'm going to change according to the task in 
{{GridPartitionedSingleGetFuture#affinityNode}}:
{code}
if (!canRemap) {
for (ClusterNode node : affNodes) {
if (cctx.discovery().alive(node))
return node;
}

return null;
}
else
return affNodes.get(0);
{code}
It's commented that {{canRemap}} is a flag indicating that get should be done 
on a locked topology version but it's not clear for my how is it related to 
piece of code above. Should I somehow take care about this flag during 
implementation of requested functionality or I can just ignore it?

Thanks

> Replicated cache reads load balancing.
> --
>
> Key: IGNITE-5357
> URL: https://issues.apache.org/jira/browse/IGNITE-5357
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Mikhail Lipkovich
>  Labels: newbie
> Fix For: 2.3
>
>
> Currently all read requests from client node to replicated cache will go 
> through primary node for key.
> Need to select random affinity node in topology and send request here (only 
> if readFromBackups=true)
> If where are server nodes collocated on same host with client, must select 
> target node from them.



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


[jira] [Updated] (IGNITE-6434) Error in checkpointer during topology change

2017-09-21 Thread Eduard Shangareev (JIRA)

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

Eduard Shangareev updated IGNITE-6434:
--
Summary: Error in checkpointer during topology change  (was: Assertion 
error in checkpointer during topology change)

> Error in checkpointer during topology change
> 
>
> Key: IGNITE-6434
> URL: https://issues.apache.org/jira/browse/IGNITE-6434
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Critical
>
> {code}
> 2017-09-11 21:35:22.195 
> [ERROR][db-checkpoint-thread-#101%node1%][o.a.i.i.p.c.p.GridCacheDatabaseSharedManager]
>  Runtime error caught during grid runnable execution: GridWorker 
> [name=db-checkpoint-thread, igniteInstanceName=node1, finished=false, 
> hashCode=1326137503, interrupted=false, 
> runner=db-checkpoint-thread-#101%node1%]
> java.lang.IllegalStateException: Failed to add new partition to the 
> partitions state (no enough space reserved) [partId=459, reserved=459]
>   at 
> org.apache.ignite.internal.pagemem.wal.record.CacheState.addPartitionState(CacheState.java:50)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2189)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:1954)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:1879)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> ~[ignite-core-2.1.4.jar:2.1.4]
>   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_121]
> {code}
> After checkpoint thread died.



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


[jira] [Commented] (IGNITE-5357) Replicated cache reads load balancing.

2017-09-21 Thread Mikhail Lipkovich (JIRA)

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

Mikhail Lipkovich commented on IGNITE-5357:
---

Hi Alexei,
I'm working on this task but I faced with one question which I can't resolve. 
There is a {{canRemap}} flag which has an unclear meaning for me. Here is the 
relevant piece of code that I'm going to change according to the task in 
{{GridPartitionedSingleGetFuture#affinityNode}}:
{code}
if (!canRemap) {
for (ClusterNode node : affNodes) {
if (cctx.discovery().alive(node))
return node;
}

return null;
}
else
return affNodes.get(0);
{code}
It's commented that {{canRemap}} is a flag indicating that get should be done 
on a locked topology version but it's not clear for my how is it related to 
piece of code above. Should I somehow take care about this flag during 
implementation of requested functionality or I can just ignore it?

Thanks

> Replicated cache reads load balancing.
> --
>
> Key: IGNITE-5357
> URL: https://issues.apache.org/jira/browse/IGNITE-5357
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Mikhail Lipkovich
>  Labels: newbie
> Fix For: 2.3
>
>
> Currently all read requests from client node to replicated cache will go 
> through primary node for key.
> Need to select random affinity node in topology and send request here (only 
> if readFromBackups=true)
> If where are server nodes collocated on same host with client, must select 
> target node from them.



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


[jira] [Comment Edited] (IGNITE-6334) Throttle writing threads during ongoing checkpoint with token bucket algorithm

2017-09-21 Thread Ivan Rakov (JIRA)

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

Ivan Rakov edited comment on IGNITE-6334 at 9/21/17 12:45 PM:
--

TC runs:
Throttling disabled by default (main pull request): 
https://ci.ignite.apache.org/viewQueued.html?itemId=844058
Throttling enabled by default: 
https://ci.ignite.apache.org/viewQueued.html?itemId=844143


was (Author: ivan.glukos):
TC runs:
Throttling disabled by default (main pull request): 
https://ci.ignite.apache.org/viewQueued.html?itemId=843348
Throttling enabled by default: 
https://ci.ignite.apache.org/viewQueued.html?itemId=843433

> Throttle writing threads during ongoing checkpoint with token bucket algorithm
> --
>
> Key: IGNITE-6334
> URL: https://issues.apache.org/jira/browse/IGNITE-6334
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.3
>
> Attachments: opsec3.jpg
>
>
> We've received several negative pieces of feedback about LFS performance with 
> enabled persistence. Ignite node stops responding to user operations under 
> intensive load. Typical operations/second graph is attached.
> Zero dropdowns happen during ongoing checkpoint when checkpoint buffer 
> (memory segment that accumulates old versions of dirty pages that are not yet 
> written in current checkpoint) is overflowed.
> In general, performance decrease is inevitable - writing in memory is always 
> faster than writing to disk. Though, we can avoid zero dropdowns if we'll 
> throttle threads that generate dirty pages.
> We can manage amount of throttle time with tocken bucket algorithm:
> 1) Before checkpoint start, we calculate ratio K = (number of checkpoint 
> pages) / (size of checkpoint buffer) and initialize non-negative atomic 
> marker counter
> 2) Every checkpointing thread increments marker counter once per K written 
> pages
> 3) Any thread that makes page dirty should decrement marker counter. Thread 
> should wait if marker counter is zero.
> Such algorithm makes buffer overflow impossible. If activity is intensive and 
> constant, user threads will write at the speed of the disk. On the other 
> hand, user threads will write at maximum speed in case of burst activity.



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


[jira] [Commented] (IGNITE-6454) Data structure suite timeout: test is not able to fail after interruption

2017-09-21 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov commented on IGNITE-6454:


Test runs with interrupted flag check still contains timeouts,
https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStructures_Ignite20Tests=pull%2F2704%2Fhead=buildTypeStatusDiv

Still failed by same test
-
 
GridCacheReplicatedDataStructuresFailoverSelfTest.testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe
 (Last started) 

> Data structure suite timeout: test is not able to fail after interruption
> -
>
> Key: IGNITE-6454
> URL: https://issues.apache.org/jira/browse/IGNITE-6454
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
> Attachments: 
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip,
>  
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv
> Most often timeout is caused by following tests:
> GridCacheReplicatedDataStructuresFailoverSelfTest
> - testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> - testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> And most of thread dumps contains the following
> {noformat}
> ] :[Step 4/5] Thread 
> [name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
>  id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.fillInStackTrace(Native Method)
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.fillInStackTrace(Throwable.java:783)
> [20:34:26] :   [Step 4/5] - locked o.a.i.IgniteException@754033e
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.(Throwable.java:265)
> [20:34:26] :   [Step 4/5] at 
> java.lang.Exception.(Exception.java:66)
> [20:34:26] :   [Step 4/5] at 
> java.lang.RuntimeException.(RuntimeException.java:62)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.IgniteException.(IgniteException.java:44)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [20:34:26] :   [Step 4/5] at 
> java.lang.reflect.Method.invoke(Method.java:606)
> [20:34:26] :   [Step 4/5] at 
> junit.framework.TestCase.runTest(TestCase.java:176)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> [20:34:26] :   [Step 4/5] at java.lang.Thread.run(Thread.java:745)
> [20:34:26] :   [Step 4/5] 
> {noformat}
> That can be indicator that threads are interrupted and flag 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl#interruptAll
>  is set,
> than org.apache.ignite.IgniteException is thrown, but it is ignored by test 
> and test continues to execute



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


[jira] [Commented] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

2017-09-21 Thread Taras Ledkov (JIRA)

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

Taras Ledkov commented on IGNITE-6448:
--

[~vozerov], the test for multi-node case is added. Tests are OK. Please review 
the changes.

> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.3
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   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)
> {noformat}
> 2. When I try to get all data from Person:
> {noformat}select * from person;{noformat}
> I get the table without new field but if try to get only this field from 
> table it works.



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


[jira] [Updated] (IGNITE-5817) Change checksum calculation methods

2017-09-21 Thread Aleksey Chetaev (JIRA)

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

Aleksey Chetaev updated IGNITE-5817:

Issue Type: Task  (was: Bug)

> Change checksum calculation methods
> ---
>
> Key: IGNITE-5817
> URL: https://issues.apache.org/jira/browse/IGNITE-5817
> Project: Ignite
>  Issue Type: Task
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
>Priority: Blocker
> Fix For: 2.3
>
>
> Neither sha1 nor md5 are trustful checksum calculation methods. We should be 
> switching to at least sha265 or higher.



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


[jira] [Commented] (IGNITE-6387) SQL: NOT NULL fields validation with read-through cache store

2017-09-21 Thread Sergey Kalashnikov (JIRA)

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

Sergey Kalashnikov commented on IGNITE-6387:


Added {{NOT NULL}} constraint validation for values read from cache store 
(read-through).  Such values are not put into cache, a debug record is put into 
log.

> SQL: NOT NULL fields validation with read-through cache store
> -
>
> Key: IGNITE-6387
> URL: https://issues.apache.org/jira/browse/IGNITE-6387
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> There is a case left unsolved during implementation of SQL NOT NULL 
> constraints feature.
> It may happen so that cache update operation fails and the value loaded from 
> store is put into cache.
> This value must also be validated with regards to configured NOT NULL 
> constraints.
> See {{CacheConfiguration.setCacheStoreFactory()}}, 
> {{CacheConfiguration.setReadThrough()}}, {{QueryEntity.setNotNullFields()}}



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


[jira] [Commented] (IGNITE-6294) ODBC: Propagate SQLSTATE error codes

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6294:


GitHub user isapego opened a pull request:

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

IGNITE-6294: ODBC: Propagated SQLSTATE error codes



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

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

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

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


commit 938df5246a5bd0d1421e034ea2b85632461a7b66
Author: Igor Sapego 
Date:   2017-09-19T15:43:16Z

IGNITE-6294: Implemented server-side

commit 79ee85907c428e7890d692ec63bbcfb01d9dafb7
Author: Igor Sapego 
Date:   2017-09-19T16:02:44Z

IGNITE-6294: Implemented protocol part

commit 7da364d81caf55de5c7997ca7f1624766a4786c0
Author: Igor Sapego 
Date:   2017-09-20T15:56:49Z

IGNITE-6294: Implemented error codes mapping

commit 41d6a00290c4e7f1165e5fa6d83453e7f6c38c8f
Author: Igor Sapego 
Date:   2017-09-20T15:58:10Z

IGNITE-6294: Test fixed.

commit 427d75410dfe5eade74aff4324eb6bf5bc1f4ec5
Author: Igor Sapego 
Date:   2017-09-20T16:07:21Z

IGNITE-6294: Changed error code on rejected connection.

commit 658684293c0a65c8bc4092fd97efc5e7832b8ab0
Author: Igor Sapego 
Date:   2017-09-21T11:45:32Z

IGNITE-6294: Improved connection failures handling




> ODBC: Propagate SQLSTATE error codes
> 
>
> Key: IGNITE-6294
> URL: https://issues.apache.org/jira/browse/IGNITE-6294
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> We should propagate SQLSTATE to ODBC usrs when it's server-side part is ready 
> [1].
> [1] IGNITE-5620



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


[jira] [Commented] (IGNITE-6457) Incorrect exception when used schema name in lower case

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6457:


Github user asfgit closed the pull request at:

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


> Incorrect exception when used schema name in lower case 
> 
>
> Key: IGNITE-6457
> URL: https://issues.apache.org/jira/browse/IGNITE-6457
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
> Environment: Cache configuration:
> {noformat}
> 
> 
> 
>  class="org.apache.ignite.configuration.CacheConfiguration">
> 
> 
> 
> 
> 
> 
> 
> {noformat}
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>  Labels: usability
> Fix For: 2.3
>
>
> Scenario:
> 1. Start 1 node
> 2. connect to node via sqlline (https://github.com/julianhyde/sqlline)
> {noformat} ./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1:10800/test{noformat}
> 3. Create table:
> {noformat}CREATE TABLE city1 (id LONG PRIMARY KEY, name VARCHAR);{noformat}
> Result:
> {noformat}
> [16:35:27,506][SEVERE][client-connector-#40%null%][JdbcRequestHandler] Failed 
> to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest [schemaName=test, 
> pageSize=1024, maxRows=0, sqlQry=CREATE TABLE city1 (id LONG PRIMARY KEY, 
> name VARCHAR), args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=test]
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:439)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForSchema(IgniteH2Indexing.java:356)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1287)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   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: org.h2.jdbc.JdbcSQLException: Schema "test" not found; SQL 
> statement:
> SET SCHEMA "test" [90079-195]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
>   at org.h2.message.DbException.get(DbException.java:179)
>   at org.h2.message.DbException.get(DbException.java:155)
>   at org.h2.engine.Database.getSchema(Database.java:1755)
>   at org.h2.command.dml.Set.update(Set.java:408)
>   at org.h2.command.CommandContainer.update(CommandContainer.java:101)
>   at org.h2.command.Command.executeUpdate(Command.java:260)
>   at 
> org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
>   at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)

[jira] [Commented] (IGNITE-6316) SQL: Add ALTER TABLE tests with persistence

2017-09-21 Thread Alexander Paschenko (JIRA)

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

Alexander Paschenko commented on IGNITE-6316:
-

[~vozerov]
1. When configuration is read from serialized {{StoredCacheData}}, it leads to 
an usual attempt to create cache. But, in this case, we already do have cache 
with same name in static configuration. And because we do, current internals 
logic ignores attempts to create caches with existing names. So this behavior 
is consistent with current state of things. However, it's doubtful whether such 
behavior is still correct since PDS has been introduced. Still, I believe it'd 
be more correct to fix this behavior in scope of a different issue/release.
2. All test failures I see are from flaky tests that fail in other branches too.
3. New clear re-run of all tests is on its way.

> SQL: Add ALTER TABLE tests with persistence
> ---
>
> Key: IGNITE-6316
> URL: https://issues.apache.org/jira/browse/IGNITE-6316
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>
> Scenario:
> 1) Start a node with persistence and pre-configured cache and {{QueryEntity}}
> 2) Add a column through {{ALTER TABLE}}
> 3) Restart the node
> 4) Make sure that new column is still there



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


[jira] [Closed] (IGNITE-6304) Visor CMD: Failed script execution after throttling interval

2017-09-21 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov closed IGNITE-6304.
--

> Visor CMD: Failed script execution after throttling interval
> 
>
> Key: IGNITE-6304
> URL: https://issues.apache.org/jira/browse/IGNITE-6304
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>
> To reproduce:
> 1) create alert
> 2) after alert triggered script is executed
> 3) after alert is gone and throttling interval is expire and alert was 
> triggered again the script doesn't execute



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


[jira] [Commented] (IGNITE-6304) Visor CMD: Failed script execution after throttling interval

2017-09-21 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov commented on IGNITE-6304:


Re-tested.

> Visor CMD: Failed script execution after throttling interval
> 
>
> Key: IGNITE-6304
> URL: https://issues.apache.org/jira/browse/IGNITE-6304
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>
> To reproduce:
> 1) create alert
> 2) after alert triggered script is executed
> 3) after alert is gone and throttling interval is expire and alert was 
> triggered again the script doesn't execute



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


[jira] [Updated] (IGNITE-6382) .NET: Set up NDepend analysis on TeamCity

2017-09-21 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn updated IGNITE-6382:
---
Description: 
NDepend provided 6 build machine licenses to Apache Ignite: 
https://svn.apache.org/repos/private/pmc/ignite/licenses/NDepend.txt

1) Install NDepend on Windows agents 
(https://www.ndepend.com/docs/teamcity-integration-ndepend)
2) Set up NDepend project, adjust rules
3) Add NDepend analysis to {{Platform .NET Inspections}}: 
https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgnitePlatformNetInspections
4) Update wiki with instructions: 
https://cwiki.apache.org/confluence/display/IGNITE/Ignite.NET+Development

  was:
NDepend provided 6 build machine licenses to Apache Ignite: 
https://svn.apache.org/repos/private/pmc/ignite/licenses/NDepend.txt

1) Install NDepend on Windows agents
2) Set up NDepend project, adjust rules
3) Add NDepend analysis to {{Platform .NET Inspections}}: 
https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgnitePlatformNetInspections
4) Update wiki with instructions: 
https://cwiki.apache.org/confluence/display/IGNITE/Ignite.NET+Development


> .NET: Set up NDepend analysis on TeamCity
> -
>
> Key: IGNITE-6382
> URL: https://issues.apache.org/jira/browse/IGNITE-6382
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
>
> NDepend provided 6 build machine licenses to Apache Ignite: 
> https://svn.apache.org/repos/private/pmc/ignite/licenses/NDepend.txt
> 1) Install NDepend on Windows agents 
> (https://www.ndepend.com/docs/teamcity-integration-ndepend)
> 2) Set up NDepend project, adjust rules
> 3) Add NDepend analysis to {{Platform .NET Inspections}}: 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgnitePlatformNetInspections
> 4) Update wiki with instructions: 
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite.NET+Development



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


[jira] [Assigned] (IGNITE-5357) Replicated cache reads load balancing.

2017-09-21 Thread Mikhail Lipkovich (JIRA)

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

Mikhail Lipkovich reassigned IGNITE-5357:
-

Assignee: Mikhail Lipkovich

> Replicated cache reads load balancing.
> --
>
> Key: IGNITE-5357
> URL: https://issues.apache.org/jira/browse/IGNITE-5357
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Mikhail Lipkovich
>  Labels: newbie
> Fix For: 2.3
>
>
> Currently all read requests from client node to replicated cache will go 
> through primary node for key.
> Need to select random affinity node in topology and send request here (only 
> if readFromBackups=true)
> If where are server nodes collocated on same host with client, must select 
> target node from them.



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


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

2017-09-21 Thread Andrey Gura (JIRA)

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

Andrey Gura reassigned IGNITE-5869:
---

Assignee: Stanilovsky Evgeny  (was: Andrey Gura)

> Unexpected timeout exception while client connecting 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
> Fix For: 2.3
>
> 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-6457) Incorrect exception when used schema name in lower case

2017-09-21 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-6457:
-

Test run: 
https://ci.ignite.apache.org/viewLog.html?buildId=843790=queuedBuildOverviewTab

> Incorrect exception when used schema name in lower case 
> 
>
> Key: IGNITE-6457
> URL: https://issues.apache.org/jira/browse/IGNITE-6457
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
> Environment: Cache configuration:
> {noformat}
> 
> 
> 
>  class="org.apache.ignite.configuration.CacheConfiguration">
> 
> 
> 
> 
> 
> 
> 
> {noformat}
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>  Labels: usability
> Fix For: 2.3
>
>
> Scenario:
> 1. Start 1 node
> 2. connect to node via sqlline (https://github.com/julianhyde/sqlline)
> {noformat} ./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1:10800/test{noformat}
> 3. Create table:
> {noformat}CREATE TABLE city1 (id LONG PRIMARY KEY, name VARCHAR);{noformat}
> Result:
> {noformat}
> [16:35:27,506][SEVERE][client-connector-#40%null%][JdbcRequestHandler] Failed 
> to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest [schemaName=test, 
> pageSize=1024, maxRows=0, sqlQry=CREATE TABLE city1 (id LONG PRIMARY KEY, 
> name VARCHAR), args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=test]
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:439)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForSchema(IgniteH2Indexing.java:356)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1287)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   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: org.h2.jdbc.JdbcSQLException: Schema "test" not found; SQL 
> statement:
> SET SCHEMA "test" [90079-195]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
>   at org.h2.message.DbException.get(DbException.java:179)
>   at org.h2.message.DbException.get(DbException.java:155)
>   at org.h2.engine.Database.getSchema(Database.java:1755)
>   at org.h2.command.dml.Set.update(Set.java:408)
>   at org.h2.command.CommandContainer.update(CommandContainer.java:101)
>   at org.h2.command.Command.executeUpdate(Command.java:260)
>   at 
> org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
>   at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
>   

[jira] [Commented] (IGNITE-6457) Incorrect exception when used schema name in lower case

2017-09-21 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-6457:
-

[~tledkov-gridgain], I did minor adjustements. Please review my commit.

> Incorrect exception when used schema name in lower case 
> 
>
> Key: IGNITE-6457
> URL: https://issues.apache.org/jira/browse/IGNITE-6457
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
> Environment: Cache configuration:
> {noformat}
> 
> 
> 
>  class="org.apache.ignite.configuration.CacheConfiguration">
> 
> 
> 
> 
> 
> 
> 
> {noformat}
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>  Labels: usability
> Fix For: 2.3
>
>
> Scenario:
> 1. Start 1 node
> 2. connect to node via sqlline (https://github.com/julianhyde/sqlline)
> {noformat} ./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1:10800/test{noformat}
> 3. Create table:
> {noformat}CREATE TABLE city1 (id LONG PRIMARY KEY, name VARCHAR);{noformat}
> Result:
> {noformat}
> [16:35:27,506][SEVERE][client-connector-#40%null%][JdbcRequestHandler] Failed 
> to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest [schemaName=test, 
> pageSize=1024, maxRows=0, sqlQry=CREATE TABLE city1 (id LONG PRIMARY KEY, 
> name VARCHAR), args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=test]
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:439)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForSchema(IgniteH2Indexing.java:356)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1287)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   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: org.h2.jdbc.JdbcSQLException: Schema "test" not found; SQL 
> statement:
> SET SCHEMA "test" [90079-195]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
>   at org.h2.message.DbException.get(DbException.java:179)
>   at org.h2.message.DbException.get(DbException.java:155)
>   at org.h2.engine.Database.getSchema(Database.java:1755)
>   at org.h2.command.dml.Set.update(Set.java:408)
>   at org.h2.command.CommandContainer.update(CommandContainer.java:101)
>   at org.h2.command.Command.executeUpdate(Command.java:260)
>   at 
> org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
>   at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
>   at 
> 

[jira] [Updated] (IGNITE-6210) Inefficient memory consumption for checkpoint buffer

2017-09-21 Thread Aleksey Chetaev (JIRA)

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

Aleksey Chetaev updated IGNITE-6210:

Summary: Inefficient memory consumption for checkpoint buffer  (was: 
inefficient memory consumption for checkpoint buffer)

> Inefficient memory consumption for checkpoint buffer
> 
>
> Key: IGNITE-6210
> URL: https://issues.apache.org/jira/browse/IGNITE-6210
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.3
>
>
> Current implementation allows configure checkpoint buffer size in 
> PersistentStoreConfiguration, but checkpoint buffer will be created for each 
> memory configuration with size equals the one indicated in 
> PersistentStoreConfiguration.
> For example:
> {code}
> PersistentStoreConfiguration prCfg = new 
> PersistentStoreConfiguration();
> prCfg.setCheckpointingFrequency(5L * 1024L * 1024L * 1024L); // 5GB.
> MemoryConfiguration memCfg = new MemoryConfiguration();
> MemoryPolicyConfiguration pl1 = new MemoryPolicyConfiguration();
> pl1.setMaxSize(100L * 1024L * 1024L); // 100 Mb.
> MemoryPolicyConfiguration pl2 = new MemoryPolicyConfiguration();
> pl2.setMaxSize(10L * 1024L * 1024L * 1024L); // 10GB.
> memCfg.setMemoryPolicies(pl1, pl2);
> {code}
> pl1(max size 10Gb) will be have checkpoint buffer = 5GB and pl2(max size 
> 100Mb) buffer= 5GB



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


[jira] [Commented] (IGNITE-6442) Deadlock detection doesn't execute.

2017-09-21 Thread Andrey Gura (JIRA)

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

Andrey Gura commented on IGNITE-6442:
-

And one more comment. It would be better if future will return 
{{GridNearTxPrepareResponse}} instead of chaining.

> Deadlock detection doesn't execute.
> ---
>
> Key: IGNITE-6442
> URL: https://issues.apache.org/jira/browse/IGNITE-6442
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
> Fix For: 2.3
>
>
> In case of a configuration with near cache and if all entities of one of the 
> transactions involved in the deadlock are on the node being the initiator of 
> this transaction, then immediately after the timeout, the transaction rolls 
> back (without calling DD).



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


[jira] [Updated] (IGNITE-6464) ignite.active() == true, but ignite.utilityCache() may return null

2017-09-21 Thread Dmitriy Govorukhin (JIRA)

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

Dmitriy Govorukhin updated IGNITE-6464:
---
Fix Version/s: 2.3

> ignite.active() == true, but ignite.utilityCache() may return null
> --
>
> Key: IGNITE-6464
> URL: https://issues.apache.org/jira/browse/IGNITE-6464
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Kuznetsov
>Assignee: Dmitriy Govorukhin
> Fix For: 2.3
>
>




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


[jira] [Commented] (IGNITE-898) Ignite does not starts from folder which name contains space

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-898:
---

GitHub user alexzaitzev opened a pull request:

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

IGNITE-898: Fixed error when path to Ignite folder contains whitespaces

Changes in build-classpath.sh fix the problem. setenv.sh was also changed 
to prevent problems with user libs

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

$ git pull https://github.com/alexzaitzev/ignite IGNITE-898

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

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


commit 1671c3676c20407b86f074925ec9f000389125d8
Author: alexzaitzev 
Date:   2017-09-21T09:17:44Z

Fixed error when path to ignite folder contains whitespaces




> Ignite does not starts from folder which name contains space
> 
>
> Key: IGNITE-898
> URL: https://issues.apache.org/jira/browse/IGNITE-898
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Aleksei Zaitsev
>Priority: Trivial
> Fix For: 2.3
>
>
> Observed:
> In case folder name contains space character Ignite node cannot be started.
> Expected:
> Ingine node should be startable even when folder name contains space 
> character.



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


[jira] [Comment Edited] (IGNITE-6463) Web console: Invalid result on query result with big number

2017-09-21 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko edited comment on IGNITE-6463 at 9/21/17 10:54 AM:
-

[~pkonstantinov]. Please test by scenario from description.


was (Author: vsisko):
Fixed parsing on big integer value from json to js object.
Attached demo project to put in cache big integer values.
# Open project and run *startup.ServerNodeCodeStartup.*
# Execute query in Web console: *SELECT * FROM "CountryCache".Country*

Big integer value showed in *population*. It should not contain 000 in the end 
of the values.


> Web console: Invalid result on query result with big number
> ---
>
> Key: IGNITE-6463
> URL: https://issues.apache.org/jira/browse/IGNITE-6463
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
> Attachments: bigIntReproducer.tar.gz
>
>
> Query result with big number values in cell cut that values.
> Attached demo project to put in cache big integer values.
> Open project and run *startup.ServerNodeCodeStartup*.
> Execute query in Web console: *SELECT * FROM "CountryCache".Country*
> Big integer value showed in *population*. It should not contain 000 in the 
> end of the values.



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


[jira] [Assigned] (IGNITE-6463) Web console: Invalid result on query result with big number

2017-09-21 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko reassigned IGNITE-6463:
-

Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

> Web console: Invalid result on query result with big number
> ---
>
> Key: IGNITE-6463
> URL: https://issues.apache.org/jira/browse/IGNITE-6463
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
> Attachments: bigIntReproducer.tar.gz
>
>
> Query result with big number values in cell cut that values.
> Attached demo project to put in cache big integer values.
> Open project and run *startup.ServerNodeCodeStartup*.
> Execute query in Web console: *SELECT * FROM "CountryCache".Country*
> Big integer value showed in *population*. It should not contain 000 in the 
> end of the values.



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


[jira] [Updated] (IGNITE-6463) Web console: Invalid result on query result with big number

2017-09-21 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko updated IGNITE-6463:
--
Description: 
Query result with big number values in cell cut that values.

Attached demo project to put in cache big integer values.

Open project and run *startup.ServerNodeCodeStartup*.
Execute query in Web console: *SELECT * FROM "CountryCache".Country*

Big integer value showed in *population*. It should not contain 000 in the end 
of the values.

  was:
Query result with big number values in cell cut that values.

Attached demo project to put in cache big integer values.

Open project and run startup.ServerNodeCodeStartup.
Execute query in Web console: SELECT * FROM "CountryCache".Country

Big integer value showed in population. It should not contain 000 in the end of 
the values.


> Web console: Invalid result on query result with big number
> ---
>
> Key: IGNITE-6463
> URL: https://issues.apache.org/jira/browse/IGNITE-6463
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
> Attachments: bigIntReproducer.tar.gz
>
>
> Query result with big number values in cell cut that values.
> Attached demo project to put in cache big integer values.
> Open project and run *startup.ServerNodeCodeStartup*.
> Execute query in Web console: *SELECT * FROM "CountryCache".Country*
> Big integer value showed in *population*. It should not contain 000 in the 
> end of the values.



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


[jira] [Updated] (IGNITE-6463) Web console: Invalid result on query result with big number

2017-09-21 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko updated IGNITE-6463:
--
Description: 
Query result with big number values in cell cut that values.

Attached demo project to put in cache big integer values.

Open project and run startup.ServerNodeCodeStartup.
Execute query in Web console: SELECT * FROM "CountryCache".Country

Big integer value showed in population. It should not contain 000 in the end of 
the values.

  was:Query result with big number values in cell cut that values.


> Web console: Invalid result on query result with big number
> ---
>
> Key: IGNITE-6463
> URL: https://issues.apache.org/jira/browse/IGNITE-6463
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
> Attachments: bigIntReproducer.tar.gz
>
>
> Query result with big number values in cell cut that values.
> Attached demo project to put in cache big integer values.
> Open project and run startup.ServerNodeCodeStartup.
> Execute query in Web console: SELECT * FROM "CountryCache".Country
> Big integer value showed in population. It should not contain 000 in the end 
> of the values.



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


[jira] [Assigned] (IGNITE-6463) Web console: Invalid result on query result with big number

2017-09-21 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko reassigned IGNITE-6463:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Web console: Invalid result on query result with big number
> ---
>
> Key: IGNITE-6463
> URL: https://issues.apache.org/jira/browse/IGNITE-6463
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
> Attachments: bigIntReproducer.tar.gz
>
>
> Query result with big number values in cell cut that values.



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


[jira] [Comment Edited] (IGNITE-6463) Web console: Invalid result on query result with big number

2017-09-21 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko edited comment on IGNITE-6463 at 9/21/17 10:46 AM:
-

Fixed parsing on big integer value from json to js object.
Attached demo project to put in cache big integer values.
# Open project and run *startup.ServerNodeCodeStartup.*
# Execute query in Web console: *SELECT * FROM "CountryCache".Country*

Big integer value showed in *population*. It should not contain 000 in the end 
of the values.



was (Author: vsisko):
Fixed parsing on big integer value from json to js object.
Attached demo project to put in cache big integer values.
# Open project and run *startup.ServerNodeCodeStartup.*
# Execute query in Web console: *SELECT * FROM "CountryCache".Country*

Big integer value showed in *population*. It does not should contain 000 in the 
end of the values.


> Web console: Invalid result on query result with big number
> ---
>
> Key: IGNITE-6463
> URL: https://issues.apache.org/jira/browse/IGNITE-6463
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 2.3
>
> Attachments: bigIntReproducer.tar.gz
>
>
> Query result with big number values in cell cut that values.



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


[jira] [Commented] (IGNITE-5732) Provide API to test compatibility with old releases

2017-09-21 Thread Vyacheslav Daradur (JIRA)

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

Vyacheslav Daradur commented on IGNITE-5732:


[~dpavlov], sorry for the delay with the answer.
Yes, the module is able to start node with enabled persistence.
Please have a look at 
[DummyPersistenceTest|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-268?filePath=/modules/compatibility/src/test/java/org/apache/ignite/compatibility/persistence/DummyPersistenceTest.java].

> Provide API to test compatibility with old releases
> ---
>
> Key: IGNITE-5732
> URL: https://issues.apache.org/jira/browse/IGNITE-5732
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.3
>
>
> Need to provide an opportunity to test compatibility with old releases.
> The main idea is the method {code}startGrid(ver){code} in the testing 
> framework, which would start an instance via downloaded "jar" from the Maven 
> repo.



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


[jira] [Commented] (IGNITE-6463) Web console: Invalid result on query result with big number

2017-09-21 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko commented on IGNITE-6463:
---

Fixed parsing on big integer value from json to js object.
Attached demo project to put in cache big integer values.
# Open project and run *startup.ServerNodeCodeStartup.*
# Execute query in Web console: *SELECT * FROM "CountryCache".Country*
Big integer value showed in *population*. It does not should contain 000 in the 
end of the values.


> Web console: Invalid result on query result with big number
> ---
>
> Key: IGNITE-6463
> URL: https://issues.apache.org/jira/browse/IGNITE-6463
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 2.3
>
> Attachments: bigIntReproducer.tar.gz
>
>
> Query result with big number values in cell cut that values.



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


[jira] [Comment Edited] (IGNITE-6463) Web console: Invalid result on query result with big number

2017-09-21 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko edited comment on IGNITE-6463 at 9/21/17 10:42 AM:
-

Fixed parsing on big integer value from json to js object.
Attached demo project to put in cache big integer values.
# Open project and run *startup.ServerNodeCodeStartup.*
# Execute query in Web console: *SELECT * FROM "CountryCache".Country*

Big integer value showed in *population*. It does not should contain 000 in the 
end of the values.



was (Author: vsisko):
Fixed parsing on big integer value from json to js object.
Attached demo project to put in cache big integer values.
# Open project and run *startup.ServerNodeCodeStartup.*
# Execute query in Web console: *SELECT * FROM "CountryCache".Country*
Big integer value showed in *population*. It does not should contain 000 in the 
end of the values.


> Web console: Invalid result on query result with big number
> ---
>
> Key: IGNITE-6463
> URL: https://issues.apache.org/jira/browse/IGNITE-6463
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 2.3
>
> Attachments: bigIntReproducer.tar.gz
>
>
> Query result with big number values in cell cut that values.



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


[jira] [Issue Comment Deleted] (IGNITE-5732) Provide API to test compatibility with old releases

2017-09-21 Thread Vyacheslav Daradur (JIRA)

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

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

(was: [~dpavlov] sorry for )

> Provide API to test compatibility with old releases
> ---
>
> Key: IGNITE-5732
> URL: https://issues.apache.org/jira/browse/IGNITE-5732
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.3
>
>
> Need to provide an opportunity to test compatibility with old releases.
> The main idea is the method {code}startGrid(ver){code} in the testing 
> framework, which would start an instance via downloaded "jar" from the Maven 
> repo.



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


[jira] [Commented] (IGNITE-5732) Provide API to test compatibility with old releases

2017-09-21 Thread Vyacheslav Daradur (JIRA)

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

Vyacheslav Daradur commented on IGNITE-5732:


[~dpavlov] sorry for 

> Provide API to test compatibility with old releases
> ---
>
> Key: IGNITE-5732
> URL: https://issues.apache.org/jira/browse/IGNITE-5732
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.3
>
>
> Need to provide an opportunity to test compatibility with old releases.
> The main idea is the method {code}startGrid(ver){code} in the testing 
> framework, which would start an instance via downloaded "jar" from the Maven 
> repo.



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


[jira] [Updated] (IGNITE-6463) Web console: Invalid result on query result with big number

2017-09-21 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko updated IGNITE-6463:
--
Attachment: bigIntReproducer.tar.gz

> Web console: Invalid result on query result with big number
> ---
>
> Key: IGNITE-6463
> URL: https://issues.apache.org/jira/browse/IGNITE-6463
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 2.3
>
> Attachments: bigIntReproducer.tar.gz
>
>
> Query result with big number values in cell cut that values.



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


[jira] [Comment Edited] (IGNITE-425) Introduce transformers for continuous queries

2017-09-21 Thread Nikolay Izhikov (JIRA)

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

Nikolay Izhikov edited comment on IGNITE-425 at 9/21/17 9:57 AM:
-

TC run on pull request merged with latest master - 
https://ci.ignite.apache.org/viewLog.html?buildId=843081

actual upsource review - 
https://reviews.ignite.apache.org/ignite/review/IGNT-CR-347


was (Author: nizhikov):
TC run on pull request merged with latest master - 
https://ci.ignite.apache.org/viewLog.html?buildId=843081

> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
>
> Currently if updated entry passes the filter, it is sent to node initiated 
> the query entirely. It would be good to provide user with the ability to 
> transform entry and, for example, select only fields that are important. This 
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer 
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} // 
> Probably, we will have to introduce new listener type, since user may want to 
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}



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


[jira] [Created] (IGNITE-6463) Web console: Invalid result on query result with big number

2017-09-21 Thread Vasiliy Sisko (JIRA)
Vasiliy Sisko created IGNITE-6463:
-

 Summary: Web console: Invalid result on query result with big 
number
 Key: IGNITE-6463
 URL: https://issues.apache.org/jira/browse/IGNITE-6463
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.1
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko
 Fix For: 2.3


Query result with big number values in cell cut that values.



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


[jira] [Commented] (IGNITE-425) Introduce transformers for continuous queries

2017-09-21 Thread Nikolay Izhikov (JIRA)

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

Nikolay Izhikov commented on IGNITE-425:


TC run on pull request merged with latest master - 
https://ci.ignite.apache.org/viewLog.html?buildId=843081

> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
>
> Currently if updated entry passes the filter, it is sent to node initiated 
> the query entirely. It would be good to provide user with the ability to 
> transform entry and, for example, select only fields that are important. This 
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer 
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} // 
> Probably, we will have to introduce new listener type, since user may want to 
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}



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


[jira] [Closed] (IGNITE-6446) Stuck on "Loading" screen

2017-09-21 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov closed IGNITE-6446.
--

> Stuck on "Loading" screen
> -
>
> Key: IGNITE-6446
> URL: https://issues.apache.org/jira/browse/IGNITE-6446
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>
> *What happens:*
> Web console gets stuck in loading screen when user opens any URL without 
> prior app navigation and any permission check or HTTP request fails due to 
> missing/expired authorization cookie.
> *How to reproduce:*
> 1. Log out of web console or open private browser tab.
> 2. Go to http://locahost:9000/configuration/basic
> *What should happen:*
> User should be redirected to either 403 or signin screen.



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


[jira] [Commented] (IGNITE-6446) Stuck on "Loading" screen

2017-09-21 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov commented on IGNITE-6446:


Re-tested. Closed.

> Stuck on "Loading" screen
> -
>
> Key: IGNITE-6446
> URL: https://issues.apache.org/jira/browse/IGNITE-6446
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>
> *What happens:*
> Web console gets stuck in loading screen when user opens any URL without 
> prior app navigation and any permission check or HTTP request fails due to 
> missing/expired authorization cookie.
> *How to reproduce:*
> 1. Log out of web console or open private browser tab.
> 2. Go to http://locahost:9000/configuration/basic
> *What should happen:*
> User should be redirected to either 403 or signin screen.



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


[jira] [Closed] (IGNITE-6095) Web console: In demo mode Implement configuration of key fields in domain model for SQL query

2017-09-21 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov closed IGNITE-6095.
--

> Web console: In demo mode Implement configuration of key fields in domain 
> model for SQL query
> -
>
> Key: IGNITE-6095
> URL: https://issues.apache.org/jira/browse/IGNITE-6095
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.3
>
>




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


[jira] [Commented] (IGNITE-995) Nodes on one host doesn't discover each other if IP finder doesn't explicitly provide port

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-995:
---

GitHub user mlipkovich opened a pull request:

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

IGNITE-995: Discover all ports from the range



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

$ git pull https://github.com/mlipkovich/ignite ignite-995-fix

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

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


commit 49d2b8c1e4e8e61b7bc5af27db4e789e78a37964
Author: Mikhail Lipkovich 
Date:   2017-09-21T09:02:31Z

IGNITE-995: Discover all ports from the range




> Nodes on one host doesn't discover each other if IP finder doesn't explicitly 
> provide port
> --
>
> Key: IGNITE-995
> URL: https://issues.apache.org/jira/browse/IGNITE-995
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Mikhail Lipkovich
>Priority: Minor
>  Labels: Usability, newbie
>




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


[jira] [Commented] (IGNITE-6095) Web console: In demo mode Implement configuration of key fields in domain model for SQL query

2017-09-21 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov commented on IGNITE-6095:


Re-tested.

> Web console: In demo mode Implement configuration of key fields in domain 
> model for SQL query
> -
>
> Key: IGNITE-6095
> URL: https://issues.apache.org/jira/browse/IGNITE-6095
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.3
>
>




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


[jira] [Commented] (IGNITE-6457) Incorrect exception when used schema name in lower case

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6457:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-6457: support schema case conversion at the JDBC thin driver c…

…onnection URL.

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

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

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

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


commit 6d2d901319d41bf03c38dbfa89443ed0c2ed117d
Author: tledkov-gridgain 
Date:   2017-09-21T08:51:11Z

IGNITE-6457: support schema case conversion at the JDBC thin driver 
connection URL.




> Incorrect exception when used schema name in lower case 
> 
>
> Key: IGNITE-6457
> URL: https://issues.apache.org/jira/browse/IGNITE-6457
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
> Environment: Cache configuration:
> {noformat}
> 
> 
> 
>  class="org.apache.ignite.configuration.CacheConfiguration">
> 
> 
> 
> 
> 
> 
> 
> {noformat}
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>  Labels: usability
> Fix For: 2.3
>
>
> Scenario:
> 1. Start 1 node
> 2. connect to node via sqlline (https://github.com/julianhyde/sqlline)
> {noformat} ./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1:10800/test{noformat}
> 3. Create table:
> {noformat}CREATE TABLE city1 (id LONG PRIMARY KEY, name VARCHAR);{noformat}
> Result:
> {noformat}
> [16:35:27,506][SEVERE][client-connector-#40%null%][JdbcRequestHandler] Failed 
> to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest [schemaName=test, 
> pageSize=1024, maxRows=0, sqlQry=CREATE TABLE city1 (id LONG PRIMARY KEY, 
> name VARCHAR), args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=test]
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:439)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForSchema(IgniteH2Indexing.java:356)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1287)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   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)
> 

[jira] [Commented] (IGNITE-6376) Web console: Enable task and job events in demo mode by default.

2017-09-21 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov commented on IGNITE-6376:


Tested.

> Web console: Enable task and job events in demo mode by default.
> 
>
> Key: IGNITE-6376
> URL: https://issues.apache.org/jira/browse/IGNITE-6376
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




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


[jira] [Commented] (IGNITE-6334) Throttle writing threads during ongoing checkpoint with token bucket algorithm

2017-09-21 Thread Ivan Rakov (JIRA)

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

Ivan Rakov commented on IGNITE-6334:


TC runs:
Throttling disabled by default (main pull request): 
https://ci.ignite.apache.org/viewQueued.html?itemId=843348
Throttling enabled by default: 
https://ci.ignite.apache.org/viewQueued.html?itemId=843433

> Throttle writing threads during ongoing checkpoint with token bucket algorithm
> --
>
> Key: IGNITE-6334
> URL: https://issues.apache.org/jira/browse/IGNITE-6334
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.3
>
> Attachments: opsec3.jpg
>
>
> We've received several negative pieces of feedback about LFS performance with 
> enabled persistence. Ignite node stops responding to user operations under 
> intensive load. Typical operations/second graph is attached.
> Zero dropdowns happen during ongoing checkpoint when checkpoint buffer 
> (memory segment that accumulates old versions of dirty pages that are not yet 
> written in current checkpoint) is overflowed.
> In general, performance decrease is inevitable - writing in memory is always 
> faster than writing to disk. Though, we can avoid zero dropdowns if we'll 
> throttle threads that generate dirty pages.
> We can manage amount of throttle time with tocken bucket algorithm:
> 1) Before checkpoint start, we calculate ratio K = (number of checkpoint 
> pages) / (size of checkpoint buffer) and initialize non-negative atomic 
> marker counter
> 2) Every checkpointing thread increments marker counter once per K written 
> pages
> 3) Any thread that makes page dirty should decrement marker counter. Thread 
> should wait if marker counter is zero.
> Such algorithm makes buffer overflow impossible. If activity is intensive and 
> constant, user threads will write at the speed of the disk. On the other 
> hand, user threads will write at maximum speed in case of burst activity.



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


[jira] [Commented] (IGNITE-6334) Throttle writing threads during ongoing checkpoint with token bucket algorithm

2017-09-21 Thread Ivan Rakov (JIRA)

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

Ivan Rakov commented on IGNITE-6334:


Please, review.

> Throttle writing threads during ongoing checkpoint with token bucket algorithm
> --
>
> Key: IGNITE-6334
> URL: https://issues.apache.org/jira/browse/IGNITE-6334
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.3
>
> Attachments: opsec3.jpg
>
>
> We've received several negative pieces of feedback about LFS performance with 
> enabled persistence. Ignite node stops responding to user operations under 
> intensive load. Typical operations/second graph is attached.
> Zero dropdowns happen during ongoing checkpoint when checkpoint buffer 
> (memory segment that accumulates old versions of dirty pages that are not yet 
> written in current checkpoint) is overflowed.
> In general, performance decrease is inevitable - writing in memory is always 
> faster than writing to disk. Though, we can avoid zero dropdowns if we'll 
> throttle threads that generate dirty pages.
> We can manage amount of throttle time with tocken bucket algorithm:
> 1) Before checkpoint start, we calculate ratio K = (number of checkpoint 
> pages) / (size of checkpoint buffer) and initialize non-negative atomic 
> marker counter
> 2) Every checkpointing thread increments marker counter once per K written 
> pages
> 3) Any thread that makes page dirty should decrement marker counter. Thread 
> should wait if marker counter is zero.
> Such algorithm makes buffer overflow impossible. If activity is intensive and 
> constant, user threads will write at the speed of the disk. On the other 
> hand, user threads will write at maximum speed in case of burst activity.



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


[jira] [Commented] (IGNITE-6334) Throttle writing threads during ongoing checkpoint with token bucket algorithm

2017-09-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6334:


GitHub user glukos opened a pull request:

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

IGNITE-6334 Throttle writing threads during ongoing checkpoint



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

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

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

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


commit cc8cc25a81dc98f02212dd6b499b5e030426d0dd
Author: Ivan Rakov 
Date:   2017-09-21T08:16:00Z

IGNITE-6334 Throttle writing threads during ongoing checkpoint with token 
bucket algorithm




> Throttle writing threads during ongoing checkpoint with token bucket algorithm
> --
>
> Key: IGNITE-6334
> URL: https://issues.apache.org/jira/browse/IGNITE-6334
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.3
>
> Attachments: opsec3.jpg
>
>
> We've received several negative pieces of feedback about LFS performance with 
> enabled persistence. Ignite node stops responding to user operations under 
> intensive load. Typical operations/second graph is attached.
> Zero dropdowns happen during ongoing checkpoint when checkpoint buffer 
> (memory segment that accumulates old versions of dirty pages that are not yet 
> written in current checkpoint) is overflowed.
> In general, performance decrease is inevitable - writing in memory is always 
> faster than writing to disk. Though, we can avoid zero dropdowns if we'll 
> throttle threads that generate dirty pages.
> We can manage amount of throttle time with tocken bucket algorithm:
> 1) Before checkpoint start, we calculate ratio K = (number of checkpoint 
> pages) / (size of checkpoint buffer) and initialize non-negative atomic 
> marker counter
> 2) Every checkpointing thread increments marker counter once per K written 
> pages
> 3) Any thread that makes page dirty should decrement marker counter. Thread 
> should wait if marker counter is zero.
> Such algorithm makes buffer overflow impossible. If activity is intensive and 
> constant, user threads will write at the speed of the disk. On the other 
> hand, user threads will write at maximum speed in case of burst activity.



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


  1   2   >