[jira] [Resolved] (IGNITE-6045) Hibernate dialect for Ignite

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov resolved IGNITE-6045.
-
Resolution: Won't Fix  (was: Fixed)

> Hibernate dialect for Ignite
> 
>
> Key: IGNITE-6045
> URL: https://issues.apache.org/jira/browse/IGNITE-6045
> Project: Ignite
>  Issue Type: Task
>  Components: hibernate, sql
>Reporter: Dmitriy Setrakyan
>Priority: Major
>
> Given that we have a very rich SQL support starting with version 2.1, it 
> makes sense to create an Ignite SQL dialect for Hibernate?
> https://docs.jboss.org/hibernate/orm/3.6/reference/en-US/html/session-configuration.html#configuration-optional-dialects



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


[jira] [Resolved] (IGNITE-1024) Failed to find SQL Table exception is thrown when indexing is not in the classpath

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov resolved IGNITE-1024.
-
Resolution: Won't Fix  (was: Fixed)

> Failed to find SQL Table exception is thrown when indexing is not in the 
> classpath
> --
>
> Key: IGNITE-1024
> URL: https://issues.apache.org/jira/browse/IGNITE-1024
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: Usability
>
> When indexing is disabled but user tries to set indexed types, no warning is 
> printed and when user tries to run an SQL query, the following exception is 
> thrown:
> {{javax.cache.CacheException: Failed to find SQL table for type: MyClass}}
> Ignite should give a proper warning on startup when indexed types are set and 
> indexing is not enabled and also throw a correct exception when SQL queries 
> are used.



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


[jira] [Resolved] (IGNITE-6877) Improve behaviour for non-correlated subqueries

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov resolved IGNITE-6877.
-
Resolution: Won't Fix  (was: Fixed)

> Improve behaviour for non-correlated subqueries
> ---
>
> Key: IGNITE-6877
> URL: https://issues.apache.org/jira/browse/IGNITE-6877
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Alin Andrei Corodescu
>Priority: Minor
>
> Ignite behaves poorly in terms of performance when given queries which 
> contain IN or = operators followed by a non-correlated subquery. My guess is 
> that the query is actually run for each row of the table in order to test the 
> condition. 
> A possible solution is to store the results of the subquery in a temporary 
> table, and use it from there.
> A workaround at the moment is to use joins instead of IN or = operators, but 
> this makes the query much more complicated.
> Example:
> SELECT name
> FROM Employees
> WHERE age IN (SELECT age FROM Customers)
> The performance of this query is very slow for small amounts of data (about 
> 20 seconds for 4000 rows in each table last time I tried)



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


[jira] [Resolved] (IGNITE-1141) Check if sorting is done over aggregated expression, otherwise we can sort and use offset-limit.

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov resolved IGNITE-1141.
-
Resolution: Won't Fix  (was: Fixed)

> Check if sorting is done over aggregated expression, otherwise we can sort 
> and use offset-limit.
> 
>
> Key: IGNITE-1141
> URL: https://issues.apache.org/jira/browse/IGNITE-1141
> Project: Ignite
>  Issue Type: Wish
>  Components: sql
>Reporter: Sergi Vladykin
>Priority: Major
>  Labels: sql-splitter
>
> See TODO in splitter



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


[jira] [Closed] (IGNITE-6409) SQL: bypass H2 during index update

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-6409.
---

> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: performance
>
> Currently the only way to update standard user index is through H2 
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
> we have to construct a kind of H2 row which will be passed to index. This 
> operation might require unnecessary memory copying and deserializations. We 
> should try to find a way to bypass H2 stuff altogether and add data to 
> underlying {{BPlusTree}} directly.
> Here is how this could be achieved:
> 1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
> ({{InlineIndexHelper}}, {{H2*IO}}). 
> 2) We should remove all H2 stuff from there, and start using {{CacheDataRow}} 
> instead of {{SearchRow}}
> 3) Refactored classes should be moved to core module.
> 4) Conversion to {{SearchRow}} should happen inside {{H2TreeIndex}} only when 
> it is really needed.
> 5) Two operations {{putNative}} and {{getNative}} should be added to 
> {{GridH2IndexBase}}. They should accept normal key-value objects instead of 
> H2 rows.
> 6) Finally, all index index update routines (cache put/get, {{CREATE INDEX}}) 
> should be moved to {{putNative}}/{{getNative}} methods.
> Note that IO classes should be reworked carefully to maintain backward 
> compatibility.



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


[jira] [Assigned] (IGNITE-11096) Webagent: flag --disable-demo doesn't work

2019-02-17 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko reassigned IGNITE-11096:
--

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Webagent: flag --disable-demo doesn't work
> --
>
> Key: IGNITE-11096
> URL: https://issues.apache.org/jira/browse/IGNITE-11096
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.7
> Environment: After enabling this flag it's still possible to start 
> demo
>Reporter: Evgenii Zhuravlev
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.8
>
> Attachments: image-2019-02-13-13-55-51-248.png, screenshot-1.png
>
>




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


