[jira] [Commented] (IGNITE-12319) Nested Transaction support in Ignite

2019-10-23 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-12319:
-

[~rajeshn], yep, there is a difference. I thought about _nested_ transactions 
as described in 
[Spring|https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Propagation.html].

Will {{org.apache.ignite.transactions.Transaction.suspend/resume}} do the 
trick? Pay attention that _pessimistic_ transaction support was not released 
yet (targeted to 2.8) IGNITE-5714

> Nested Transaction support in Ignite
> 
>
> Key: IGNITE-12319
> URL: https://issues.apache.org/jira/browse/IGNITE-12319
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: Rajesh
>Priority: Major
>
> There is no support for Nested transaction. For example, if there is an outer 
> transaction which works on few caches and within that there is a transaction 
> which is opened by a third party client to update their caches then it throws 
> exception as current thread already has the transaction.
> This scenario is encountered multiple times where the inner transaction needs 
> to be committed on success of inner transaction even if the outer transaction 
> fails.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12319) Nested Transaction support in Ignite

2019-10-23 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-12319:
-

[~rajeshn], sorry.  I inserted wrong ticket, I meant IGNITE-4188.

> Nested Transaction support in Ignite
> 
>
> Key: IGNITE-12319
> URL: https://issues.apache.org/jira/browse/IGNITE-12319
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: Rajesh
>Priority: Major
>
> There is no support for Nested transaction. For example, if there is an outer 
> transaction which works on few caches and within that there is a transaction 
> which is opened by a third party client to update their caches then it throws 
> exception as current thread already has the transaction.
> This scenario is encountered multiple times where the inner transaction needs 
> to be committed on success of inner transaction even if the outer transaction 
> fails.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-10-22 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-7285:


[~samaitra], I left some comments related to tests.

> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 8h 10m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-10-22 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-7285:


[~ptupitsyn], could you please check that everything is ok in .NET part?

> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 8h 10m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12319) Nested Transaction support in Ignite

2019-10-22 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-12319:
-

[~rajeshn], does not this ticket duplicate IGNITE-12319?

> Nested Transaction support in Ignite
> 
>
> Key: IGNITE-12319
> URL: https://issues.apache.org/jira/browse/IGNITE-12319
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: Rajesh
>Priority: Major
>
> There is no support for Nested transaction. For example, if there is an outer 
> transaction which works on few caches and within that there is a transaction 
> which is opened by a third party client to update their caches then it throws 
> exception as current thread already has the transaction.
> This scenario is encountered multiple times where the inner transaction needs 
> to be committed on success of inner transaction even if the outer transaction 
> fails.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-10-14 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-7285:


[~samaitra], sorry for a delay. I left my 
[comments|https://github.com/apache/ignite/pull/6490#pullrequestreview-301331326]
 on GitHub.

> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12281) Data search from Ignite Cache value object

2019-10-11 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-12281:
-

Hi [~rsangwan],

I suggest you to forward your question to Ignite community users mailing list. 
In a such way there will be more visibility and chances to get the answer. 
Please check https://ignite.apache.org/community/resources.html to access 
user-list.

Meanwhile you can search about Ignite SQL. Following example could be a good 
starting point.

> Data search from Ignite Cache value object
> --
>
> Key: IGNITE-12281
> URL: https://issues.apache.org/jira/browse/IGNITE-12281
> Project: Ignite
>  Issue Type: Wish
>Reporter: ROHIT SANGWAN
>Priority: Major
>
> Hi Team,
>  
> I am solution for data look up from Ignite cache value. I found multiple 
> operation where I can use key to get the value. But I have a use case where I 
> want to apply search on few attributes of value on a certain cache. I tried 
> scan query but its very costly operation. Please help me to find a effective 
> solution.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12266) Add limit parameter to Platforms for processing TextQuery

2019-10-07 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-12266:
-

[~Yuriy_Shuliha], could you please fill in a ticket description? We strive to 
create tickets ready to be taken for development by any community member. 
Usually a ticket description helps with it.

> Add limit parameter to Platforms for processing TextQuery
> -
>
> Key: IGNITE-12266
> URL: https://issues.apache.org/jira/browse/IGNITE-12266
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Yuriy Shuliha 
>Assignee: Yuriy Shuliha 
>Priority: Major
> Fix For: 2.8
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12265) JavaDoc doesn't have documentation for the org.apache.ignite.client package

2019-10-07 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin updated IGNITE-12265:

Labels: newbie  (was: )

> JavaDoc doesn't have documentation for the org.apache.ignite.client package
> ---
>
> Key: IGNITE-12265
> URL: https://issues.apache.org/jira/browse/IGNITE-12265
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Mekhanikov
>Priority: Major
>  Labels: newbie
>
> JavaDoc published on the website doesn't have documentation for the 
> {{org.apache.ignite.client}} package. Link to the website: 
> [https://ignite.apache.org/releases/2.7.6/javadoc/]
> A lack of {{package-info.java}} file or exclusion from the 
> {{maven-javadoc-plugin}} in the root {{pom.xml}} may be the reason.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12265) JavaDoc doesn't have documentation for the org.apache.ignite.client package

2019-10-07 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin updated IGNITE-12265:

Labels: newbi  (was: )

> JavaDoc doesn't have documentation for the org.apache.ignite.client package
> ---
>
> Key: IGNITE-12265
> URL: https://issues.apache.org/jira/browse/IGNITE-12265
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Mekhanikov
>Priority: Major
>  Labels: newbi
>
> JavaDoc published on the website doesn't have documentation for the 
> {{org.apache.ignite.client}} package. Link to the website: 
> [https://ignite.apache.org/releases/2.7.6/javadoc/]
> A lack of {{package-info.java}} file or exclusion from the 
> {{maven-javadoc-plugin}} in the root {{pom.xml}} may be the reason.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12265) JavaDoc doesn't have documentation for the org.apache.ignite.client package

2019-10-07 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin updated IGNITE-12265:

Labels:   (was: newbi)

> JavaDoc doesn't have documentation for the org.apache.ignite.client package
> ---
>
> Key: IGNITE-12265
> URL: https://issues.apache.org/jira/browse/IGNITE-12265
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Mekhanikov
>Priority: Major
>
> JavaDoc published on the website doesn't have documentation for the 
> {{org.apache.ignite.client}} package. Link to the website: 
> [https://ignite.apache.org/releases/2.7.6/javadoc/]
> A lack of {{package-info.java}} file or exclusion from the 
> {{maven-javadoc-plugin}} in the root {{pom.xml}} may be the reason.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-11829) Distribute joins fail if number of tables > 7

2019-10-01 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin updated IGNITE-11829:

Fix Version/s: 2.8

> Distribute joins fail if number of tables > 7
> -
>
> Key: IGNITE-11829
> URL: https://issues.apache.org/jira/browse/IGNITE-11829
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.7
>Reporter: Stanislav Lukyanov
>Assignee: Diana Iakovleva
>Priority: Major
>  Labels: newbie
> Fix For: 2.8
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Distributed joins fail with ArrayIndexOutOfBounds when the total number of 
> tables is > 7.
> Example:
> {code}
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml");) {
> IgniteCache cache = ignite.createCache("foo");
> cache.query(new SqlFieldsQuery("CREATE TABLE Person(ID INTEGER 
> PRIMARY KEY, NAME VARCHAR(100));"));
> cache.query(new SqlFieldsQuery("INSERT INTO Person(ID, NAME) 
> VALUES (1, 'Ed'), (2, 'Ann'), (3, 'Emma');"));
> cache.query(new SqlFieldsQuery("SELECT *\n" +
> "FROM PERSON P1\n" +
> "JOIN PERSON P2 ON P1.ID = P2.ID\n" +
> "JOIN PERSON P3 ON P1.ID = P3.ID\n" +
> "JOIN PERSON P4 ON P1.ID = P4.ID\n" +
> "JOIN PERSON P5 ON P1.ID = P5.ID\n" +
> "JOIN PERSON P6 ON P1.ID = P6.ID\n" +
> "JOIN PERSON P7 ON P1.ID = P7.ID\n" +
> "JOIN PERSON P8 ON P1.ID = 
> P8.ID").setDistributedJoins(true).setEnforceJoinOrder(false));
> }
> {code}
> throws
> {code}
> Exception in thread "main" javax.cache.CacheException: General error: 
> "java.lang.ArrayIndexOutOfBoundsException" [5-197]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:832)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:765)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:403)
>   at 
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:60)
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException: General 
> error: "java.lang.ArrayIndexOutOfBoundsException" [5-197]
>   at 
> org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:454)
>   at 
> org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:156)
>   at 
> org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:121)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1191)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2261)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2257)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:53)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2767)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2277)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2297)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2250)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2177)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:817)
>   ... 3 more
> Caused by: org.h2.jdbc.JdbcSQLException: General error: 
> "java.lang.ArrayIndexOutOfBoundsException" [5-197]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
>   at org.h2.message.DbException.get(DbException.java:168)
>   at org.h2.message.DbException.convert(DbException.java:307)
>   at org.h2.message.DbException.toSQLException(DbException.java:280)
>   at org.h2.message.TraceObject.logAndConvert(TraceObject.java:357)
>   at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:308)
>   at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.prepare(GridSqlQuerySplitter.java:1770)
>   at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split0(GridSqlQuerySplitter.java:299)
>   at 
> 

[jira] [Updated] (IGNITE-12190) Throw an exception for enabled text queries on persistent caches

2019-10-01 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin updated IGNITE-12190:

Description: As TEXT queries cannot be used with persistent caches we 
should throw a meaningful exception when a TEXT query is executed against a 
persistent cache.

> Throw an exception for enabled text queries on persistent caches
> 
>
> Key: IGNITE-12190
> URL: https://issues.apache.org/jira/browse/IGNITE-12190
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Reporter: Yuriy Shuliha 
>Assignee: Yuriy Shuliha 
>Priority: Major
> Fix For: 2.8
>
>
> As TEXT queries cannot be used with persistent caches we should throw a 
> meaningful exception when a TEXT query is executed against a persistent cache.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12190) Throw an exception for enabled text queries on persistent caches

2019-10-01 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin updated IGNITE-12190:

Component/s: (was: general)
 sql
 cache

> Throw an exception for enabled text queries on persistent caches
> 
>
> Key: IGNITE-12190
> URL: https://issues.apache.org/jira/browse/IGNITE-12190
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Reporter: Yuriy Shuliha 
>Assignee: Yuriy Shuliha 
>Priority: Major
> Fix For: 2.8
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-11125) Use alternative column instead of special _key for indexes.

2019-09-30 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin reassigned IGNITE-11125:
---

Assignee: (was: Ivan Pavlukhin)

> Use alternative column instead of special _key for indexes.
> ---
>
> Key: IGNITE-11125
> URL: https://issues.apache.org/jira/browse/IGNITE-11125
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we can have the same columns for sorted inline indexes twice 
> because in part cases use alternative columns for another case special column 
> _key.  To avoid duplicate the same columns need to use alternative columns 
> (real columns) always.
>  
> For example for 
> CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY 
> (ID1 DESC, ID2))
>  CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC)
>  
> will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, *_KEY*   instead 
> of ID2 DESC, ID1, MY_VAL DESC
>  
>  
> The task may be better to do together with 
> [IGNITE-11250|https://issues.apache.org/jira/browse/IGNITE-11250], due to, 
> seems, both of them required compatibility changes. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-11125) Use alternative column instead of special _key for indexes.

2019-09-30 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin reassigned IGNITE-11125:
---

Assignee: Ivan Pavlukhin

> Use alternative column instead of special _key for indexes.
> ---
>
> Key: IGNITE-11125
> URL: https://issues.apache.org/jira/browse/IGNITE-11125
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we can have the same columns for sorted inline indexes twice 
> because in part cases use alternative columns for another case special column 
> _key.  To avoid duplicate the same columns need to use alternative columns 
> (real columns) always.
>  
> For example for 
> CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY 
> (ID1 DESC, ID2))
>  CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC)
>  
> will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, *_KEY*   instead 
> of ID2 DESC, ID1, MY_VAL DESC
>  
>  
> The task may be better to do together with 
> [IGNITE-11250|https://issues.apache.org/jira/browse/IGNITE-11250], due to, 
> seems, both of them required compatibility changes. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-11125) Use alternative column instead of special _key for indexes.

2019-09-30 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin reassigned IGNITE-11125:
---

Assignee: (was: Yury Gerzhedovich)