[jira] [Resolved] (IGNITE-2906) Embedded / child element types indexing/queryfields (non-flat)

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov resolved IGNITE-2906.
-
Resolution: Won't Fix  (was: Fixed)

> Embedded / child element types indexing/queryfields (non-flat)
> --
>
> Key: IGNITE-2906
> URL: https://issues.apache.org/jira/browse/IGNITE-2906
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, data structures, general, sql
>Reporter: Krome Plasma
>Priority: Major
> Attachments: indexing.patch
>
>
> I've had discussion about this on Apache Ignite Users.
> http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
> The problem occurs when you want to index a non-primitive type that have same 
> names of variables as the enclosing type, better described on forum above. As 
> a short example:
> Let's say we want to index:
> public class Person
> {
>  @QuerySqlField 
>  long id;
>  @QuerySqlField 
>  PersonData personData;
> }
> public class PersonData
> {
>  @QuerySqlField 
>  long id;
> }
> This will not work as it will detect indexes/query fields with same names for 
> index Person.id and PersonData.id because the names are flattened to simply 
> 'id'.
> I am attaching a simple patch that resolves this issue. We've been running 
> this for (3 months now) and found no problems. However we are using 
> annotations and not XML. I am not sure the patch completely solves the 
> problem for XML based configuration.



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


[jira] [Closed] (IGNITE-1140) Find aggregate functions in HAVING clause or rewrite query to put all aggregates to SELECT clause.

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-1140.
---

> Find aggregate functions in HAVING clause or rewrite query to put all 
> aggregates to SELECT clause.
> --
>
> Key: IGNITE-1140
> URL: https://issues.apache.org/jira/browse/IGNITE-1140
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Sergi Vladykin
>Priority: Major
>  Labels: sql-splitter
>
> See TODO in Splitter



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


[jira] [Closed] (IGNITE-3415) UNION query does not remove duplicates

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-3415.
---

> UNION query does not remove duplicates
> --
>
> Key: IGNITE-3415
> URL: https://issues.apache.org/jira/browse/IGNITE-3415
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 1.6
>Reporter: Semen Boikov
>Priority: Major
>  Labels: sql-splitter
>
> Looks like UNION query does not remove duplicates on reduce step.
> Added test reproducing issue - IgniteCacheUnionDuplicatesTest.



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


[jira] [Resolved] (IGNITE-1140) Find aggregate functions in HAVING clause or rewrite query to put all aggregates to SELECT clause.

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov resolved IGNITE-1140.
-
Resolution: Won't Fix  (was: Fixed)

> Find aggregate functions in HAVING clause or rewrite query to put all 
> aggregates to SELECT clause.
> --
>
> Key: IGNITE-1140
> URL: https://issues.apache.org/jira/browse/IGNITE-1140
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Sergi Vladykin
>Priority: Major
>  Labels: sql-splitter
>
> See TODO in Splitter



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


[jira] [Resolved] (IGNITE-6518) Smarter analysis of INSERT and MERGE statements at parsing stage

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov resolved IGNITE-6518.
-
Resolution: Won't Fix  (was: Fixed)

> Smarter analysis of INSERT and MERGE statements at parsing stage
> 
>
> Key: IGNITE-6518
> URL: https://issues.apache.org/jira/browse/IGNITE-6518
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Alexander Paschenko
>Priority: Major
>
> We could analyze INSERT and MERGE statements to detect that they don't 
> specify data for key and/or value to notify users early that their query 
> can't be executed within Ignite - prior to building plans and attempting to 
> actually do anything.
> (Note how we check that CREATE TABLE doesn't declare columns for key - logic 
> here would be similar.)



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


[jira] [Closed] (IGNITE-6518) Smarter analysis of INSERT and MERGE statements at parsing stage

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-6518.
---

> Smarter analysis of INSERT and MERGE statements at parsing stage
> 
>
> Key: IGNITE-6518
> URL: https://issues.apache.org/jira/browse/IGNITE-6518
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Alexander Paschenko
>Priority: Major
>
> We could analyze INSERT and MERGE statements to detect that they don't 
> specify data for key and/or value to notify users early that their query 
> can't be executed within Ignite - prior to building plans and attempting to 
> actually do anything.
> (Note how we check that CREATE TABLE doesn't declare columns for key - logic 
> here would be similar.)



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


[jira] [Resolved] (IGNITE-3415) UNION query does not remove duplicates

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov resolved IGNITE-3415.
-
Resolution: Won't Fix  (was: Fixed)

> UNION query does not remove duplicates
> --
>
> Key: IGNITE-3415
> URL: https://issues.apache.org/jira/browse/IGNITE-3415
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 1.6
>Reporter: Semen Boikov
>Priority: Major
>  Labels: sql-splitter
>
> Looks like UNION query does not remove duplicates on reduce step.
> Added test reproducing issue - IgniteCacheUnionDuplicatesTest.



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


[jira] [Closed] (IGNITE-6045) Hibernate dialect for Ignite

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-6045.
---

> Hibernate dialect for Ignite
> 
>
> Key: IGNITE-6045
> URL: https://issues.apache.org/jira/browse/IGNITE-6045
> Project: Ignite
>  Issue Type: Task
>  Components: hibernate, sql
>Reporter: Dmitriy Setrakyan
>Priority: Major
>
> Given that we have a very rich SQL support starting with version 2.1, it 
> makes sense to create an Ignite SQL dialect for Hibernate?
> https://docs.jboss.org/hibernate/orm/3.6/reference/en-US/html/session-configuration.html#configuration-optional-dialects



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


[jira] [Closed] (IGNITE-1141) Check if sorting is done over aggregated expression, otherwise we can sort and use offset-limit.

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-1141.
---

> Check if sorting is done over aggregated expression, otherwise we can sort 
> and use offset-limit.
> 
>
> Key: IGNITE-1141
> URL: https://issues.apache.org/jira/browse/IGNITE-1141
> Project: Ignite
>  Issue Type: Wish
>  Components: sql
>Reporter: Sergi Vladykin
>Priority: Major
>  Labels: sql-splitter
>
> See TODO in splitter



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


[jira] [Closed] (IGNITE-6877) Improve behaviour for non-correlated subqueries

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-6877.
---

> Improve behaviour for non-correlated subqueries
> ---
>
> Key: IGNITE-6877
> URL: https://issues.apache.org/jira/browse/IGNITE-6877
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Alin Andrei Corodescu
>Priority: Minor
>
> Ignite behaves poorly in terms of performance when given queries which 
> contain IN or = operators followed by a non-correlated subquery. My guess is 
> that the query is actually run for each row of the table in order to test the 
> condition. 
> A possible solution is to store the results of the subquery in a temporary 
> table, and use it from there.
> A workaround at the moment is to use joins instead of IN or = operators, but 
> this makes the query much more complicated.
> Example:
> SELECT name
> FROM Employees
> WHERE age IN (SELECT age FROM Customers)
> The performance of this query is very slow for small amounts of data (about 
> 20 seconds for 4000 rows in each table last time I tried)



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


[jira] [Resolved] (IGNITE-6409) SQL: bypass H2 during index update

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov resolved IGNITE-6409.
-
Resolution: Won't Fix  (was: Fixed)

> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: performance
>
> Currently the only way to update standard user index is through H2 
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
> we have to construct a kind of H2 row which will be passed to index. This 
> operation might require unnecessary memory copying and deserializations. We 
> should try to find a way to bypass H2 stuff altogether and add data to 
> underlying {{BPlusTree}} directly.
> Here is how this could be achieved:
> 1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
> ({{InlineIndexHelper}}, {{H2*IO}}). 
> 2) We should remove all H2 stuff from there, and start using {{CacheDataRow}} 
> instead of {{SearchRow}}
> 3) Refactored classes should be moved to core module.
> 4) Conversion to {{SearchRow}} should happen inside {{H2TreeIndex}} only when 
> it is really needed.
> 5) Two operations {{putNative}} and {{getNative}} should be added to 
> {{GridH2IndexBase}}. They should accept normal key-value objects instead of 
> H2 rows.
> 6) Finally, all index index update routines (cache put/get, {{CREATE INDEX}}) 
> should be moved to {{putNative}}/{{getNative}} methods.
> Note that IO classes should be reworked carefully to maintain backward 
> compatibility.



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


[jira] [Commented] (IGNITE-11096) Webagent: flag --disable-demo doesn't work

2019-02-17 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko commented on IGNITE-11096:


++Fixed launch of demo mode when agent in not connected to Web console.

> Webagent: flag --disable-demo doesn't work
> --
>
> Key: IGNITE-11096
> URL: https://issues.apache.org/jira/browse/IGNITE-11096
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.7
> Environment: After enabling this flag it's still possible to start 
> demo
>Reporter: Evgenii Zhuravlev
>Assignee: Vasiliy Sisko
>Priority: Major
> Fix For: 2.8
>
> Attachments: image-2019-02-13-13-55-51-248.png, screenshot-1.png
>
>




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


[jira] [Comment Edited] (IGNITE-11096) Webagent: flag --disable-demo doesn't work

2019-02-17 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko edited comment on IGNITE-11096 at 2/18/19 7:01 AM:
-

Fixed launch of demo mode when agent in not connected to Web console.


was (Author: vsisko):
++Fixed launch of demo mode when agent in not connected to Web console.