> Use alternative column instead of special _key for indexes.
> ---
>
> Key: IGNITE-11125
> URL: https://issues.apache.org/jira/browse/IGNITE-11125
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we can have the same columns for sorted inline indexes twice 
> because in part cases use alternative columns for another case special column 
> _key.  To avoid duplicate the same columns need to use alternative columns 
> (real columns) always.
>  
> For example for 
> CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY 
> (ID1 DESC, ID2))
>  CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC)
>  
> will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, *_KEY*   instead 
> of ID2 DESC, ID1, MY_VAL DESC
>  
>  
> The task may be better to do together with 
> [IGNITE-11250|https://issues.apache.org/jira/browse/IGNITE-11250], due to, 
> seems, both of them required compatibility changes. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12201) distributed sql join not working as mentioned in documentation

2019-09-30 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-12201:
-

Hi [~shm],

I suppose that a confusing term in 
[documentation|https://apacheignite-sql.readme.io/docs/distributed-joins] is 
_cross-table joins_. In test coverage we have a test checking that CROSS JOIN 
with distributedJoins=true throws an exception. And seems that it is impossible 
to setup indexes for CROSS JOIN. Otherwise you need N-1 replicated tables.

> distributed sql join not working as mentioned in documentation
> --
>
> Key: IGNITE-12201
> URL: https://issues.apache.org/jira/browse/IGNITE-12201
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7
> Environment: Kubernetes on RHEL 7.6
>Reporter: shivakumar
>Priority: Major
> Attachments: distributed_sql_error.txt
>
>
> I am trying to do a simple cross join on two tables with non-collocated data 
> (without affinity key), 
> This non-collocated distributed join always fails with the error message:
>  
> *"java.sql.SQLException: javax.cache.CacheException: Failed to prepare 
> distributed join query: join condition does not use index "*
>  
> If I create one of the tables in replicated mode and another one in 
> partitioned mode this Join operation works but documentation mentions that 
> Ignite supports non-collocated joins without any condition.
> And we tried with 3 tables and 1 in replicated and other 2 in partitioned 
> then we observed that it failed.
> we are running the Join operations with *distributedJoins=true.*
> *We observed that if there are N tables in Join operation then (N-1) should 
> be in replicated mode, is our understanding right?*
> *If our understanding is correct then to do Join operation the dimensioning 
> of cluster increases by many folds which can't be used in a production 
> environment.*
> *To reproduce:*
> *Ignite with 4 node cluster with native persistence enabled.*
> *create the following tables*
> {quote} {{CREATE TABLE City (}}{quote}
> {quote} {{  id LONG PRIMARY KEY, name VARCHAR)}}{quote}
> {quote} {{  WITH "backup=1";}}{quote}
> {quote} {{}}{quote}
> {quote} {{CREATE TABLE Person (}}
>  {{  id LONG, name VARCHAR, city_id LONG, PRIMARY KEY (id, city_id))}}
>  {{  WITH "backups=1";}}
>  {{}}
>  {{CREATE INDEX idx_city_name ON City (name);}}
>  {{}}
>  {{CREATE INDEX idx_person_name ON Person (name);}}
>  
>  {{INSERT INTO City (id, name) VALUES (1, 'Forest Hill');}}
>  {{INSERT INTO City (id, name) VALUES (2, 'Denver');}}
>  {{INSERT INTO City (id, name) VALUES (3, 'St. Petersburg');}}
>  {{}}
>  {{INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);}}
>  {{INSERT INTO Person (id, name, city_id) VALUES (2, 'Jane Roe', 2);}}
>  {{INSERT INTO Person (id, name, city_id) VALUES (3, 'Mary Major', 1);}}
>  {{INSERT INTO Person (id, name, city_id) VALUES (4, 'Richard Miles', 2);}} {{
> }}{quote}
> Query to be run:
> {quote}select * from City c, Person p;{color:#66}
> {color}{quote}
> {quote}or 
> {color:#80}*SELECT*{color} * *{color:#80}FROM{color}* City 
> *{color:#80}AS{color}* c *{color:#80}CROSS{color}* 
> *{color:#80}join{color}* Person *{color:#80}AS{color}* p;{quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12230) Partition eviction during cache stop / deactivation may cause errors leading to node failure and storage corruption

2019-09-25 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-12230:
-

[~mstepachev], what do you think is this issues related to IGNITE-11996 ?

> Partition eviction during cache stop / deactivation may cause errors leading 
> to node failure and storage corruption
> ---
>
> Key: IGNITE-12230
> URL: https://issues.apache.org/jira/browse/IGNITE-12230
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> PartitionEvictionTask may produce NullPointerException if cache / cache group 
> / cluser is stopping / deactivating.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-12230) Partition eviction during cache stop / deactivation may cause errors leading to node failure and storage corruption

2019-09-25 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin edited comment on IGNITE-12230 at 9/25/19 12:08 PM:
---

[~mstepachev], what do you think is this issue related to IGNITE-11996 ?


was (Author: pavlukhin):
[~mstepachev], what do you think is this issues related to IGNITE-11996 ?

> Partition eviction during cache stop / deactivation may cause errors leading 
> to node failure and storage corruption
> ---
>
> Key: IGNITE-12230
> URL: https://issues.apache.org/jira/browse/IGNITE-12230
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> PartitionEvictionTask may produce NullPointerException if cache / cache group 
> / cluser is stopping / deactivating.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12201) distributed sql join not working as mentioned in documentation

2019-09-25 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-12201:
-

Hi [~shm],

What kind of fix do you expect for this issue? Will it be enough to update 
documentation?

As my understanding goes Ignite requires that index exists on a table column 
which is used to be "joined" remotely. As for replicated caches, each node has 
all table data so there is no need to do remote lookups for replicated tables. 
I agree here that limitations here are not trivial and should be documented 
well.

> distributed sql join not working as mentioned in documentation
> --
>
> Key: IGNITE-12201
> URL: https://issues.apache.org/jira/browse/IGNITE-12201
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7
> Environment: Kubernetes on RHEL 7.6
>Reporter: shivakumar
>Priority: Major
> Attachments: distributed_sql_error.txt
>
>
> I am trying to do a simple cross join on two tables with non-collocated data 
> (without affinity key), 
> This non-collocated distributed join always fails with the error message:
>  
> *"java.sql.SQLException: javax.cache.CacheException: Failed to prepare 
> distributed join query: join condition does not use index "*
>  
> If I create one of the tables in replicated mode and another one in 
> partitioned mode this Join operation works but documentation mentions that 
> Ignite supports non-collocated joins without any condition.
> And we tried with 3 tables and 1 in replicated and other 2 in partitioned 
> then we observed that it failed.
> we are running the Join operations with *distributedJoins=true.*
> *We observed that if there are N tables in Join operation then (N-1) should 
> be in replicated mode, is our understanding right?*
> *If our understanding is correct then to do Join operation the dimensioning 
> of cluster increases by many folds which can't be used in a production 
> environment.*
> *To reproduce:*
> *Ignite with 4 node cluster with native persistence enabled.*
> *create the following tables*
> {quote} {{CREATE TABLE City (}}{quote}
> {quote} {{  id LONG PRIMARY KEY, name VARCHAR)}}{quote}
> {quote} {{  WITH "backup=1";}}{quote}
> {quote} {{}}{quote}
> {quote} {{CREATE TABLE Person (}}
>  {{  id LONG, name VARCHAR, city_id LONG, PRIMARY KEY (id, city_id))}}
>  {{  WITH "backups=1";}}
>  {{}}
>  {{CREATE INDEX idx_city_name ON City (name);}}
>  {{}}
>  {{CREATE INDEX idx_person_name ON Person (name);}}
>  
>  {{INSERT INTO City (id, name) VALUES (1, 'Forest Hill');}}
>  {{INSERT INTO City (id, name) VALUES (2, 'Denver');}}
>  {{INSERT INTO City (id, name) VALUES (3, 'St. Petersburg');}}
>  {{}}
>  {{INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);}}
>  {{INSERT INTO Person (id, name, city_id) VALUES (2, 'Jane Roe', 2);}}
>  {{INSERT INTO Person (id, name, city_id) VALUES (3, 'Mary Major', 1);}}
>  {{INSERT INTO Person (id, name, city_id) VALUES (4, 'Richard Miles', 2);}} {{
> }}{quote}
> Query to be run:
> {quote}select * from City c, Person p;{color:#66}
> {color}{quote}
> {quote}or 
> {color:#80}*SELECT*{color} * *{color:#80}FROM{color}* City 
> *{color:#80}AS{color}* c *{color:#80}CROSS{color}* 
> *{color:#80}join{color}* Person *{color:#80}AS{color}* p;{quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-09-24 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-7285:


[~samaitra], thank you for continuing work on it. I left 
[comments|https://github.com/apache/ignite/pull/6490#pullrequestreview-292345841].
 If you agree with them please proceed with tests.

> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12168) [ML] Flaky ML example tests

2019-09-16 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-12168:
-

[~zaleslaw], should the ticket be resolved as PR is merged? Could you please do 
it?

> [ML] Flaky ML example tests
> ---
>
> Key: IGNITE-12168
> URL: https://issues.apache.org/jira/browse/IGNITE-12168
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Critical
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Discussed here 
> [http://apache-ignite-developers.2346864.n4.nabble.com/After-IGNITE-12148-the-Examples-suite-has-unstable-tests-td43469.html]



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Comment Edited] (IGNITE-12144) Vacuum error. class org.apache.ignite.internal.transactions.IgniteTxMvccVersionCheckedException

2019-09-10 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin edited comment on IGNITE-12144 at 9/10/19 9:08 AM:
--

[~adiagarwal29], I resolved this issue as a duplicate of IGNITE-12143. Feel 
free to reopen if I got it wrong.


was (Author: pavlukhin):
[~adiagarwal29], I resolved an issue as a duplicate of IGNITE-12143. Feel free 
to reopen if I got it wrong.

> Vacuum error.  class 
> org.apache.ignite.internal.transactions.IgniteTxMvccVersionCheckedException
> 
>
> Key: IGNITE-12144
> URL: https://issues.apache.org/jira/browse/IGNITE-12144
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Affects Versions: 2.7.5
>Reporter: Aditya Gupta
>Priority: Major
>
> 2019-09-05 17:54:46.576 INFO STDERR [Thread-18] :  
> [17:54:46] (err) Failed to execute compound future reducer: 
> GridCompoundFuture [rdc=null, initFlag=0, lsnrCalls=0, done=false, 
> cancelled=false, err=null, futs=[false, false, false, false, false, false, 
> false, false, false, false, false, false, false, false, false, false, false, 
> false, false, false, true]]class org.apache.ignite.IgniteCheckedException: 
> class org.apache.ignite.transactions.TransactionRollbackException: 
> Transaction has been rolled back: 
> 108bb6a2d61--0aad-7c5d--0001
> 2019-09-05 17:54:46.576 INFO STDERR [Thread-18] :   
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7429)
> 2019-09-05 17:54:46.576 INFO STDERR [Thread-18] :   
> at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:975)
> 2019-09-05 17:54:46.576 INFO STDERR [Thread-18] :   
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :   
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :   
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :   
> at java.lang.Thread.run(Thread.java:745)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :  Caused by: 
> javax.cache.CacheException: class 
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has 
> been rolled back: 108bb6a2d61--0aad-7c5d--0001
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1758)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerCacheUpdaters$Individual.receive(DataStreamerCacheUpdaters.java:121)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6817)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     ... 4 
> more
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :  Caused by: 
> class org.apache.ignite.transactions.TransactionRollbackException: 
> Transaction has been rolled back: 
> 108bb6a2d61--0aad-7c5d--0001
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:918)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     ... 12 
> more
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :  Caused by: 
> class 
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException: 
> Transaction has been rolled back: 
> 108bb6a2d61--0aad-7c5d--0001
> 

[jira] [Resolved] (IGNITE-12144) Vacuum error. class org.apache.ignite.internal.transactions.IgniteTxMvccVersionCheckedException

2019-09-10 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin resolved IGNITE-12144.
-
Fix Version/s: (was: 2.7.5)
   Resolution: Duplicate

[~adiagarwal29], I resolved an issue as a duplicate of IGNITE-12143. Feel free 
to reopen if I got it wrong.