> Webagent: flag --disable-demo doesn't work
> --
>
> Key: IGNITE-11096
> URL: https://issues.apache.org/jira/browse/IGNITE-11096
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.7
> Environment: After enabling this flag it's still possible to start 
> demo
>Reporter: Evgenii Zhuravlev
>Assignee: Vasiliy Sisko
>Priority: Major
> Fix For: 2.8
>
> Attachments: image-2019-02-13-13-55-51-248.png, screenshot-1.png
>
>




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


[jira] [Commented] (IGNITE-10414) IF NOT EXISTS in CREATE TABLE doesn't work

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-10414:
--

Patch looks good in general. However, Queries 1 hanged. Requires investigation.

> IF NOT EXISTS in CREATE TABLE doesn't work
> --
>
> Key: IGNITE-10414
> URL: https://issues.apache.org/jira/browse/IGNITE-10414
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4, 2.6, 2.7
>Reporter: Evgenii Zhuravlev
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Reproducer:
>  
> {code:java}
>Ignite ignite = Ignition.start();
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE 
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE 
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> {code}
> Error:
> {code:java}
> (err) DDL operation failureSchemaOperationException [code=3, msg=Table 
> already exists: CITY]
>   at 
> org.apache.ignite.internal.processors.query.QueryUtils.checkQueryEntityConflicts(QueryUtils.java:1214)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:351)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2677)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$0(GridQueryProcessor.java:2183)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2203)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2164)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2125)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:685)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
>   at 
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
> Exception in thread "main" javax.cache.CacheException: Table already exists: 
> CITY
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:697)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
>   at 
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException: Table already 
> exists: CITY
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:642)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:503)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2677)
>   at 
> 

[jira] [Updated] (IGNITE-11098) Web console: font cleanup

2019-02-17 Thread Alexey Kuznetsov (JIRA)


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

Alexey Kuznetsov updated IGNITE-11098:
--
Fix Version/s: 2.8

> Web console: font cleanup
> -
>
> Key: IGNITE-11098
> URL: https://issues.apache.org/jira/browse/IGNITE-11098
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.8
>
>  Time Spent: 2h 47m
>  Remaining Estimate: 0h
>
> Web console font should be set in a single place.
> Places to check:
> 1. SCSS variables passed into Bootstrap.
> 2. Component styles that explicitly use Roboto font (they should not).
> 3. Font preload meta tags.



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


[jira] [Assigned] (IGNITE-11096) Webagent: flag --disable-demo doesn't work

2019-02-17 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov reassigned IGNITE-11096:
---

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Webagent: flag --disable-demo doesn't work
> --
>
> Key: IGNITE-11096
> URL: https://issues.apache.org/jira/browse/IGNITE-11096
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.7
> Environment: After enabling this flag it's still possible to start 
> demo
>Reporter: Evgenii Zhuravlev
>Assignee: Vasiliy Sisko
>Priority: Major
> Fix For: 2.8
>
> Attachments: image-2019-02-13-13-55-51-248.png, screenshot-1.png
>
>




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


[jira] [Updated] (IGNITE-11096) Webagent: flag --disable-demo doesn't work

2019-02-17 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov updated IGNITE-11096:

Attachment: screenshot-1.png

> Webagent: flag --disable-demo doesn't work
> --
>
> Key: IGNITE-11096
> URL: https://issues.apache.org/jira/browse/IGNITE-11096
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.7
> Environment: After enabling this flag it's still possible to start 
> demo
>Reporter: Evgenii Zhuravlev
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.8
>
> Attachments: image-2019-02-13-13-55-51-248.png, screenshot-1.png
>
>




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


[jira] [Commented] (IGNITE-11096) Webagent: flag --disable-demo doesn't work

2019-02-17 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov commented on IGNITE-11096:
-

Test failed - I didn't start any agent but got the error message
 !screenshot-1.png! 

> Webagent: flag --disable-demo doesn't work
> --
>
> Key: IGNITE-11096
> URL: https://issues.apache.org/jira/browse/IGNITE-11096
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.7
> Environment: After enabling this flag it's still possible to start 
> demo
>Reporter: Evgenii Zhuravlev
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.8
>
> Attachments: image-2019-02-13-13-55-51-248.png, screenshot-1.png
>
>




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


[jira] [Assigned] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file

2019-02-17 Thread Alexey Kuznetsov (JIRA)


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

Alexey Kuznetsov reassigned IGNITE-10214:
-

Assignee: Vasiliy Sisko  (was: Alexey Kuznetsov)

# Please test that new logic of parsing driver metadata works with all major 
JDBC drivers.
# Please rework "_latestVersions" to use "_.reduce" function instead of "for()"
# Use "You may download JDBC driver from:" instead of "Download last available 
driver by link"
# Check "_numberComparator" usages, do we need it at all?
# Remove duplicated code that check version.

> Web console: dependency to open source JDBC driver is not generated in the 
> project's pom file
> -
>
> Key: IGNITE-10214
> URL: https://issues.apache.org/jira/browse/IGNITE-10214
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
> Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png
>
>
> Steps to reproduce:
> # import caches from for example MySql DB
> # check generated pom file



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


[jira] [Updated] (IGNITE-8368) Reimplement queries notebooks list table wth pc-items-table'

2019-02-17 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov updated IGNITE-8368:
---
Attachment: screenshot-3.png

> Reimplement queries notebooks list table wth pc-items-table'
> 
>
> Key: IGNITE-8368
> URL: https://issues.apache.org/jira/browse/IGNITE-8368
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Pavel Konstantinov
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>  Time Spent: 1.2h
>  Remaining Estimate: 0h
>
> Currently notebooks list table is implemented with pure ui-grid directive. 
> But now we have a component 'pc-items-table', which enfolds higher 
> abstractions. For better managability we should reimplement this table with 
> pc-items-table.



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


[jira] [Assigned] (IGNITE-8368) Reimplement queries notebooks list table wth pc-items-table'

2019-02-17 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov reassigned IGNITE-8368:
--

Assignee: Alexander Kalinin  (was: Pavel Konstantinov)

> Reimplement queries notebooks list table wth pc-items-table'
> 
>
> Key: IGNITE-8368
> URL: https://issues.apache.org/jira/browse/IGNITE-8368
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>  Time Spent: 1.2h
>  Remaining Estimate: 0h
>
> Currently notebooks list table is implemented with pure ui-grid directive. 
> But now we have a component 'pc-items-table', which enfolds higher 
> abstractions. For better managability we should reimplement this table with 
> pc-items-table.



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


[jira] [Commented] (IGNITE-8368) Reimplement queries notebooks list table wth pc-items-table'

2019-02-17 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov commented on IGNITE-8368:


We lost one line
 !screenshot-3.png! 

Please fix and assign to [~kuaw26] for merge

> Reimplement queries notebooks list table wth pc-items-table'
> 
>
> Key: IGNITE-8368
> URL: https://issues.apache.org/jira/browse/IGNITE-8368
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Pavel Konstantinov
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>  Time Spent: 1.2h
>  Remaining Estimate: 0h
>
> Currently notebooks list table is implemented with pure ui-grid directive. 
> But now we have a component 'pc-items-table', which enfolds higher 
> abstractions. For better managability we should reimplement this table with 
> pc-items-table.



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


[jira] [Updated] (IGNITE-8368) Reimplement queries notebooks list table wth pc-items-table'

2019-02-17 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov updated IGNITE-8368:
---
Attachment: screenshot-2.png

> Reimplement queries notebooks list table wth pc-items-table'
> 
>
> Key: IGNITE-8368
> URL: https://issues.apache.org/jira/browse/IGNITE-8368
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Pavel Konstantinov
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>  Time Spent: 1.2h
>  Remaining Estimate: 0h
>
> Currently notebooks list table is implemented with pure ui-grid directive. 
> But now we have a component 'pc-items-table', which enfolds higher 
> abstractions. For better managability we should reimplement this table with 
> pc-items-table.



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


[jira] [Updated] (IGNITE-8368) Reimplement queries notebooks list table wth pc-items-table'

2019-02-17 Thread Pavel Konstantinov (JIRA)


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

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

> Reimplement queries notebooks list table wth pc-items-table'
> 
>
> Key: IGNITE-8368
> URL: https://issues.apache.org/jira/browse/IGNITE-8368
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Pavel Konstantinov
>Priority: Minor
> Attachments: screenshot-1.png
>
>  Time Spent: 1.2h
>  Remaining Estimate: 0h
>
> Currently notebooks list table is implemented with pure ui-grid directive. 
> But now we have a component 'pc-items-table', which enfolds higher 
> abstractions. For better managability we should reimplement this table with 
> pc-items-table.



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


[jira] [Assigned] (IGNITE-11098) Web console: font cleanup

2019-02-17 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov reassigned IGNITE-11098:
---

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web console: font cleanup
> -
>
> Key: IGNITE-11098
> URL: https://issues.apache.org/jira/browse/IGNITE-11098
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>  Time Spent: 2h 47m
>  Remaining Estimate: 0h
>
> Web console font should be set in a single place.
> Places to check:
> 1. SCSS variables passed into Bootstrap.
> 2. Component styles that explicitly use Roboto font (they should not).
> 3. Font preload meta tags.



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


[jira] [Commented] (IGNITE-11098) Web console: font cleanup

2019-02-17 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov commented on IGNITE-11098:
-

Test results:
# demo mode - ok
# setting "--sans-serif-font" property - ok
# Roboto bold font should load only when bold text is displayed - ok

> Web console: font cleanup
> -
>
> Key: IGNITE-11098
> URL: https://issues.apache.org/jira/browse/IGNITE-11098
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
>Priority: Minor
>  Time Spent: 2h 47m
>  Remaining Estimate: 0h
>
> Web console font should be set in a single place.
> Places to check:
> 1. SCSS variables passed into Bootstrap.
> 2. Component styles that explicitly use Roboto font (they should not).
> 3. Font preload meta tags.



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