> Vacuum error.  class 
> org.apache.ignite.internal.transactions.IgniteTxMvccVersionCheckedException
> 
>
> Key: IGNITE-12144
> URL: https://issues.apache.org/jira/browse/IGNITE-12144
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Affects Versions: 2.7.5
>Reporter: Aditya Gupta
>Priority: Major
>
> 2019-09-05 17:54:46.576 INFO STDERR [Thread-18] :  
> [17:54:46] (err) Failed to execute compound future reducer: 
> GridCompoundFuture [rdc=null, initFlag=0, lsnrCalls=0, done=false, 
> cancelled=false, err=null, futs=[false, false, false, false, false, false, 
> false, false, false, false, false, false, false, false, false, false, false, 
> false, false, false, true]]class org.apache.ignite.IgniteCheckedException: 
> class org.apache.ignite.transactions.TransactionRollbackException: 
> Transaction has been rolled back: 
> 108bb6a2d61--0aad-7c5d--0001
> 2019-09-05 17:54:46.576 INFO STDERR [Thread-18] :   
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7429)
> 2019-09-05 17:54:46.576 INFO STDERR [Thread-18] :   
> at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:975)
> 2019-09-05 17:54:46.576 INFO STDERR [Thread-18] :   
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :   
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :   
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :   
> at java.lang.Thread.run(Thread.java:745)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :  Caused by: 
> javax.cache.CacheException: class 
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has 
> been rolled back: 108bb6a2d61--0aad-7c5d--0001
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1758)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> 2019-09-05 17:54:46.577 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerCacheUpdaters$Individual.receive(DataStreamerCacheUpdaters.java:121)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6817)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     ... 4 
> more
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :  Caused by: 
> class org.apache.ignite.transactions.TransactionRollbackException: 
> Transaction has been rolled back: 
> 108bb6a2d61--0aad-7c5d--0001
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:918)
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :     ... 12 
> more
> 2019-09-05 17:54:46.578 INFO STDERR [Thread-18] :  Caused by: 
> class 
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException: 
> Transaction has been rolled back: 
> 108bb6a2d61--0aad-7c5d--0001
> 2019-09-05 17:54:46.579 INFO STDERR [Thread-18] :     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4248)

[jira] [Comment Edited] (IGNITE-7285) Add default query timeout

2019-09-09 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin edited comment on IGNITE-7285 at 9/9/19 12:42 PM:
-

[~samaitra], sorry for a late response. I left a couple of comments on GitHub.
Regarding _unset_ timeout. I think that it would be more straightforward to 
have a following logic:
* Unset timeout means that a default one should be used.
* Explicitly set timeout must be used.
* Timeout values have the same meaning for {{SqlFieldsQuery.setTimeout}} and 
{{IgniteConfiguration.setDefaultQueryTimeout}}. Consequently 0 means infinite 
timeout for both methods.

Technically it can be done in a following way:
# {{SqlFieldsQuery}} declares {{private int timeout = -1}}.
# {{SqlFieldsQuery.setTimeout}} forbids negative arguments.
# Upon {{QueryParameters}} initialization we treat -1 as _unset_ value and use 
a default one.
A care should be taken when we create {{SqlFieldsQuery}} internally for an 
execution, like in {{OdbcRequestHandler}}.


was (Author: pavlukhin):
[~samaitra], I left a couple of comments on GitHub.
Regarding _unset_ timeout. I think that it would be more straightforward to 
have a following logic:
* Unset timeout means that a default one should be used.
* Explicitly set timeout must be used.
* Timeout values have the same meaning for {{SqlFieldsQuery.setTimeout}} and 
{{IgniteConfiguration.setDefaultQueryTimeout}}. Consequently 0 means infinite 
timeout for both methods.

Technically it can be done in a following way:
# {{SqlFieldsQuery}} declares {{private int timeout = -1}}.
# {{SqlFieldsQuery.setTimeout}} forbids negative arguments.
# Upon {{QueryParameters}} initialization we treat -1 as _unset_ value and use 
a default one.
A care should be taken when we create {{SqlFieldsQuery}} internally for an 
execution, like in {{OdbcRequestHandler}}.

> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-09-09 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-7285:


[~samaitra], I left a couple of comments on GitHub.
Regarding _unset_ timeout. I think that it would be more straightforward to 
have a following logic:
* Unset timeout means that a default one should be used.
* Explicitly set timeout must be used.
* Timeout values have the same meaning for {{SqlFieldsQuery.setTimeout}} and 
{{IgniteConfiguration.setDefaultQueryTimeout}}. Consequently 0 means infinite 
timeout for both methods.

Technically it can be done in a following way:
# {{SqlFieldsQuery}} declares {{private int timeout = -1}}.
# {{SqlFieldsQuery.setTimeout}} forbids negative arguments.
# Upon {{QueryParameters}} initialization we treat -1 as _unset_ value and use 
a default one.
A care should be taken when we create {{SqlFieldsQuery}} internally for an 
execution, like in {{OdbcRequestHandler}}.

> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (IGNITE-9410) Add transactions support to thin clients

2019-08-31 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-9410:


[~alex_pl], I must say that I did not check the patch thoroughly. But at least 
I have not noticed any blockers from a bird-eye view.

> Add transactions support to thin clients
> 
>
> Key: IGNITE-9410
> URL: https://issues.apache.org/jira/browse/IGNITE-9410
> Project: Ignite
>  Issue Type: Task
>  Components: mvcc, thin client
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-34
> Fix For: 2.8
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> Currently only ODBC and JDBC drivers support transactions and in not very 
> efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS 
> and Python clients.
> Key pieces:
> # Add API to relevant clients
> # Review listener logic - currently we create separate threads. But is it 
> really needed? 
> ## If there is an implicit operation and no ongoing transaction, then 
> operation might be executed right away
> ## If cache operations are decoupled from threads, then we can resort to 
> reactive approach, when multiple transactions could be executed from the same 
> thread



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Comment Edited] (IGNITE-7285) Add default query timeout

2019-08-26 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin edited comment on IGNITE-7285 at 8/26/19 9:24 PM:
-