[jira] [Assigned] (IGNITE-11096) Webagent: flag --disable-demo doesn't work

2019-02-17 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko reassigned IGNITE-11096:
--

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Webagent: flag --disable-demo doesn't work
> --
>
> Key: IGNITE-11096
> URL: https://issues.apache.org/jira/browse/IGNITE-11096
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.7
> Environment: After enabling this flag it's still possible to start 
> demo
>Reporter: Evgenii Zhuravlev
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.8
>
> Attachments: image-2019-02-13-13-55-51-248.png
>
>




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


[jira] [Commented] (IGNITE-11096) Webagent: flag --disable-demo doesn't work

2019-02-17 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko commented on IGNITE-11096:


Fixed.

> Webagent: flag --disable-demo doesn't work
> --
>
> Key: IGNITE-11096
> URL: https://issues.apache.org/jira/browse/IGNITE-11096
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.7
> Environment: After enabling this flag it's still possible to start 
> demo
>Reporter: Evgenii Zhuravlev
>Assignee: Vasiliy Sisko
>Priority: Major
> Fix For: 2.8
>
> Attachments: image-2019-02-13-13-55-51-248.png
>
>




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


[jira] [Assigned] (IGNITE-11284) Web console: Actualize grid configuration: query entity and Pojo store

2019-02-17 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko reassigned IGNITE-11284:
--

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Web console: Actualize grid configuration: query entity and Pojo store
> --
>
> Key: IGNITE-11284
> URL: https://issues.apache.org/jira/browse/IGNITE-11284
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Major
>
> Result for class: org.apache.ignite.cache.QueryEntity
>    Missed
>      fieldsPrecision
>      notNullFields
>      fieldsScale
>      defaultFieldValues
> Result for class: org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory
>    Missed
>      types
> Result for class: org.apache.ignite.cache.QueryIndex
>    Missed
>      inlineSize



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


[jira] [Commented] (IGNITE-11284) Web console: Actualize grid configuration: query entity and Pojo store

2019-02-17 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko commented on IGNITE-11284:


Fixed generation of missed fields. Field types of CacheJdbcPojoStoreFactory 
class is already generated.

> Web console: Actualize grid configuration: query entity and Pojo store
> --
>
> Key: IGNITE-11284
> URL: https://issues.apache.org/jira/browse/IGNITE-11284
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>Priority: Major
>
> Result for class: org.apache.ignite.cache.QueryEntity
>    Missed
>      fieldsPrecision
>      notNullFields
>      fieldsScale
>      defaultFieldValues
> Result for class: org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory
>    Missed
>      types
> Result for class: org.apache.ignite.cache.QueryIndex
>    Missed
>      inlineSize



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


[jira] [Updated] (IGNITE-11012) [ML] Add model type validation during parsing json file

2019-02-17 Thread Yury Babak (JIRA)


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

Yury Babak updated IGNITE-11012:

Priority: Major  (was: Blocker)

> [ML] Add model type validation during parsing json file
> ---
>
> Key: IGNITE-11012
> URL: https://issues.apache.org/jira/browse/IGNITE-11012
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Affects Versions: 2.8
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After resolving ignite path, check special field in parquet file to validate 
> apropriate model loading.



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


[jira] [Updated] (IGNITE-11313) Cluster hangs on cache invoke with binary objects creation

2019-02-17 Thread Dmitriy Govorukhin (JIRA)


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

Dmitriy Govorukhin updated IGNITE-11313:

Fix Version/s: 2.8

> Cluster hangs on cache invoke with binary objects creation
> --
>
> Key: IGNITE-11313
> URL: https://issues.apache.org/jira/browse/IGNITE-11313
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Creating of binary objects in entry processors in parallel with continuous 
> queries may lead to deadlock:
> {code:java}
> [2019-02-11 18:52:50,129][WARN ][grid-timeout-worker-#39] >>> Possible 
> starvation in striped pool.
> Thread name: sys-stripe-13-#14
> Queue: []
> Deadlock: false
> Completed: 1
> Thread [name="sys-stripe-13-#14", id=33, state=WAITING, blockCnt=3, waitCnt=3]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at 
> o.a.i.i.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
> at 
> o.a.i.i.binary.BinaryContext.registerUserClassName(BinaryContext.java:1202)
> at 
> o.a.i.i.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:366)
> at 
> o.a.i.i.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:189)
> at 
> o.a.i.scenario.InvokeTask$MyEntryProcessor.process(InvokeTask.java:106)
> at 
> o.a.i.i.processors.cache.EntryProcessorResourceInjectorProxy.process(EntryProcessorResourceInjectorProxy.java:68)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:446)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1302)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:713)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1103)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:405)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:569)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:367)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:171)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:156)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:118)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:198)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:196)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at 
> o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at 
> o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at 
> o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at 
> o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at o.a.i.i.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>  



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


[jira] [Commented] (IGNITE-10898) Exchange coordinator failover breaks in some cases when node filter is used

2019-02-17 Thread Dmitriy Govorukhin (JIRA)


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

Dmitriy Govorukhin commented on IGNITE-10898:
-

Merged to master.

> Exchange coordinator failover breaks in some cases when node filter is used
> ---
>
> Key: IGNITE-10898
> URL: https://issues.apache.org/jira/browse/IGNITE-10898
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Attachments: NodeWithFilterRestartTest.java
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently if a node does not pass cache node filter, we do not store this 
> cache affinity on the node unless the node is coordinator. This, however, may 
> fail in the following scenario:
> 1) A node passing node filter joins cluster
> 2) During the join coordinator fails, new coordinator is selected for which 
> previous exchange is completed
> 3) Next coordinator attempts to fetch the affinity, and joining node resends 
> partitions single message, but there are two problems here. First, exchange 
> fast-reply does not wait for the new affinity initialization which results in 
> {{IllegalStateException}}. Second, such an attempt to fetch affinity may lead 
> either to deadlock or to incorrectly fetched affinity (basically, coordinator 
> must be in consensus with other nodes passing node filter)
> Test attached reproduces the issue.
> I suggest to always calculate and keep affinity on all nodes, even ones not 
> passing the filter. In this case, there will be no need to fetch and 
> recalculate affinity ({{initCoordinatorCaches}} will go away.



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


[jira] [Commented] (IGNITE-10898) Exchange coordinator failover breaks in some cases when node filter is used

2019-02-17 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-10898:


{panel:title=-- Run :: All: No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3094509buildTypeId=IgniteTests24Java8_RunAll]

> Exchange coordinator failover breaks in some cases when node filter is used
> ---
>
> Key: IGNITE-10898
> URL: https://issues.apache.org/jira/browse/IGNITE-10898
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Attachments: NodeWithFilterRestartTest.java
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently if a node does not pass cache node filter, we do not store this 
> cache affinity on the node unless the node is coordinator. This, however, may 
> fail in the following scenario:
> 1) A node passing node filter joins cluster
> 2) During the join coordinator fails, new coordinator is selected for which 
> previous exchange is completed
> 3) Next coordinator attempts to fetch the affinity, and joining node resends 
> partitions single message, but there are two problems here. First, exchange 
> fast-reply does not wait for the new affinity initialization which results in 
> {{IllegalStateException}}. Second, such an attempt to fetch affinity may lead 
> either to deadlock or to incorrectly fetched affinity (basically, coordinator 
> must be in consensus with other nodes passing node filter)
> Test attached reproduces the issue.
> I suggest to always calculate and keep affinity on all nodes, even ones not 
> passing the filter. In this case, there will be no need to fetch and 
> recalculate affinity ({{initCoordinatorCaches}} will go away.



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


[jira] [Created] (IGNITE-11340) SQL: Add OOME tests to separate suite

2019-02-17 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-11340:


 Summary: SQL: Add OOME tests to separate suite
 Key: IGNITE-11340
 URL: https://issues.apache.org/jira/browse/IGNITE-11340
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Taras Ledkov
 Fix For: 2.8


{{IgniteQueryOOMTestSuite}} was added as a part of IGNITE-9171. We need to add 
this suite to TC and make sure it is executed on regular basis.



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


[jira] [Assigned] (IGNITE-11341) SQL: Enable lazy mode by default

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov reassigned IGNITE-11341:


Assignee: (was: Taras Ledkov)

> SQL: Enable lazy mode by default
> 
>
> Key: IGNITE-11341
> URL: https://issues.apache.org/jira/browse/IGNITE-11341
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Priority: Critical
>
> We redesigned lazy mode, so that now it doesn't spawn new thread and has the 
> same performance as old "eager" mode (IGNITE-9171). However, we didn't enable 
> it by default because H2 1.4.197 contains several bugs causing query engine 
> slowdown in some cases when lazy mode is set. These issues are resolved in H2 
> master and will become available as a part of the next release (presumably 
> 1.4.198). 
> We need to make lazy mode enabled by default once new version is available 
> (IGNITE-10801).



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


[jira] [Updated] (IGNITE-11341) SQL: Enable lazy mode by default

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-11341:
-
Priority: Critical  (was: Major)

> SQL: Enable lazy mode by default
> 
>
> Key: IGNITE-11341
> URL: https://issues.apache.org/jira/browse/IGNITE-11341
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
>
> We redesigned lazy mode, so that now it doesn't spawn new thread and has the 
> same performance as old "eager" mode (IGNITE-9171). However, we didn't enable 
> it by default because H2 1.4.197 contains several bugs causing query engine 
> slowdown in some cases when lazy mode is set. These issues are resolved in H2 
> master and will become available as a part of the next release (presumably 
> 1.4.198). 
> We need to make lazy mode enabled by default once new version is available 
> (IGNITE-10801).



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


[jira] [Created] (IGNITE-11341) SQL: Enable lazy mode by default

2019-02-17 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-11341:


 Summary: SQL: Enable lazy mode by default
 Key: IGNITE-11341
 URL: https://issues.apache.org/jira/browse/IGNITE-11341
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Taras Ledkov


We redesigned lazy mode, so that now it doesn't spawn new thread and has the 
same performance as old "eager" mode (IGNITE-9171). However, we didn't enable 
it by default because H2 1.4.197 contains several bugs causing query engine 
slowdown in some cases when lazy mode is set. These issues are resolved in H2 
master and will become available as a part of the next release (presumably 
1.4.198). 

We need to make lazy mode enabled by default once new version is available 
(IGNITE-10801).



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


[jira] [Updated] (IGNITE-9171) Use lazy mode with results pre-fetch

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-9171:

Ignite Flags:   (was: Docs Required)

> Use lazy mode with results pre-fetch
> 
>
> Key: IGNITE-9171
> URL: https://issues.apache.org/jira/browse/IGNITE-9171
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Current implementation of the {{lazy}} mode always starts separate thread for 
> {{MapQueryLazyWorker}}. It  causes excessive overhead for requests that 
> produces small results set.
> We have to begin execute query at the {{QUERY_POOL}} thread pool and fetch 
> first page of the results. In case results set is bigger than one page 
> {{MapQueryLazyWorker}} is started and link with {{MapNodeResults}} to handle 
> next pages lazy.



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


[jira] [Commented] (IGNITE-9171) Use lazy mode with results pre-fetch

2019-02-17 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-9171:
-

Failures are unrelated. Merged.

> Use lazy mode with results pre-fetch
> 
>
> Key: IGNITE-9171
> URL: https://issues.apache.org/jira/browse/IGNITE-9171
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: sql-stability
> Fix For: 2.8
>
>
> Current implementation of the {{lazy}} mode always starts separate thread for 
> {{MapQueryLazyWorker}}. It  causes excessive overhead for requests that 
> produces small results set.
> We have to begin execute query at the {{QUERY_POOL}} thread pool and fetch 
> first page of the results. In case results set is bigger than one page 
> {{MapQueryLazyWorker}} is started and link with {{MapNodeResults}} to handle 
> next pages lazy.



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


[jira] [Commented] (IGNITE-9171) Use lazy mode with results pre-fetch

2019-02-17 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-9171:
---

{panel:title=-- Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=3106920]]