[~samaitra],
bq. 1. I ran tests for Distributed Query and local query like 
IgniteCacheReplicatedQuerySelfTest, 
IgniteCacheLocalQueryCancelOrTimeoutSelfTest and I see that timeout value is 
passed. Can you share an example in which Query or execution mode you can see 
that timeout is not passed?
Good to know that it works for different cases. I am concerned about timeout 
propagation 
{{org.apache.ignite.internal.processors.query.h2.CommandProcessor#processTxCommand}}.
 It seems that _default timeout_ is not used in that class in PR. But I must 
say that I do not fully understand why query timeout is used by transactional 
commands.

bq.  2. I observed that QueryParameters initialization is occurring in 
QueryParameters.fromQuery(SqlFieldsQuery qry) method and QueryParameters does 
not have GridKernalContext reference so it will not be feasible to access the 
ctx.config().getDefaultQueryTimeout() upon QueryParameters initialization.
{{org.apache.ignite.internal.processors.query.h2.QueryParameters#fromQuery}} is 
used only in {{QueryParser}}, we can make it aware of ignite configuration by 
placing {{fromQuery}} method to {{QueryParser}} or by introducing a class 
responsible for {{QueryParameters}} construction in presence of default values 
in configuration (only timeout so far). Are there major disadvantages of such 
approach?

.bq 3. If you observe timeout in SqlFieldsQuery get validated in 
QueryUtils.validateTimeout(timeout, timeUnit) and it asserts that timeout value 
of SqlFieldsQuery is more than equal 0. Now if we allow feature to disable 
timeout of particular query using (SqlFieldsQuery.setTimeout(0)) then 
ctx.config().getDefaultQueryTimeout() will never get used.
I understood that disabling a timeout in presence of non-zero default value is 
not so trivial. But I am still concerned how usable it would be? It is 
desirable to protect a user from surprising behavior of {{setTimeout(0)}} when 
default timeout is configured. Actually, to distinguish between _unset_ vs 
_disabled_ timeout I thought about using -1 to indicate that a user did not 
call {{setTimeout}}. Of course some care is needed to implement such approach 
properly.

One more additional note. We have 
{{org.apache.ignite.internal.sql.command.SqlBulkLoadCommand}} and we should 
consider a _default timeout_ for it, at least roughly estimate how challenging 
is it.


was (Author: pavlukhin):
[~samaitra],
bq. 1. I ran tests for Distributed Query and local query like 
IgniteCacheReplicatedQuerySelfTest, 
IgniteCacheLocalQueryCancelOrTimeoutSelfTest and I see that timeout value is 
passed. Can you share an example in which Query or execution mode you can see 
that timeout is not passed?
Good to know that it works for different cases. I am concerned about timeout 
propagation 
{{org.apache.ignite.internal.processors.query.h2.CommandProcessor#processTxCommand}}.
 It seems that _default timeout_ is not used in that class in PR. But I must 
say that I do not fully understand why query timeout is used by transactional 
commands.
bq.  2. I observed that QueryParameters initialization is occurring in 
QueryParameters.fromQuery(SqlFieldsQuery qry) method and QueryParameters does 
not have GridKernalContext reference so it will not be feasible to access the 
ctx.config().getDefaultQueryTimeout() upon QueryParameters initialization.
{{org.apache.ignite.internal.processors.query.h2.QueryParameters#fromQuery}} is 
used only in {{QueryParser}}, we can make it aware of ignite configuration by 
placing {{fromQuery}} method to {{QueryParser}} or by introducing a class 
responsible for {{QueryParameters}} construction in presence of default values 
in configuration (only timeout so far). Are there major disadvantages of such 
approach?
.bq If you observe timeout in SqlFieldsQuery get validated in 
QueryUtils.validateTimeout(timeout, timeUnit) and it asserts that timeout value 
of SqlFieldsQuery is more than equal 0. Now if we allow feature to disable 
timeout of particular query using (SqlFieldsQuery.setTimeout(0)) then 
ctx.config().getDefaultQueryTimeout() will never get used.
I understood that disabling a timeout in presence of non-zero default value is 
not so trivial. But I am still concerned how usable it would be? It is 
desirable to protect a user from surprising behavior of {{setTimeout(0)}} when 
default timeout is configured. Actually, to distinguish between _unset_ vs 
_disabled_ timeout I thought about using -1 to indicate that a user did not 
call {{setTimeout}}. Of course some care is needed to implement such approach 
properly.

One more additional note. We have 
{{org.apache.ignite.internal.sql.command.SqlBulkLoadCommand}} and we should 
consider a 

[jira] [Comment Edited] (IGNITE-7285) Add default query timeout

2019-08-26 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin edited comment on IGNITE-7285 at 8/26/19 9:24 PM:
-

[~samaitra],
bq. 1. I ran tests for Distributed Query and local query like 
IgniteCacheReplicatedQuerySelfTest, 
IgniteCacheLocalQueryCancelOrTimeoutSelfTest and I see that timeout value is 
passed. Can you share an example in which Query or execution mode you can see 
that timeout is not passed?
Good to know that it works for different cases. I am concerned about timeout 
propagation 
{{org.apache.ignite.internal.processors.query.h2.CommandProcessor#processTxCommand}}.
 It seems that _default timeout_ is not used in that class in PR. But I must 
say that I do not fully understand why query timeout is used by transactional 
commands.

bq.  2. I observed that QueryParameters initialization is occurring in 
QueryParameters.fromQuery(SqlFieldsQuery qry) method and QueryParameters does 
not have GridKernalContext reference so it will not be feasible to access the 
ctx.config().getDefaultQueryTimeout() upon QueryParameters initialization.
{{org.apache.ignite.internal.processors.query.h2.QueryParameters#fromQuery}} is 
used only in {{QueryParser}}, we can make it aware of ignite configuration by 
placing {{fromQuery}} method to {{QueryParser}} or by introducing a class 
responsible for {{QueryParameters}} construction in presence of default values 
in configuration (only timeout so far). Are there major disadvantages of such 
approach?

bq. 3. If you observe timeout in SqlFieldsQuery get validated in 
QueryUtils.validateTimeout(timeout, timeUnit) and it asserts that timeout value 
of SqlFieldsQuery is more than equal 0. Now if we allow feature to disable 
timeout of particular query using (SqlFieldsQuery.setTimeout(0)) then 
ctx.config().getDefaultQueryTimeout() will never get used.
I understood that disabling a timeout in presence of non-zero default value is 
not so trivial. But I am still concerned how usable it would be? It is 
desirable to protect a user from surprising behavior of {{setTimeout(0)}} when 
default timeout is configured. Actually, to distinguish between _unset_ vs 
_disabled_ timeout I thought about using -1 to indicate that a user did not 
call {{setTimeout}}. Of course some care is needed to implement such approach 
properly.

One more additional note. We have 
{{org.apache.ignite.internal.sql.command.SqlBulkLoadCommand}} and we should 
consider a _default timeout_ for it, at least roughly estimate how challenging 
is it.


was (Author: pavlukhin):
[~samaitra],
bq. 1. I ran tests for Distributed Query and local query like 
IgniteCacheReplicatedQuerySelfTest, 
IgniteCacheLocalQueryCancelOrTimeoutSelfTest and I see that timeout value is 
passed. Can you share an example in which Query or execution mode you can see 
that timeout is not passed?
Good to know that it works for different cases. I am concerned about timeout 
propagation 
{{org.apache.ignite.internal.processors.query.h2.CommandProcessor#processTxCommand}}.
 It seems that _default timeout_ is not used in that class in PR. But I must 
say that I do not fully understand why query timeout is used by transactional 
commands.

bq.  2. I observed that QueryParameters initialization is occurring in 
QueryParameters.fromQuery(SqlFieldsQuery qry) method and QueryParameters does 
not have GridKernalContext reference so it will not be feasible to access the 
ctx.config().getDefaultQueryTimeout() upon QueryParameters initialization.
{{org.apache.ignite.internal.processors.query.h2.QueryParameters#fromQuery}} is 
used only in {{QueryParser}}, we can make it aware of ignite configuration by 
placing {{fromQuery}} method to {{QueryParser}} or by introducing a class 
responsible for {{QueryParameters}} construction in presence of default values 
in configuration (only timeout so far). Are there major disadvantages of such 
approach?

.bq 3. If you observe timeout in SqlFieldsQuery get validated in 
QueryUtils.validateTimeout(timeout, timeUnit) and it asserts that timeout value 
of SqlFieldsQuery is more than equal 0. Now if we allow feature to disable 
timeout of particular query using (SqlFieldsQuery.setTimeout(0)) then 
ctx.config().getDefaultQueryTimeout() will never get used.
I understood that disabling a timeout in presence of non-zero default value is 
not so trivial. But I am still concerned how usable it would be? It is 
desirable to protect a user from surprising behavior of {{setTimeout(0)}} when 
default timeout is configured. Actually, to distinguish between _unset_ vs 
_disabled_ timeout I thought about using -1 to indicate that a user did not 
call {{setTimeout}}. Of course some care is needed to implement such approach 
properly.

One more additional note. We have 
{{org.apache.ignite.internal.sql.command.SqlBulkLoadCommand}} and we should 

[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-08-26 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-7285:


[~samaitra],
bq. 1. I ran tests for Distributed Query and local query like 
IgniteCacheReplicatedQuerySelfTest, 
IgniteCacheLocalQueryCancelOrTimeoutSelfTest and I see that timeout value is 
passed. Can you share an example in which Query or execution mode you can see 
that timeout is not passed?
Good to know that it works for different cases. I am concerned about timeout 
propagation 
{{org.apache.ignite.internal.processors.query.h2.CommandProcessor#processTxCommand}}.
 It seems that _default timeout_ is not used in that class in PR. But I must 
say that I do not fully understand why query timeout is used by transactional 
commands.
bq.  2. I observed that QueryParameters initialization is occurring in 
QueryParameters.fromQuery(SqlFieldsQuery qry) method and QueryParameters does 
not have GridKernalContext reference so it will not be feasible to access the 
ctx.config().getDefaultQueryTimeout() upon QueryParameters initialization.
{{org.apache.ignite.internal.processors.query.h2.QueryParameters#fromQuery}} is 
used only in {{QueryParser}}, we can make it aware of ignite configuration by 
placing {{fromQuery}} method to {{QueryParser}} or by introducing a class 
responsible for {{QueryParameters}} construction in presence of default values 
in configuration (only timeout so far). Are there major disadvantages of such 
approach?
.bq If you observe timeout in SqlFieldsQuery get validated in 
QueryUtils.validateTimeout(timeout, timeUnit) and it asserts that timeout value 
of SqlFieldsQuery is more than equal 0. Now if we allow feature to disable 
timeout of particular query using (SqlFieldsQuery.setTimeout(0)) then 
ctx.config().getDefaultQueryTimeout() will never get used.
I understood that disabling a timeout in presence of non-zero default value is 
not so trivial. But I am still concerned how usable it would be? It is 
desirable to protect a user from surprising behavior of {{setTimeout(0)}} when 
default timeout is configured. Actually, to distinguish between _unset_ vs 
_disabled_ timeout I thought about using -1 to indicate that a user did not 
call {{setTimeout}}. Of course some care is needed to implement such approach 
properly.

One more additional note. We have 
{{org.apache.ignite.internal.sql.command.SqlBulkLoadCommand}} and we should 
consider a _default timeout_ for it, at least roughly estimate how challenging 
is it.

> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Updated] (IGNITE-12090) KeyNotFound exception when creating cache from code if value has 'sbyte?' field

2019-08-23 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin updated IGNITE-12090:

Component/s: platforms

> KeyNotFound exception when creating cache from code if value has 'sbyte?' 
> field
> ---
>
> Key: IGNITE-12090
> URL: https://issues.apache.org/jira/browse/IGNITE-12090
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, platforms
>Affects Versions: 2.7.5
>Reporter: Denis Zakharov
>Priority: Major
> Attachments: a.cs
>
>
> Ignite.NET.
> Using 'sbyte?' field for value causes KeyNotFound exception during cache 
> creation (field's type validation), when Ignite attempts to print type's name 
> into log.
>  # {{I don't really understand why .Net's sbyte is considered not directly 
> mappable to java.byte 
> ([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L54)]
>  ? }}{{Also it is not consistent with other indirect mapping (usigned -> 
> signed)}}
>  # {{Access to NetToJava dictionary 
> ([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L109])
>  should be safeguarded (NetToJava doesn't have entries for nullable types)}}
>   
> {{Code example in attachment}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Updated] (IGNITE-12090) KeyNotFound exception when creating cache from code if value has 'sbyte?' field

2019-08-23 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin updated IGNITE-12090:

Labels: .NET  (was: )

> KeyNotFound exception when creating cache from code if value has 'sbyte?' 
> field
> ---
>
> Key: IGNITE-12090
> URL: https://issues.apache.org/jira/browse/IGNITE-12090
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, platforms
>Affects Versions: 2.7.5
>Reporter: Denis Zakharov
>Priority: Major
>  Labels: .NET
> Attachments: a.cs
>
>
> Ignite.NET.
> Using 'sbyte?' field for value causes KeyNotFound exception during cache 
> creation (field's type validation), when Ignite attempts to print type's name 
> into log.
>  # {{I don't really understand why .Net's sbyte is considered not directly 
> mappable to java.byte 
> ([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L54)]
>  ? }}{{Also it is not consistent with other indirect mapping (usigned -> 
> signed)}}
>  # {{Access to NetToJava dictionary 
> ([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L109])
>  should be safeguarded (NetToJava doesn't have entries for nullable types)}}
>   
> {{Code example in attachment}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-08-20 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-7285:


[~amashenkov], could you please step in and continue the review? Unfortunately, 
for a couple of weeks I have limited access to my computer and cannot do a 
review in a timely manner.

> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-08-20 Thread Ivan Pavlukhin (Jira)


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

Ivan Pavlukhin commented on IGNITE-7285:


Hi [~samaitra],

I suspect that not all places where a timeout should be passed are covered yet. 
For me it looks more natural to calculate a query timeout (taking default one 
into account) upon {{QueryParameters}} initialization. It is worth to consider 
following points for an implementation:
1. Reduce a number of places where _default timeout_ is read from configuration 
(ideally there should be only one place).
2. Be able to disable a timeout for a particular query 
({{SqlFieldsQuery.setTimeout(0)}}) when default non-zero timeout is configured.

> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-16 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12068:
-

Cherry-picked to master in 
https://github.com/apache/ignite/commit/45d719e66c95df8a115af467792f8b89dace83e3

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Fix For: 2.7.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-16 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12068:
-

C++ and .NET test results are same as in 2.7.6. MVCC Queries tests are not 
stable, results are comparable to other 2.7.6 runs.

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Fix For: 2.7.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.

2019-08-16 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12061:
-

[~zstan], I left a couple comments on GitHub. I suggest to exclude this ticket 
from 2.7.6 and complete with this ticket calmly.

> Silently fail while try to recreate already existing index with differ 
> inline_size.
> ---
>
> Key: IGNITE-12061
> URL: https://issues.apache.org/jira/browse/IGNITE-12061
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.5, 2.7, 2.7.5
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> INLINE_SIZE differ from previous value is  not correctly sets.
> 1. create index idx0(c1, c2)
> 2. drop idx0
> 3. create index idx0(c1, c2) inline_size 100;
> inline_size remains the same, in this case default = 10.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.

2019-08-16 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12061:
-

[~zstan], I left my comments on 
[GitHub|https://github.com/apache/ignite/pull/6770#pullrequestreview-275803048].
 Also we need to clarify one thing about "physical" indexes destroy. Is it 
right that before this patch we did not clear index partition at all on index 
drop? Do you know why was it so? If it is true we need to highlight that it is 
not only about _index recreation with different inline size_.

> Silently fail while try to recreate already existing index with differ 
> inline_size.
> ---
>
> Key: IGNITE-12061
> URL: https://issues.apache.org/jira/browse/IGNITE-12061
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.5, 2.7, 2.7.5
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> INLINE_SIZE differ from previous value is  not correctly sets.
> 1. create index idx0(c1, c2)
> 2. drop idx0
> 3. create index idx0(c1, c2) inline_size 100;
> inline_size remains the same, in this case default = 10.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-16 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12068:
-

*Release notes*
Fixed a bug when SELECT with an equality predicate on a part of a complex 
primary key returned a single row result while multiple matching rows existed 
in the table.

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.

2019-08-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-12061:

Reviewer: Yury Gerzhedovich

> Silently fail while try to recreate already existing index with differ 
> inline_size.
> ---
>
> Key: IGNITE-12061
> URL: https://issues.apache.org/jira/browse/IGNITE-12061
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.5, 2.7, 2.7.5
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> INLINE_SIZE differ from previous value is  not correctly sets.
> 1. create index idx0(c1, c2)
> 2. drop idx0
> 3. create index idx0(c1, c2) inline_size 100;
> inline_size remains the same, in this case default = 10.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11289) BPlusTree.AbstractForwardCursor can use obsolete page

2019-08-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-11289:
-

Some debugging were done in:
* https://github.com/apache/ignite/pull/6066
* https://github.com/apache/ignite/pull/6064

> BPlusTree.AbstractForwardCursor can use obsolete page
> -
>
> Key: IGNITE-11289
> URL: https://issues.apache.org/jira/browse/IGNITE-11289
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> There is a possibility that {{AbstractForwardCursor.nextPageId}} refers to a 
> page which was already excluded from the tree. The problem reproduces with a 
> scan query execution with put/remove load in background.
> Linked PR contains a reproducer and some tricks allowing to reproduce the 
> problem more often (it is still possible to reproduce it without tricks but 
> likelihood is significantly lower). The problem becomes evident when a 
> problematic page is taken from REUSE_BUCKET. But there could be other hidden 
> problems which do not cause any runtime errors but lead to data inconsistency.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12068:
-

Work note. Release notes will be needed.

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (IGNITE-12068) puzzling select result

2019-08-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin reassigned IGNITE-12068:
---

Assignee: Ivan Pavlukhin

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Fix For: 2.7.6
>
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-08-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-7285:


[~samaitra], from configuration standpoint changes look good. But a default 
value is not passed properly. Method {{GridCacheQueryAdapter#timeout(long)}} 
using _default timeout_ from configuration is never used in a production code, 
so I suppose that a timeout is not propagated properly. In API we have 2 types 
of queries supporting timeouts {{SqlFieldsQuery}} and {{SqlQuery}}. 
Mechanically {{QueryParameters#fromQuery}} looks as a good starting point to 
see how timeout is propagated from a user {{SqlFieldsQuery}} for an actual 
execution. Note, that timeout should be propagated to _map_ queries as well. 
Also, all behavior should be validated by tests, at least following execution 
modes should be covered:
* Distributed query against PARTITIONED cache.
* Distributed query against REPLICATED cache.
* Local query.


> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12069) Create cache shared preloader

2019-08-14 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12069:
-

[~xtern], thank you for a clarification.

> Create cache shared preloader
> -
>
> Key: IGNITE-12069
> URL: https://issues.apache.org/jira/browse/IGNITE-12069
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-28
>
> {{CacheSharedPreloader}} must do the following:
>  # build the map of partitions and corresponding supplier nodes from which 
> partitions will be loaded [1];
>  # switch cache data storage to {{no-op}} and back to original (HWM must be 
> fixed here for the needs of historical rebalance) under the checkpoint and 
> keep the partition update counter for each partition [1];
>  # run async the eviction indexes for the list of collected partitions (API 
> must be provided by IGNITE-11075) [2];
>  # send a request message to each node one by one with the list of partitions 
> to load [2];
>  # wait for files received (listening for the transmission handler) [2];
>  # run rebuild indexes async over the receiving partitions (API must be 
> provided by IGNITE-11075) [2];
>  # run historical rebalance from LWM to HWM collected above (LWM can be read 
> from the received file meta page) [1];
> The points marked with the label {{[1]}} must be done prior to {{[2]}}.
>  
> NOTE. The following things need to be checked:
>  # Rebalancing of MVCC cache groups;
>  # How LWM and HWM will be set for the historical rebalance;



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12069) Create cache shared preloader

2019-08-14 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12069:
-

[~Mmuzaf], [~xtern], just for my understanding, could you please elaborate why 
it is _shared_ preloader? What entities do share it?

> Create cache shared preloader
> -
>
> Key: IGNITE-12069
> URL: https://issues.apache.org/jira/browse/IGNITE-12069
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-28
>
> {{CacheSharedPreloader}} must do the following:
>  # build the map of partitions and corresponding supplier nodes from which 
> partitions will be loaded [1];
>  # witching cache data storage to {{no-op}} and back to original (HWM must be 
> fixed here for the needs of historical rebalance) under the checkpoint and 
> keep the partition update counter for each partition [1];
>  # run async the eviction indexes for the list of collected partitions (API 
> must be provided by IGNITE-11075) [2];
>  # send a request message to each node one by one with the list of partitions 
> to load [2];
>  # listening for the transmission handler to receive files [2];
>  # run rebuild indexes async over the receiving partitions (API must be 
> provided by IGNITE-11075) [2];
>  # run historical rebalance from LWM to HWM collected above (LWM can be read 
> from the received file meta page) [1];
> The points marked with the label {{[1]}} must be done prior to {{[2]}}.
>  
> NOTE. Check the following things:
>  # Rebalancing of MVCC cache groups;
>  # How LWM and HWM will be set for the historical rebalance;



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-14 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12068:
-

[~JerryKwan], yep you are right. And a workaround for integers also does not 
look good. Currently I can only think about changing a table structure =(

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Priority: Critical
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12068) puzzling select result

2019-08-14 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-12068:

Priority: Critical  (was: Major)

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Priority: Critical
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-14 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12068:
-

[~JerryKwan], you faced (for our shame) a bug related to an optimization for a 
primary key equality lookup. Erroneously it assumes that there should be only 
one result row. As a workaround I was able to get proper results using 
filtering condition {{WHERE id >= 1 and id < 2}}. But it is really weird, hope 
to fix it shortly.

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Priority: Major
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-08-13 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-10973:
-

[~ivanan.fed], I suppose we cannot proceed until the problem with .NET tests is 
fixed.

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-5475) SQL: add CTE ("WITH AS") support

2019-08-13 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-5475:
---
Summary: SQL: add CTE ("WITH AS") support  (was: SQL: add "WITH AS" support)

> SQL: add CTE ("WITH AS") support
> 
>
> Key: IGNITE-5475
> URL: https://issues.apache.org/jira/browse/IGNITE-5475
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Andrew Mashenkov
>Priority: Minor
>  Labels: sql-engine
>
> Seems for now, H2 doesn't support "WITH AS" clause.
> We should throw exception until we found a workaround or "WITH" support be 
> added to H2.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-5475) SQL: add "WITH AS" support

2019-08-13 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-5475:


[~amashenkov] could we close this ticket as it seems that queries using syntax 
{{WITH ... AS}} (CTE) are accepted by Ignite?

> SQL: add "WITH AS" support
> --
>
> Key: IGNITE-5475
> URL: https://issues.apache.org/jira/browse/IGNITE-5475
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Andrew Mashenkov
>Priority: Minor
>  Labels: sql-engine
>
> Seems for now, H2 doesn't support "WITH AS" clause.
> We should throw exception until we found a workaround or "WITH" support be 
> added to H2.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Comment Edited] (IGNITE-12051) Update javadoc for the IgniteKernal class

2019-08-13 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin edited comment on IGNITE-12051 at 8/13/19 6:48 AM:
--

[~Mmuzaf], I left few comments on GitHub.


was (Author: pavlukhin):
[~Mmuzaf], I left several comments on GitHub.

> Update javadoc for the IgniteKernal class
> -
>
> Key: IGNITE-12051
> URL: https://issues.apache.org/jira/browse/IGNITE-12051
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Fix For: 2.8
>
>  Time Spent: 5.5h
>  Remaining Estimate: 0h
>
> Update all ambiguous an empty javadoc comments, such as:
> {code}
> /** */
> /** Periodic starvation check interval. */ 
> private static final long PERIODIC_STARVATION_CHECK_FREQ = 1000 * 30; 
> /** Long jvm pause detector. */ 
> private LongJVMPauseDetector longJVMPauseDetector; 
> /** Scheduler. */ 
> private IgniteScheduler scheduler; 
> /** Stop guard. */ 
> private final AtomicBoolean stopGuard = new AtomicBoolean(); 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12051) Update javadoc for the IgniteKernal class

2019-08-13 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12051:
-

[~Mmuzaf], I left several comments on GitHub.

> Update javadoc for the IgniteKernal class
> -
>
> Key: IGNITE-12051
> URL: https://issues.apache.org/jira/browse/IGNITE-12051
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Fix For: 2.8
>
>  Time Spent: 5.5h
>  Remaining Estimate: 0h
>
> Update all ambiguous an empty javadoc comments, such as:
> {code}
> /** */
> /** Periodic starvation check interval. */ 
> private static final long PERIODIC_STARVATION_CHECK_FREQ = 1000 * 30; 
> /** Long jvm pause detector. */ 
> private LongJVMPauseDetector longJVMPauseDetector; 
> /** Scheduler. */ 
> private IgniteScheduler scheduler; 
> /** Stop guard. */ 
> private final AtomicBoolean stopGuard = new AtomicBoolean(); 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Reopened] (IGNITE-11429) rror on queryng IGNITE.LOCAL_SQL_RUNNING_QUERIES SQL view

2019-08-12 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin reopened IGNITE-11429:
-
Ignite Flags:   (was: Docs Required)

> rror on queryng IGNITE.LOCAL_SQL_RUNNING_QUERIES SQL view
> -
>
> Key: IGNITE-11429
> URL: https://issues.apache.org/jira/browse/IGNITE-11429
> Project: Ignite
>  Issue Type: Bug
>Reporter: Yury Gerzhedovich
>Priority: Major
>
> Need to fix TIMESTAMP_WITH_TIMEZONE issue in the LOCAL_SQL_RUNNING_QUERIES 
> view.
> SELECT * FROM IGNITE.LOCAL_SQL_RUNNING_QUERIES;
>  
> [2019-02-27 
> 11:28:24,357][ERROR][client-connector-#56][ClientListenerNioListener] Failed 
> to process client request [req=JdbcQueryExecuteRequest [schemaName=PUBLIC, 
> pageSize=1024, maxRows=200, sqlQry=SELECT * FROM 
> IGNITE.LOCAL_SQL_RUNNING_QUERIES, args=Object[] [], 
> stmtType=ANY_STATEMENT_TYPE, autoCommit=true]]
> class org.apache.ignite.binary.BinaryObjectException: Custom objects are not 
> supported
>  at 
> org.apache.ignite.internal.processors.odbc.SqlListenerUtils.writeObject(SqlListenerUtils.java:219)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcUtils.writeItems(JdbcUtils.java:44)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryExecuteResult.writeBinary(JdbcQueryExecuteResult.java:128)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcResponse.writeBinary(JdbcResponse.java:88)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcMessageParser.encode(JdbcMessageParser.java:91)
>  at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:198)
>  at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:48)
>  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:120)
>  at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>  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)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Resolved] (IGNITE-11429) rror on queryng IGNITE.LOCAL_SQL_RUNNING_QUERIES SQL view

2019-08-12 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin resolved IGNITE-11429.
-
Resolution: Duplicate

> rror on queryng IGNITE.LOCAL_SQL_RUNNING_QUERIES SQL view
> -
>
> Key: IGNITE-11429
> URL: https://issues.apache.org/jira/browse/IGNITE-11429
> Project: Ignite
>  Issue Type: Bug
>Reporter: Yury Gerzhedovich
>Priority: Major
>
> Need to fix TIMESTAMP_WITH_TIMEZONE issue in the LOCAL_SQL_RUNNING_QUERIES 
> view.
> SELECT * FROM IGNITE.LOCAL_SQL_RUNNING_QUERIES;
>  
> [2019-02-27 
> 11:28:24,357][ERROR][client-connector-#56][ClientListenerNioListener] Failed 
> to process client request [req=JdbcQueryExecuteRequest [schemaName=PUBLIC, 
> pageSize=1024, maxRows=200, sqlQry=SELECT * FROM 
> IGNITE.LOCAL_SQL_RUNNING_QUERIES, args=Object[] [], 
> stmtType=ANY_STATEMENT_TYPE, autoCommit=true]]
> class org.apache.ignite.binary.BinaryObjectException: Custom objects are not 
> supported
>  at 
> org.apache.ignite.internal.processors.odbc.SqlListenerUtils.writeObject(SqlListenerUtils.java:219)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcUtils.writeItems(JdbcUtils.java:44)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryExecuteResult.writeBinary(JdbcQueryExecuteResult.java:128)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcResponse.writeBinary(JdbcResponse.java:88)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcMessageParser.encode(JdbcMessageParser.java:91)
>  at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:198)
>  at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:48)
>  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:120)
>  at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>  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)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Resolved] (IGNITE-11429) rror on queryng IGNITE.LOCAL_SQL_RUNNING_QUERIES SQL view

2019-08-12 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin resolved IGNITE-11429.
-
Resolution: Fixed

Resolved as IGNITE-11430 duplicate.

> rror on queryng IGNITE.LOCAL_SQL_RUNNING_QUERIES SQL view
> -
>
> Key: IGNITE-11429
> URL: https://issues.apache.org/jira/browse/IGNITE-11429
> Project: Ignite
>  Issue Type: Bug
>Reporter: Yury Gerzhedovich
>Priority: Major
>
> Need to fix TIMESTAMP_WITH_TIMEZONE issue in the LOCAL_SQL_RUNNING_QUERIES 
> view.
> SELECT * FROM IGNITE.LOCAL_SQL_RUNNING_QUERIES;
>  
> [2019-02-27 
> 11:28:24,357][ERROR][client-connector-#56][ClientListenerNioListener] Failed 
> to process client request [req=JdbcQueryExecuteRequest [schemaName=PUBLIC, 
> pageSize=1024, maxRows=200, sqlQry=SELECT * FROM 
> IGNITE.LOCAL_SQL_RUNNING_QUERIES, args=Object[] [], 
> stmtType=ANY_STATEMENT_TYPE, autoCommit=true]]
> class org.apache.ignite.binary.BinaryObjectException: Custom objects are not 
> supported
>  at 
> org.apache.ignite.internal.processors.odbc.SqlListenerUtils.writeObject(SqlListenerUtils.java:219)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcUtils.writeItems(JdbcUtils.java:44)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryExecuteResult.writeBinary(JdbcQueryExecuteResult.java:128)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcResponse.writeBinary(JdbcResponse.java:88)
>  at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcMessageParser.encode(JdbcMessageParser.java:91)
>  at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:198)
>  at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:48)
>  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:120)
>  at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>  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)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12051) Update javadoc for the IgniteKernal class

2019-08-10 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12051:
-

[~Mmuzaf], I left my comments on GitHub.

> Update javadoc for the IgniteKernal class
> -
>
> Key: IGNITE-12051
> URL: https://issues.apache.org/jira/browse/IGNITE-12051
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Fix For: 2.8
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Update all ambiguous an empty javadoc comments, such as:
> {code}
> /** */
> /** Periodic starvation check interval. */ 
> private static final long PERIODIC_STARVATION_CHECK_FREQ = 1000 * 30; 
> /** Long jvm pause detector. */ 
> private LongJVMPauseDetector longJVMPauseDetector; 
> /** Scheduler. */ 
> private IgniteScheduler scheduler; 
> /** Stop guard. */ 
> private final AtomicBoolean stopGuard = new AtomicBoolean(); 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12050) MVCC test suites resurrection

2019-08-08 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-12050:
---

 Summary: MVCC test suites resurrection
 Key: IGNITE-12050
 URL: https://issues.apache.org/jira/browse/IGNITE-12050
 Project: Ignite
  Issue Type: Bug
  Components: mvcc
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin


Need to resurrect MVCC test suites for RunAll. 
Mute all tests with fail rate more 50%
And start use scale factor for MVCC tests to reduce execution time.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-11985) .NET: CompiledQuery.Compile does not work with string parameters

2019-08-06 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-11985:

Fix Version/s: 2.8