{color:#d04437}RDD{color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=3106907]]
* JavaEmbeddedIgniteRDDSelfTest.testReadDataFromIgnite (last started)

{color:#d04437}Cache 1{color} [[tests 
3|https://ci.ignite.apache.org/viewLog.html?buildId=3106946]]
* IgniteBinaryCacheTestSuite: 
DataStreamProcessorPersistenceBinarySelfTest.testTryFlush - 0,0% fails in last 
434 master runs.

{color:#d04437}Cache (Full API){color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=3106942]]
* IgniteCacheFullApiSelfTestSuite: 
GridCacheReplicatedAtomicFullApiSelfTest.testTtlNoTxOldEntry - 0,0% fails in 
last 591 master runs.

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3106998buildTypeId=IgniteTests24Java8_RunAll]

> Use lazy mode with results pre-fetch
> 
>
> Key: IGNITE-9171
> URL: https://issues.apache.org/jira/browse/IGNITE-9171
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: sql-stability
> Fix For: 2.8
>
>
> Current implementation of the {{lazy}} mode always starts separate thread for 
> {{MapQueryLazyWorker}}. It  causes excessive overhead for requests that 
> produces small results set.
> We have to begin execute query at the {{QUERY_POOL}} thread pool and fetch 
> first page of the results. In case results set is bigger than one page 
> {{MapQueryLazyWorker}} is started and link with {{MapNodeResults}} to handle 
> next pages lazy.



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


[jira] [Commented] (IGNITE-11243) Not working control.sh / control.bat in master NPE in output

2019-02-17 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-11243:


{panel:title=-- Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=3106863]]

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3103452buildTypeId=IgniteTests24Java8_RunAll]

> Not working control.sh / control.bat in master NPE in output
> 
>
> Key: IGNITE-11243
> URL: https://issues.apache.org/jira/browse/IGNITE-11243
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: ARomantsov
>Assignee: Sergey Kosarev
>Priority: Blocker
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> ./bin/control.sh  --host --port --baseline
> Cluster state: active
> Error: java.lang.NullPointerException
> control.bat --host  --port  --baseline
> Cluster state: active
> Error: java.lang.NullPointerException
> Press any key to continue . . .
> No info in cluster logs matched with call, look like problem in utility run



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