> .NET: CompiledQuery.Compile does not work with string parameters
> 
>
> Key: IGNITE-11985
> URL: https://issues.apache.org/jira/browse/IGNITE-11985
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4, 2.5, 2.6, 2.7, 2.7.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.8
>
>
> String parameters always produce an exception, example:
> {code}
> CompiledQuery.Compile((string empName) => persons.Where(x => x.Value.Name == 
> empName))
> {code}
> Result:
> {code}
> System.InvalidOperationException: Error compiling query: entire LINQ 
> expression should be specified within lambda passed to Compile method. Part 
> of the query can't be outside the Compile method call.
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-9694) Add tests to check that reading queries are not blocked on exchange events that don't change data visibility

2019-08-06 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-9694:


[~ibessonov] as the ticket is resolved can substasks be resolved as well?

> Add tests to check that reading queries are not blocked on exchange events 
> that don't change data visibility
> 
>
> Key: IGNITE-9694
> URL: https://issues.apache.org/jira/browse/IGNITE-9694
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
>
> In current implementation there might be situations where reading operation 
> waits, for example, exchange of client join event. Such events should not 
> block read operations.
> In theory - the only operation that has to block reading (except for writing) 
> is "node left" for server (or baseline server in case of persistent setup).
> Table shows current state of blocking, covered by test in this ticket:
>  
> Partitioned cache:
> || ||Start
>  Client||Stop
>  Client||Start
>  Server||Stop
>  Server||Start
>  Baseline||Stop
>  Baseline||Add
>  Baseline||Start
>  Cache||Stop
>  Cache||Create
>  Sql Index||Drop
>  Sql Index||
> |Get|   (x)|   (x)|   (x)|   (x)|     (/)|     (x)|     (x)|   (x)|   (x)|    
>   (/)|  (/)|
> |Get All|   (x)|   (x)|   (x)|   (x)|     (/)|     (x)|     (x)|   (x)|   
> (x)|      (/)|  (/)|
> |Scan|   (/)|   (/)|   (/)|   (/)|     (/)|     (/)|     (/)|   (/)|   (/)|   
>    (/)|      (/)|
> |Sql Query|   (x)|   (x)|   (x)|   (x)|     (/)|     (x)|     (/)|   (/)|   
> (/)|  (/)|      (/)|
> Replicated cache:
> || ||Start
>  Client||Stop
>  Client||Start
>  Server||Stop
>  Server||Start
>  Baseline||Stop
>  Baseline||Add
>  Baseline||Start
>  Cache||Stop
>  Cache||Create
>  Sql Index||Drop
>  Sql Index||
> |Get|   (x)|   (x)|   (x)|   (x)|     (/)|     (x)|     (x)|   (x)|   (x)|    
>   (/)|  (/)|
> |Get All|   (x)|   (x)|   (x)|   (x)|     (/)|     (x)|     (x)|   (x)|   
> (x)|      (/)|  (/)|
> |Scan|   (x)|   (x)|   (/)|   (/)|     (/)|     (/)|     (/)|   (/)|   (/)|   
>    (/)|      (/)|
> |Sql Query|   (/)|   (/)|   (/)|   (/)|     (/)|     (/)|     (/)|   (/)|   
> (/)|  (/)|      (/)|
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12041) CacheMvccTransactionsTest.testNodesRestartNoHang fails frequently

2019-08-03 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-12041:
---

 Summary: CacheMvccTransactionsTest.testNodesRestartNoHang fails 
frequently
 Key: IGNITE-12041
 URL: https://issues.apache.org/jira/browse/IGNITE-12041
 Project: Ignite
  Issue Type: Bug
  Components: mvcc
Reporter: Ivan Pavlukhin


CacheMvccTransactionsTest.testNodesRestartNoHang fails frequently on TC.
{noformat}
84)
[2019-08-02 
15:48:13,510][ERROR][sys-stripe-21-#34781%mvcc.CacheMvccTransactionsTest1%][IgniteTestResources]
 Critical system error detected. Will be handled accordingly to configured 
handler [hnd=StopNodeFailureHandler [super=AbstractFailureHandler 
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, 
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class 
o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is 
corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=81227264, 
val2=844420635164673]], msg=Runtime failure on search row: TxKey 
[major=1564750080783, minor=1116
class 
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
 B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=81227264, 
val2=844420635164673]], msg=Runtime failure on search row: TxKey 
[major=1564750080783, minor=1116]]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:5921)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1865)
at 
org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog.put(TxLog.java:294)
at 
org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.updateState(MvccProcessorImpl.java:695)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.setMvccState(IgniteTxManager.java:2551)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.state(IgniteTxAdapter.java:1227)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.state(IgniteTxAdapter.java:1069)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.prepareRemoteTx(GridDistributedTxRemoteAdapter.java:422)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.startRemoteTx(IgniteTxHandler.java:1855)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1201)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$400(IgniteTxHandler.java:121)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:225)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1602)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1227)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:131)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1124)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:550)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.IllegalStateException: Unexpected new transaction state. 
[currState=2, newState=1, cntr=1116]
at 
org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.invalid(TxLog.java:630)
at 
org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.checkAborted(TxLog.java:606)
at 
org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.call(TxLog.java:500)
at 
org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.call(TxLog.java:441)

[jira] [Updated] (IGNITE-12037) Ignore tests in MVCC PDS 3 suite canonically

2019-08-02 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-12037:

Reviewer: Andrew Mashenkov

> Ignore tests in MVCC PDS 3 suite canonically
> 
>
> Key: IGNITE-12037
> URL: https://issues.apache.org/jira/browse/IGNITE-12037
> Project: Ignite
>  Issue Type: Task
>  Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently tests in IgnitePdsMvccTestSuite3 are ignored using following 
> construction:
> {code}
> // TODO https://issues.apache.org/jira/browse/IGNITE-11937
> ignoredTests.add(IgnitePdsContinuousRestartTest.class);
> ignoredTests.add(IgnitePdsContinuousRestartTestWithExpiryPolicy.class);
> {code}
> But IgnitePdsContinuousRestartTestWithExpiryPolicy is already ignored (as 
> ExpiryPolicy is not supported for MVCC caches). And it worth to ignore tests 
> in IgnitePdsContinuousRestartTest explicitly so they will be listed as 
> ignored tests after execution.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12040) IgniteNodeStoppedDuringDisableWALTest.test[AFTER_DISABLE_WAL] fails in MVCC mode

2019-08-02 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-12040:
---

 Summary: 
IgniteNodeStoppedDuringDisableWALTest.test[AFTER_DISABLE_WAL] fails in MVCC mode
 Key: IGNITE-12040
 URL: https://issues.apache.org/jira/browse/IGNITE-12040
 Project: Ignite
  Issue Type: Bug
  Components: mvcc
Reporter: Ivan Pavlukhin


IgniteNodeStoppedDuringDisableWALTest.test[AFTER_DISABLE_WAL] fails in MVCC 
mode.
{noformat}
[2019-08-02 
12:59:35,836][ERROR][test-runner-#7379%wal.IgniteNodeStoppedDuringDisableWALTest%][IgniteTestResources]
 Critical system error detected. Will be handled accordingly to configured 
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler 
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, 
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class 
o.a.i.i.processors.cache.persistence.StorageException: Failed to read record by 
pointer [ptr=FileWALPointer [idx=0, fileOff=0, len=0], rec=IgniteBiTuple 
[val1=FileWALPointer [idx=0, fileOff=29, len=29], val2=MemoryRecoveryRecord 
[time=1564739950672, super=WALRecord [size=29, chainSize=0, pos=FileWALPointer 
[idx=0, fileOff=29, len=29], type=MEMORY_RECOVERY]]
class org.apache.ignite.internal.processors.cache.persistence.StorageException: 
Failed to read record by pointer [ptr=FileWALPointer [idx=0, fileOff=0, len=0], 
rec=IgniteBiTuple [val1=FileWALPointer [idx=0, fileOff=29, len=29], 
val2=MemoryRecoveryRecord [time=1564739950672, super=WALRecord [size=29, 
chainSize=0, pos=FileWALPointer [idx=0, fileOff=29, len=29], 
type=MEMORY_RECOVERY
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.read(FileWriteAheadLogManager.java:913)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.performBinaryMemoryRestore(GridCacheDatabaseSharedManager.java:2233)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:795)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:5461)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1167)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1987)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1687)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1110)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:608)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:970)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:911)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:899)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:865)
at 
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteNodeStoppedDuringDisableWALTest.testStopNodeWithDisableWAL(IgniteNodeStoppedDuringDisableWALTest.java:203)
at 
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteNodeStoppedDuringDisableWALTest.test(IgniteNodeStoppedDuringDisableWALTest.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2069)
at java.lang.Thread.run(Thread.java:748)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12039) CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails in MVCC mode

2019-08-02 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-12039:
---

 Summary: CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails in 
MVCC mode
 Key: IGNITE-12039
 URL: https://issues.apache.org/jira/browse/IGNITE-12039
 Project: Ignite
  Issue Type: Bug
  Components: mvcc
Reporter: Ivan Pavlukhin


CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails in MVCC mode.
{noformat}
java.lang.AssertionError: Renting partitions count when node returns not equals 
to moved partitions when node left
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:28)
at 
org.apache.ignite.internal.processors.cache.CacheGroupMetricsMBeanTest.testCacheGroupMetrics(CacheGroupMetricsMBeanTest.java:330)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2069)
at java.lang.Thread.run(Thread.java:748)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12037) Ignore tests in MVCC PDS 3 suite canonically

2019-08-02 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12037:
-

[TC 
run|https://ci.ignite.apache.org/viewLog.html?buildId=4453686=IgniteTests24Java8_MvccPds3]
 with ignored tests.

> Ignore tests in MVCC PDS 3 suite canonically
> 
>
> Key: IGNITE-12037
> URL: https://issues.apache.org/jira/browse/IGNITE-12037
> Project: Ignite
>  Issue Type: Task
>  Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently tests in IgnitePdsMvccTestSuite3 are ignored using following 
> construction:
> {code}
> // TODO https://issues.apache.org/jira/browse/IGNITE-11937
> ignoredTests.add(IgnitePdsContinuousRestartTest.class);
> ignoredTests.add(IgnitePdsContinuousRestartTestWithExpiryPolicy.class);
> {code}
> But IgnitePdsContinuousRestartTestWithExpiryPolicy is already ignored (as 
> ExpiryPolicy is not supported for MVCC caches). And it worth to ignore tests 
> in IgnitePdsContinuousRestartTest explicitly so they will be listed as 
> ignored tests after execution.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12037) Ignore tests in MVCC PDS 3 suite canonically

2019-08-02 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-12037:
---

 Summary: Ignore tests in MVCC PDS 3 suite canonically
 Key: IGNITE-12037
 URL: https://issues.apache.org/jira/browse/IGNITE-12037
 Project: Ignite
  Issue Type: Task
  Components: mvcc
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin


Currently tests in IgnitePdsMvccTestSuite3 are ignored using following 
construction:
{code}
// TODO https://issues.apache.org/jira/browse/IGNITE-11937
ignoredTests.add(IgnitePdsContinuousRestartTest.class);
ignoredTests.add(IgnitePdsContinuousRestartTestWithExpiryPolicy.class);
{code}
But IgnitePdsContinuousRestartTestWithExpiryPolicy is already ignored (as 
ExpiryPolicy is not supported for MVCC caches). And it worth to ignore tests in 
IgnitePdsContinuousRestartTest explicitly so they will be listed as ignored 
tests after execution.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-08-01 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-10973:
-

[~ivanan.fed], good news. Am I getting it right that the PR will be ready when 
a problem with .NET tests is solved?

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Resolved] (IGNITE-12031) node freeze and not able to login after few days stop and start the service give the message in description

2019-08-01 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin resolved IGNITE-12031.
-
Resolution: Duplicate

[~yabushaib], I resolved this ticket as a duplicate of IGNITE-12030. Feel free 
to reopen if I misunderstood something.

> node freeze and not able to login after few days stop and start the service 
> give the message in description
> ---
>
> Key: IGNITE-12031
> URL: https://issues.apache.org/jira/browse/IGNITE-12031
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.7.5
> Environment: Linux 7.5
>Reporter: Yaser Mohammad Abushaip
>Priority: Critical
> Fix For: None
>
>
> During startup I receive the below error
> Failed to wait for partition map exchange
> [topVer=AffinityTopologyVersion [topVer=2,minorTopVer=1],
> node=adfsdfdsfxx. Dumping pending objects that might be the cause
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12004) CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky

2019-07-26 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-12004:

Reviewer: Yury Gerzhedovich

> CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky
> --
>
> Key: IGNITE-12004
> URL: https://issues.apache.org/jira/browse/IGNITE-12004
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields fails often 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4227647830422954979=testDetails



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12016) Is there option to increase or decrease Ignite SQL Table backup count after its initialized?

2019-07-26 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12016:
-

Hi [~hirik],

I am not aware of such feature. Consider using _user mailing list_ for asking 
questions. You can find instructions at the very top of 
https://ignite.apache.org/community/resources.html

> Is there option to increase or decrease Ignite SQL Table backup count after 
> its initialized?
> 
>
> Key: IGNITE-12016
> URL: https://issues.apache.org/jira/browse/IGNITE-12016
> Project: Ignite
>  Issue Type: New Feature
>Reporter: hirik
>Priority: Major
>
> Hi, 
> We are working in a dynamic environment, based on the new nodes we should 
> update the backup count of existing SQL tables. is there any api available to 
> support this requirement? 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11373) varchar_ignorecase doesn't work properly

2019-07-25 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-11373:
-

[~ezhuravl], could we resolve this ticket as a duplicate of IGNITE-3999?

> varchar_ignorecase doesn't work properly
> 
>
> Key: IGNITE-11373
> URL: https://issues.apache.org/jira/browse/IGNITE-11373
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> Looks like a field with type varchar_ignorecase can't be used for filtering 
> the values for different cases.
> {code:java}
> Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
> 
> IgniteCache cache = ignite.getOrCreateCache("TEST");
> cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
> "(\n" +
> "  TEST_IDNUMBER(15)NOT NULL,\n" +
> "  TEST_VALUE VARCHAR_IGNORECASE(100),\n" +
> "  PRIMARY KEY (TEST_ID)\n" +
> ") "));
> System.out.println("INSERTED:" + ignite.cache("TEST").query(new 
> SqlFieldsQuery("INSERT INTO TEST values (1,'aAa')")).getAll().size());
> System.out.println("FOUND:" + ignite.cache("TEST").query(new 
> SqlFieldsQuery("Select * from TEST where TEST_VALUE like 
> '%aaa%'")).getAll().size());
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12015) Text caseinsensitive search

2019-07-25 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12015:
-

[~hirik], {{VARCHAR_IGNORECASE}} is not supported in Ignite. Could we resolve 
this ticket as a duplicate of IGNITE-3999?

> Text caseinsensitive search 
> 
>
> Key: IGNITE-12015
> URL: https://issues.apache.org/jira/browse/IGNITE-12015
> Project: Ignite
>  Issue Type: Improvement
>Reporter: hirik
>Priority: Critical
>
> Hi,
> I'm looking for 
> [VARCHAR_IGNORECASE|http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type]
>  kind of datatype in Ignite SQL for text ignore-case search. Is there any 
> reason for this not available in Ignite even though Apache Ignite SQL engine 
> is tightly coupled with H2 database?  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-25 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-10973:
-

[~ivanan.fed], I suppose that we should fix .NET tests somehow. Apparently now 
we are ready to start massive migration to junit5. And so we should announce it 
to dev-list to discuss a strategy for the massive migration.

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12004) CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky

2019-07-24 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12004:
-

Rerun a suite containing a changed test class 
https://ci.ignite.apache.org/viewLog.html?buildId=4387614=IgniteTests24Java8_Queries2

> CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky
> --
>
> Key: IGNITE-12004
> URL: https://issues.apache.org/jira/browse/IGNITE-12004
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields fails often 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4227647830422954979=testDetails



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12004) CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky

2019-07-24 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12004:
-

SQL {{UPDATE}} trims precision more than milliseconds for {{LocalTime}}. 
Created a ticket for investigation IGNITE-12009.

Was reproduced only for Java 9+ because of increased precision of system clock. 
Employed nanosecond precision in tests explicitly. Ignored a test for UPDATE 
with nanos precision and added a test for UPDATE with millis precision instead.

> CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky
> --
>
> Key: IGNITE-12004
> URL: https://issues.apache.org/jira/browse/IGNITE-12004
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields fails often 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4227647830422954979=testDetails



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12009) Clarify java.time.LocalTime mapping in SQL queries

2019-07-24 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-12009:
---

 Summary: Clarify java.time.LocalTime mapping in SQL queries
 Key: IGNITE-12009
 URL: https://issues.apache.org/jira/browse/IGNITE-12009
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.7.5
Reporter: Ivan Pavlukhin


Currently mappings between, java.time. java.sql and h2 temporal types provokes 
some surprising behavior. Need to figure out if there are bugs or it is an 
expected behavior.

One example is using java.time.LocalTime as QueryEntity field. If a value of 
such column is modified by SQL {{UPDATE}} then precision more than milliseconds 
is lost.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12002) [TTL] Some expired data remains in memory even with eager TTL enabled

2019-07-23 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12002:
-

[~panes], kind of discussion was held in 
http://apache-ignite-developers.2346864.n4.nabble.com/apache-Ignite-2-8-release-date-td42748.html
 I suppose it means at least that it will be no earlier than October.

> [TTL] Some expired data remains in memory even with eager TTL enabled
> -
>
> Key: IGNITE-12002
> URL: https://issues.apache.org/jira/browse/IGNITE-12002
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 2.7
> Environment: Running on MacOS 10.12.6
> OpenJDK 11
> Ignite v2.7.0
>  
>Reporter: Philippe Anes
>Priority: Major
>
> Create an ignite client (in client mode false) and put some data (10k 
> entries/values) to it with very small expiration time (~20s) and TTL enabled.
>  Each time the thread is running it'll remove all the entries that expired, 
> but after few attempts this thread is not removing all the expired entries, 
> some of them are staying in memory and are not removed by this thread 
> execution.
>  That means we got some expired data in memory, and it's something we want to 
> avoid.
> Please can you confirm that is a real issue or just misuse/configuration of 
> my test?
> Thanks for your feedback.
>  
> To reproduce:
> Git repo: [https://github.com/panes/ignite-sample]
> Run MyIgniteLoadRunnerTest.run() to reproduce the issue described on top.
> (Global setup: Writing 10k entries of 64octets each with TTL 10s)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12004) CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky

2019-07-22 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-12004:
---

 Summary: 
CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky
 Key: IGNITE-12004
 URL: https://issues.apache.org/jira/browse/IGNITE-12004
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.7.5
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin


CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields fails often 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4227647830422954979=testDetails



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12003) Java thin client fails to get object with compact footer from cache

2019-07-22 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-12003:

Description: 
Experiment:
1. Start server.
2. Start thin client, configure to use compact footer. Put some Pojo into cache.
3. Start another client (compact footer enabled). Try to read Pojo saved in 
previous step (Pojo class is available).
Result -- {{BinaryObjectException("Cannot find metadata for object with compact 
footer: " + typeId)}}.

See attached reproducer.

  was:
Experiment:
1. Start server.
2. Start thin client, configure to use compact footer. Put some Pojo into cache.
3. Start another client (compact footer enabled). Try to read Pojo saved in 
previous step (Pojo class is available).
Result -- {{BinaryObjectException("Cannot find metadata for object with compact 
footer: " + typeId)}}.


> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into 
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in 
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with 
> compact footer: " + typeId)}}.
> See attached reproducer.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12003) Java thin client fails to get object with compact footer from cache

2019-07-22 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-12003:

Attachment: ThinClientCompactFooterDeserializationProblem.java

> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into 
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in 
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with 
> compact footer: " + typeId)}}.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12003) Java thin client fails to get object with compact footer from cache

2019-07-22 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-12003:
---

 Summary: Java thin client fails to get object with compact footer 
from cache
 Key: IGNITE-12003
 URL: https://issues.apache.org/jira/browse/IGNITE-12003
 Project: Ignite
  Issue Type: Bug
  Components: thin client
Affects Versions: 2.7.5
Reporter: Ivan Pavlukhin


Experiment:
1. Start server.
2. Start thin client, configure to use compact footer. Put some Pojo into cache.
3. Start another client (compact footer enabled). Try to read Pojo saved in 
previous step (Pojo class is available).
Result -- {{BinaryObjectException("Cannot find metadata for object with compact 
footer: " + typeId)}}.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12002) [TTL] Some expired data remains in memory even with eager TTL enabled

2019-07-22 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12002:
-

[~panes], it seems that similar problem was fixed in IGNITE-11438. It would be 
great to check your reproducer against master branch.

> [TTL] Some expired data remains in memory even with eager TTL enabled
> -
>
> Key: IGNITE-12002
> URL: https://issues.apache.org/jira/browse/IGNITE-12002
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 2.7
> Environment: Running on MacOS 10.12.6
> OpenJDK 11
> Ignite v2.7.0
>  
>Reporter: Philippe Anes
>Priority: Major
>
> Create an ignite client (in client mode false) and put some data (10k 
> entries/values) to it with very small expiration time (~20s) and TTL enabled.
>  Each time the thread is running it'll remove all the entries that expired, 
> but after few attempts this thread is not removing all the expired entries, 
> some of them are staying in memory and are not removed by this thread 
> execution.
>  That means we got some expired data in memory, and it's something we want to 
> avoid.
> Please can you confirm that is a real issue or just misuse/configuration of 
> my test?
> Thanks for your feedback.
>  
> To reproduce:
> Git repo: [https://github.com/panes/ignite-sample]
> Run MyIgniteLoadRunnerTest.run() to reproduce the issue described on top.
> (Global setup: Writing 10k entries of 64octets each with TTL 10s)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12001) SchemaExchangeSelfTest.testServerRestartWithNewTypes is flaky

2019-07-19 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-12001:
---

 Summary: SchemaExchangeSelfTest.testServerRestartWithNewTypes is 
flaky
 Key: IGNITE-12001
 URL: https://issues.apache.org/jira/browse/IGNITE-12001
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin


SchemaExchangeSelfTest.testServerRestartWithNewTypes is flaky.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12000) IgniteSqlQueryMinMaxTest is flaky

2019-07-19 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12000:
-

[TC 
runs|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BinaryObjectsSimpleMapperQueries?branch=pull%2F6708%2Fhead=overview]
 do not contain failures for the fixed test. Also confirmed by multiple runs 
locally.

> IgniteSqlQueryMinMaxTest is flaky
> -
>
> Key: IGNITE-12000
> URL: https://issues.apache.org/jira/browse/IGNITE-12000
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> IgniteSqlQueryMinMaxTest is flaky.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Resolved] (IGNITE-7354) H2 Debug Console should be marked as deprecated.

2019-07-19 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin resolved IGNITE-7354.

Resolution: Duplicate

Resolved because duplicates IGNITE-11333

> H2 Debug Console should be marked as deprecated.
> 
>
> Key: IGNITE-7354
> URL: https://issues.apache.org/jira/browse/IGNITE-7354
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vyacheslav Koptilin
>Priority: Minor
>
> It seems H2 Debug Console is a legacy tool and does not support all 
> capabilities provided by Apache Ignite SQL engine.
> So, it should be marked as deprecated. The documentation page 
> https://apacheignite-net.readme.io/docs/sql-queries#using-h2-debug-console 
> should be updated as well in order to provide more powerful and convenient 
> tools like WebConsole, SQLLine etc.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11248) H2 Debug Console reports NPE when launched

2019-07-19 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-11248:
-

[~ilyak], can we close the issue as H2 Debug console is not available after 
IGNITE-11333.

> H2 Debug Console reports NPE when launched
> --
>
> Key: IGNITE-11248
> URL: https://issues.apache.org/jira/browse/IGNITE-11248
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Priority: Minor
>
> Reliably happens on invocation of 
> IGNITE_H2_DEBUG_CONSOLE=true bin/ignite.sh
> {code}
> Внутренняя ошибка: "java.lang.NullPointerException"
> General error: "java.lang.NullPointerException"; SQL statement:
> SELECT TABLE_CAT, TABLE_SCHEM, TABLE_NAME, TABLE_TYPE, REMARKS, TYPE_CAT, 
> TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, REF_GENERATION, SQL FROM 
> (SELECT SYNONYM_CATALOG TABLE_CAT, SYNONYM_SCHEMA TABLE_SCHEM, SYNONYM_NAME 
> as TABLE_NAME, TYPE_NAME AS TABLE_TYPE, REMARKS, TYPE_NAME TYPE_CAT, 
> TYPE_NAME TYPE_SCHEM, TYPE_NAME AS TYPE_NAME, TYPE_NAME 
> SELF_REFERENCING_COL_NAME, TYPE_NAME REF_GENERATION, NULL AS SQL FROM 
> INFORMATION_SCHEMA.SYNONYMS WHERE SYNONYM_CATALOG LIKE ? ESCAPE ? AND 
> SYNONYM_SCHEMA LIKE ? ESCAPE ? AND SYNONYM_NAME LIKE ? ESCAPE ? AND (true)  
> UNION SELECT TABLE_CATALOG TABLE_CAT, TABLE_SCHEMA TABLE_SCHEM, TABLE_NAME, 
> TABLE_TYPE, REMARKS, TYPE_NAME TYPE_CAT, TYPE_NAME TYPE_SCHEM, TYPE_NAME, 
> TYPE_NAME SELF_REFERENCING_COL_NAME, TYPE_NAME REF_GENERATION, SQL FROM 
> INFORMATION_SCHEMA.TABLES WHERE TABLE_CATALOG LIKE ? ESCAPE ? AND 
> TABLE_SCHEMA LIKE ? ESCAPE ? AND TABLE_NAME LIKE ? ESCAPE ? AND (TABLE_TYPE 
> IN(?, ?, ?, ?, ?, ?, ?)) ) ORDER BY TABLE_TYPE, TABLE_SCHEM, TABLE_NAME 
> [5-197] HY000/5
> {code}
> in browser window that is opened.
> Reportedly, used to work just fine 2.6



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (IGNITE-11996) Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore

2019-07-19 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin reassigned IGNITE-11996:
---

Assignee: (was: Ivan Pavlukhin)

> Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore
> --
>
> Key: IGNITE-11996
> URL: https://issues.apache.org/jira/browse/IGNITE-11996
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Assertion error occurs in IgniteCacheOffheapManagerImpl#destroyCacheDataStore 
> in a following code:
> {code}
> boolean removed = partDataStores.remove(p, store);
> assert removed;
> {code}
> It asserts that a partition store must be removed from a map here. But in 
> practice a removal can occur at least in 2 places: node stop and partition 
> eviction. Employed synchronization is not sufficient to guarantee that a 
> removal happens exactly once.
> The issue is reproduced in {{IgniteSqlQueryMinMaxTest}} from time to time.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12000) IgniteSqlQueryMinMaxTest is flaky

2019-07-19 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-12000:
---

 Summary: IgniteSqlQueryMinMaxTest is flaky
 Key: IGNITE-12000
 URL: https://issues.apache.org/jira/browse/IGNITE-12000
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.7.5
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin


IgniteSqlQueryMinMaxTest is flaky.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-11996) Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore

2019-07-19 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-11996:

Description: 
Assertion error occurs in IgniteCacheOffheapManagerImpl#destroyCacheDataStore 
in a following code:
{code}
boolean removed = partDataStores.remove(p, store);

assert removed;
{code}

It asserts that a partition store must be removed from a map here. But in 
practice a removal can occur at least in 2 places: node stop and partition 
eviction. Employed synchronization is not sufficient to guarantee that a 
removal happens exactly once.

The issue is reproduced in {{IgniteSqlQueryMinMaxTest}} from time to time.

  was:
Assertion error occurs in a following code:
{code}
boolean removed = partDataStores.remove(p, store);

assert removed;
{code}

It asserts that a partition store must be removed from a map here. But in 
practice a removal can occur at least in 2 places: node stop and partition 
eviction. Employed synchronization is not sufficient to guarantee that a 
removal happens exactly once.

The issue is reproduced in {{IgniteSqlQueryMinMaxTest}} from time to time.


> Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore
> --
>
> Key: IGNITE-11996
> URL: https://issues.apache.org/jira/browse/IGNITE-11996
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Assertion error occurs in IgniteCacheOffheapManagerImpl#destroyCacheDataStore 
> in a following code:
> {code}
> boolean removed = partDataStores.remove(p, store);
> assert removed;
> {code}
> It asserts that a partition store must be removed from a map here. But in 
> practice a removal can occur at least in 2 places: node stop and partition 
> eviction. Employed synchronization is not sufficient to guarantee that a 
> removal happens exactly once.
> The issue is reproduced in {{IgniteSqlQueryMinMaxTest}} from time to time.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11996) Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore

2019-07-19 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-11996:
-

Linked PR [#6705|https://github.com/apache/ignite/pull/6705] contains a code 
allowing to reproduce the issue easiliy.

> Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore
> --
>
> Key: IGNITE-11996
> URL: https://issues.apache.org/jira/browse/IGNITE-11996
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Assertion error occurs in a following code:
> {code}
> boolean removed = partDataStores.remove(p, store);
> assert removed;
> {code}
> It asserts that a partition store must be removed from a map here. But in 
> practice a removal can occur at least in 2 places: node stop and partition 
> eviction. Employed synchronization is not sufficient to guarantee that a 
> removal happens exactly once.
> The issue is reproduced in {{IgniteSqlQueryMinMaxTest}} from time to time.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-11996) Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore

2019-07-18 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-11996:

Description: 
Assertion error occurs in a following code:
{code}
boolean removed = partDataStores.remove(p, store);

assert removed;
{code}

It asserts that a partition store must be removed from a map here. But in 
practice a removal can occur at least in 2 places: node stop and partition 
eviction. Employed synchronization is not sufficient to guarantee that a 
removal happens exactly once.

The issues is reproduced in {{IgniteSqlQueryMinMaxTest}} from time to time.

  was:
Assertion error occurs in a following code:
{code}
boolean removed = partDataStores.remove(p, store);

assert removed;
{code}

It asserts that a partition store must be removed from a map here. But in 
practice a removal can occur at least in 2 places: node stop and partition 
eviction. Employed synchronization is not sufficient to guarantee that a 
removal happens exactly once.


> Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore
> --
>
> Key: IGNITE-11996
> URL: https://issues.apache.org/jira/browse/IGNITE-11996
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>
> Assertion error occurs in a following code:
> {code}
> boolean removed = partDataStores.remove(p, store);
> assert removed;
> {code}
> It asserts that a partition store must be removed from a map here. But in 
> practice a removal can occur at least in 2 places: node stop and partition 
> eviction. Employed synchronization is not sufficient to guarantee that a 
> removal happens exactly once.
> The issues is reproduced in {{IgniteSqlQueryMinMaxTest}} from time to time.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-11996) Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore

2019-07-18 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-11996:

Description: 
Assertion error occurs in a following code:
{code}
boolean removed = partDataStores.remove(p, store);

assert removed;
{code}

It asserts that a partition store must be removed from a map here. But in 
practice a removal can occur at least in 2 places: node stop and partition 
eviction. Employed synchronization is not sufficient to guarantee that a 
removal happens exactly once.

The issue is reproduced in {{IgniteSqlQueryMinMaxTest}} from time to time.

  was:
Assertion error occurs in a following code:
{code}
boolean removed = partDataStores.remove(p, store);

assert removed;
{code}

It asserts that a partition store must be removed from a map here. But in 
practice a removal can occur at least in 2 places: node stop and partition 
eviction. Employed synchronization is not sufficient to guarantee that a 
removal happens exactly once.

The issues is reproduced in {{IgniteSqlQueryMinMaxTest}} from time to time.


> Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore
> --
>
> Key: IGNITE-11996
> URL: https://issues.apache.org/jira/browse/IGNITE-11996
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>
> Assertion error occurs in a following code:
> {code}
> boolean removed = partDataStores.remove(p, store);
> assert removed;
> {code}
> It asserts that a partition store must be removed from a map here. But in 
> practice a removal can occur at least in 2 places: node stop and partition 
> eviction. Employed synchronization is not sufficient to guarantee that a 
> removal happens exactly once.
> The issue is reproduced in {{IgniteSqlQueryMinMaxTest}} from time to time.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-11996) Assertion error in IgniteCacheOffheapManagerImpl#destroyCacheDataStore

2019-07-18 Thread Ivan Pavlukhin (JIRA)
Ivan Pavlukhin created IGNITE-11996:
---

 Summary: Assertion error in 
IgniteCacheOffheapManagerImpl#destroyCacheDataStore
 Key: IGNITE-11996
 URL: https://issues.apache.org/jira/browse/IGNITE-11996
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.7.5
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin


Assertion error occurs in a following code:
{code}
boolean removed = partDataStores.remove(p, store);

assert removed;
{code}

It asserts that a partition store must be removed from a map here. But in 
practice a removal can occur at least in 2 places: node stop and partition 
eviction. Employed synchronization is not sufficient to guarantee that a 
removal happens exactly once.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11985) .NET: CompiledQuery.Compile does not work with string parameters

2019-07-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-11985:
-

[~ptupitsyn], [~ashapkin], does not this ticket duplicate 
https://issues.apache.org/jira/browse/IGNITE-11984 ?

> .NET: CompiledQuery.Compile does not work with string parameters
> 
>
> Key: IGNITE-11985
> URL: https://issues.apache.org/jira/browse/IGNITE-11985
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> String parameters always produce an exception, example:
> {code}
> CompiledQuery.Compile((string empName) => persons.Where(x => x.Value.Name == 
> empName))
> {code}
> Result:
> {code}
> System.InvalidOperationException: Error compiling query: entire LINQ 
> expression should be specified within lambda passed to Compile method. Part 
> of the query can't be outside the Compile method call.
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-12 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-10973:
-

[~ivanan.fed], by the way, do you have any idea what is wrong with .NET tests? 
It seems that the same tests do not fail in master.

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-12 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-10973:
-

[~ivanan.fed], so, it seems that different names are caused by 
{{surefire-junit47}} dependency. And actually I do not see a reason against 
using it as we have been using junit 4.11 for a while. And yes, I guess 
{{@UseTechnicalNames}} can be related to junit5 tests only (examples here).

So, I suppose we should return to dev-list announcing at least following:
1. First junit5 tests are going to appear in master.
2. Change in test report naming will obsolete TC bot history.

By the way, what is the plan for dealing with junit4 {{@Parameterized}} and 
{{@Rule}}. I suppose that we already have them used in several places.

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class

2019-07-10 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-11907:
-

[~rkondakov], [~jooger], thank you for review I fixed all points except
{quote} 1) IncompleteDeserializationExceptionTest - commented code at the 
end{quote}
I would prefer to keep commented lines because they explains how a file with 
serialized object is generated. Unfortunately it is not possible to uncomment 
them because test will not work as expected (class should not be available at 
runtime).

> Registration of continuous query should fail if nodes don't have remote 
> filter class
> 
>
> Key: IGNITE-11907
> URL: https://issues.apache.org/jira/browse/IGNITE-11907
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Attachments: 
> ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If one of data nodes doesn't have a remote filter class, then registration of 
> continuous queries should fail with an exception. Currently nodes fail 
> instead.
> Reproducer is attached: 
> [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java]



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


[jira] [Commented] (IGNITE-711) [Java 8 Examples] Need to complete implementation of Java 8 examples.

2019-07-09 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-711:
---

[~ivanan.fed], I left a couple of comments on 
[GitHub|https://github.com/apache/ignite/pull/6672#pullrequestreview-259440315].

> [Java 8 Examples] Need to complete implementation of Java 8 examples.
> -
>
> Key: IGNITE-711
> URL: https://issues.apache.org/jira/browse/IGNITE-711
> Project: Ignite
>  Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> There are next examples for java 7, but there are no for java 8. Need to 
> implement if they are applicable for java 8.
> // BasicExamplesSelfTest
> - ComputeReducerExample
> - ComputeTaskMapExample
> - ComputeTaskSplitExample
> // CacheExamplesSelfTest:
> - IgniteAtomicLongExample.main
> - IgniteAtomicReferenceExample.main
> - IgniteAtomicSequenceExample.main
> - IgniteAtomicStampedExample.main
> - IgniteCountDownLatchExample.main
> - IgniteQueueExample.main
> - IgniteSetExample.main
> - CacheDummyStoreExample.main
> - CacheQueryExample.main
> - CacheTransactionExample.main
> - CacheDataStreamerExample.main
> - CachePutGetExample.main
> - CacheStarSchemaExample.main
> - CacheContinuousQueryExample.main
> // CheckpointExamplesSelfTest
> - ComputeFailoverExample 
> // ClusterGroupExampleSelfTest
> - ClusterGroupExample
> // ContinuationExamplesSelfTest
>  - ComputeFibonacciContinuationExample
> // ContinuousMapperExamplesSelfTest
> - ComputeContinuousMapperExample
> - DeploymentExamplesMultiNodeSelfTest # testDeploymentExample
> - DeploymentExamplesSelfTest # testDeploymentExample
> // HibernateL2CacheExampleSelfTest
> - HibernateL2CacheExample
> - IgfsExamplesSelfTest # testIgniteFsApiExample
> // LifecycleExamplesSelfTest
> - LifecycleExample
> - look at MemcacheRestExamplesMultiNodeSelfTest
> - MemcacheRestExample
> - CreditRiskExample
> - SpringBeanExample
> - ComputeTaskSplitExample
> - ComputeTaskMapExample
> Examples should be implemented for java 8 or testing methods should be 
> removed if examples do not applicable for java 8.



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


  1   2   3   4   5   6   >