[jira] [Commented] (IGNITE-13310) Add tracing of SQL queries.

2020-09-17 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13310:
---

[~PetrovMikhail], the patch is OK with me.
My questions:
- the tracing is added for index operations on distributed joins, but not added 
for simple lookup (I mean {{H2TreeIndex#find}}). Why?
- please create the issue(s) to extends tracing information. I think the 
following info are very important for trace:
-- partition reservation (set of reserved partitions);
-- page / message size in bytes;
-- query parse info: cached query parse result or real parse.

> Add tracing of SQL queries.
> ---
>
> Key: IGNITE-13310
> URL: https://issues.apache.org/jira/browse/IGNITE-13310
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> It's needed to add tracing of SQL queries  based on the tracing framework 
> that was added as part of the 
> [IGNITE-13060|https://issues.apache.org/jira/browse/IGNITE-13060]
> Tracing of SQL queries must show phases of query execution, their duration, 
> errors and additional information describing each of the phases, such as the 
> number of rows requested from a remote node, SQL query mapping, and so on.
> For the first step of implementation Its proposed to distinguish the 
> following phases of queries execution:
> * The overall execution of SQL query.
> * Opening SQL query cursor.
> * Closing SQL query cursor.
> * Cancellation SQL query cursor. 
> * Parsing SQL query.
> * Processing SQL query execution request.   
> * Processing SQL next result page request.
> * Processing mapped node response with requested SQL result page.
> * Execution SQL query by H2.
> * Reading rows from cursor and preparing result page.
> * Processing SQL query fail response.
> * Processing DML query request.
> * Processing DML query response.
> * Processing query cancellation request.
> * Opening cursor iterator.
> * Opening cursor iterator.
> * Fetching SQL query result page.
> * Waiting for SQL query results page to be received.
> * Processing SQL index range request.
> * Processing SQL index range response.
> * Execution of SQL DML query.
> * Execution of SQL command query which either DDL SQL queries or Ignite 
> native SQL commands.
> * SQL query partitions reservation.
> * Update of cache as a result of the SQL DML query.
> * Processing of incoming batch.
> And keeps the following info: 
> * SQL query text 
> * SQL query schema
> * Number of rows that result page contains.
> * Number of rows that index range response contains.
> * Name of SQL table.
> * Number of cache entries to be updated as a result of DML query.



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


[jira] [Commented] (IGNITE-13186) Commands for control.sh to manage properties at the distributed metastore

2020-09-15 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13186:
---

[~korlov], [~northdragon], please review the patch.

> Commands for control.sh to manage properties at the distributed metastore
> -
>
> Key: IGNITE-13186
> URL: https://issues.apache.org/jira/browse/IGNITE-13186
> Project: Ignite
>  Issue Type: Improvement
>  Components: control.sh, sql
>Affects Versions: 2.8.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Now we store some properties (e.g. all properties of the 
> {{DistributedSqlConfiguration}}) at the distributed metastore.
> Now there is not way to change this properties for user.
> *Proposed fix:*
> adds command for {{CommandHandler}} to manage properties stored at the 
> distibuted metastore. 



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


[jira] [Commented] (IGNITE-13403) Update JDBC metadata to match actual capabilities

2020-09-14 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13403:
---

[~korlov], please review the patch.

> Update JDBC metadata to match actual capabilities
> -
>
> Key: IGNITE-13403
> URL: https://issues.apache.org/jira/browse/IGNITE-13403
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In our JDBC metadata some capabilities are reported not to be supported, 
> while in fact they are. E.g. I see
> {code}
> /** {@inheritDoc} */
> @Override public boolean supportsAlterTableWithAddColumn() throws 
> SQLException {
> return false;
> }
> /** {@inheritDoc} */
> @Override public boolean supportsAlterTableWithDropColumn() throws 
> SQLException {
> return false;
> }
> {code}
> while in fact `ALTER TABLE ADD/DROP COLUMN` are supported.
> Need to go through the list of capabilities and correct them.



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


[jira] [Commented] (IGNITE-13414) JDBC thin: compatibility is broken for versions 2.8-2.9

2020-09-11 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13414:
---

[~alex_pl] the patch is OK with me.
Please keep in mind improvement of the JDBC compatibility test: for appropriate 
pairs of versions please check:
- authentication;
- user attributes;
- manual disable features.
(may be on separate ticket)





> JDBC thin: compatibility is broken for versions 2.8-2.9
> ---
>
> Key: IGNITE-13414
> URL: https://issues.apache.org/jira/browse/IGNITE-13414
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Blocker
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> "User attributes" feature was added by IGNITE-12049, it was added to 2.9 
> version, but for VER_2_8_0 condition:
> {code:java}
>  if (ver.compareTo(VER_2_8_0) >= 0) {
> dataPageScanEnabled = nullableBooleanFromByte(reader.readByte());
> updateBatchSize = JdbcUtils.readNullableInteger(reader);
> userAttrs = reader.readMap();
> }
> {code}
> This breaks compatibility between 2.8 and 2.9 versions (both, backward and 
> forward)



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


[jira] [Comment Edited] (IGNITE-13409) System view for metastorage items

2020-09-09 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-13409 at 9/9/20, 10:01 AM:
-

[~nizhikov]
The patch looks good. But we have to restrict an access to this view because 
the metastorage may contain sensitive data.
e.g.: ignite users are stored at the metastorage by 
{{IgniteAuthenticationProcessor}}


was (Author: tledkov-gridgain):
[~nizhikov]
The patch is OK with me.

> System view for metastorage items
> -
>
> Key: IGNITE-13409
> URL: https://issues.apache.org/jira/browse/IGNITE-13409
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-35
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We need to provide a System view to show metastorage and distributed 
> metastorage properties.



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


[jira] [Comment Edited] (IGNITE-13408) System view for binary metadata

2020-09-09 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-13408 at 9/9/20, 10:01 AM:
-

[~nizhikov]
The patch is OK with me.


was (Author: tledkov-gridgain):
[~nizhikov]
The patch looks good. But we have to restrict an access to this view because 
the metastorage may contain sensitive data.
e.g.: ignite users are stored at the metastorage by 
{{IgniteAuthenticationProcessor}}

> System view for binary metadata
> ---
>
> Key: IGNITE-13408
> URL: https://issues.apache.org/jira/browse/IGNITE-13408
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-35
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently, list of binary metadata available via experimental {{control.sh}} 
> command.
> We need to provide a corresponding System view for this information.



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


[jira] [Commented] (IGNITE-13408) System view for binary metadata

2020-09-09 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13408:
---

[~nizhikov]
The patch looks good. But we have to restrict an access to this view because 
the metastorage may contain sensitive data.
e.g.: ignite users are stored at the metastorage by 
{{IgniteAuthenticationProcessor}}

> System view for binary metadata
> ---
>
> Key: IGNITE-13408
> URL: https://issues.apache.org/jira/browse/IGNITE-13408
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-35
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently, list of binary metadata available via experimental {{control.sh}} 
> command.
> We need to provide a corresponding System view for this information.



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


[jira] [Commented] (IGNITE-13409) System view for metastorage items

2020-09-09 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13409:
---

[~nizhikov]
The patch is OK with me.

> System view for metastorage items
> -
>
> Key: IGNITE-13409
> URL: https://issues.apache.org/jira/browse/IGNITE-13409
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-35
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We need to provide a System view to show metastorage and distributed 
> metastorage properties.



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


[jira] [Updated] (IGNITE-13403) Update JDBC metadata to match actual capabilities

2020-09-04 Thread Taras Ledkov (Jira)


[jira] [Updated] (IGNITE-13403) Update JDBC metadata to match actual capabilities

2020-09-04 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-13403:
--
Ignite Flags: Release Notes Required  (was: Docs Required,Release Notes 
Required)

> Update JDBC metadata to match actual capabilities
> -
>
> Key: IGNITE-13403
> URL: https://issues.apache.org/jira/browse/IGNITE-13403
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In our JDBC metadata some capabilities are reported not to be supported, 
> while in fact they are. E.g. I see
> {code}
> /** {@inheritDoc} */
> @Override public boolean supportsAlterTableWithAddColumn() throws 
> SQLException {
> return false;
> }
> /** {@inheritDoc} */
> @Override public boolean supportsAlterTableWithDropColumn() throws 
> SQLException {
> return false;
> }
> {code}
> while in fact `ALTER TABLE ADD/DROP COLUMN` are supported.
> Need to go through the list of capabilities and correct them.



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


[jira] [Updated] (IGNITE-13186) Commands for control.sh to manage properties at the distributed metastore

2020-09-04 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-13186:
--
Fix Version/s: 2.10

> Commands for control.sh to manage properties at the distributed metastore
> -
>
> Key: IGNITE-13186
> URL: https://issues.apache.org/jira/browse/IGNITE-13186
> Project: Ignite
>  Issue Type: Improvement
>  Components: control.sh, sql
>Affects Versions: 2.8.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Now we store some properties (e.g. all properties of the 
> {{DistributedSqlConfiguration}}) at the distributed metastore.
> Now there is not way to change this properties for user.
> *Proposed fix:*
> adds command for {{CommandHandler}} to manage properties stored at the 
> distibuted metastore. 



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


[jira] [Created] (IGNITE-13403) Update JDBC metadata to match actual capabilities

2020-09-04 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-13403:
-

 Summary: Update JDBC metadata to match actual capabilities
 Key: IGNITE-13403
 URL: https://issues.apache.org/jira/browse/IGNITE-13403
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.8.1
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.10


In our JDBC metadata some capabilities are reported not to be supported, while 
in fact they are. E.g. I see
{code}
/** {@inheritDoc} */
@Override public boolean supportsAlterTableWithAddColumn() throws 
SQLException {
return false;
}

/** {@inheritDoc} */
@Override public boolean supportsAlterTableWithDropColumn() throws 
SQLException {
return false;
}
{code}

while in fact `ALTER TABLE ADD/DROP COLUMN` are supported.
Need to go through the list of capabilities and correct them.



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


[jira] [Commented] (IGNITE-13376) Primary index can be created with fields sequence differ from declared.

2020-08-25 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13376:
---

[~zstan], the patch is OK with me. Please fix typos and codestyle:
- BasicIndexTest#testCorrectPkFldsSequence - fix name according with 
[guideline|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Abbreviations];
- GridQueryTypeDescriptor#primaryKeyFields(): typo at the javadoc;
- IgniteDiscoverySpi#SRV_NODES - [javadoc 
style|org.apache.ignite.internal.managers.discovery.IgniteDiscoverySpi#SRV_NODES].


> Primary index can be created with fields sequence differ from declared.
> ---
>
> Key: IGNITE-13376
> URL: https://issues.apache.org/jira/browse/IGNITE-13376
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.7.6, 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Steps to reproduce: 
> Execute the following DDL (create table + create index):
> {noformat}
> CREATE TABLE IF NOT EXISTS Workspace (
> id UUID NOT NULL,
> accountId UUID NOT NULL,
> jsonModel VARCHAR,
> PRIMARY KEY (accountId, id)
>   ) WITH 
> "template=partitioned,atomicity=transactional,key_type=org.gridgain.gmc.dto.workspace.WorkspaceKey,value_type=workspace.Workspace,cache_name=WorkspaceCache";
> CREATE INDEX IF NOT EXISTS workspace_id_account_id_idx ON Workspace (id, 
> accountId);
> {noformat}
> On node start got the following warning:
> {noformat}
> Index with the given set or subset of columns already exists (consider 
> dropping either new or existing index) [cacheName=WorkspaceCache, 
> schemaName=PUBLIC, tableName=WORKSPACE, 
> newIndexName=WORKSPACE_ID_ACCOUNT_ID_IDX, existingIndexName=_key_PK, 
> existingIndexColumns=[ID, ACCOUNTID]]
> {noformat}
> But PK and index have different order!



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


[jira] [Commented] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.

2020-08-25 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13280:
---

[~zstan] the patch is OK with me.

> Improper index usage, fields enumeration not used with pk index creation.
> -
>
> Key: IGNITE-13280
> URL: https://issues.apache.org/jira/browse/IGNITE-13280
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For example:
> {code:java}
> CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR, 
> ADDRESS VARCHAR, LANG VARCHAR,  CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME, 
> LAST_NAME));
> CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
> {code}
> and further explain:
> {code:java}
> SELECT
> "__Z0"."FIRST_NAME" AS "__C0_0",
> "__Z0"."LAST_NAME" AS "__C0_1",
> "__Z0"."ADDRESS" AS "__C0_2",
> "__Z0"."LANG" AS "__C0_3"
> FROM "PUBLIC"."TEST_TABLE" "__Z0"
> /* PUBLIC.IDX2: ADDRESS > 0 */
> WHERE "__Z0"."ADDRESS" > 0
> {code}
> this is erroneous  to use "idx2" here, because first index field LANG not 
> equals to predicate ADDRESS.
> Looks like this bug brings this ticket [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-10217



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


[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5

2020-08-24 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13270:
---

[~zstan]
About reproducer with invalid results:
The root cause is using the index on VARCHAR column {{idx_B_COL2}} and lookup 
the integer value at this index.
We have a problem with lookup value with type conversion at the index.
The reproducer may be shorter:
{code}
sql("CREATE TABLE TEST (ID INTEGER PRIMARY KEY, VAL VARCHAR(100), VAL1 
int)");
sql("CREATE INDEX IDX_VAL ON TEST (VAL)");

   // Fail
res = sql("SELECT * FROM TEST WHERE VAL=?", i).getAll();

   // OK
res = sql("SELECT * FROM TEST WHERE VAL=?", 
Integer.toString(i)).getAll();
{code}

> Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
> --
>
> Key: IGNITE-13270
> URL: https://issues.apache.org/jira/browse/IGNITE-13270
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8, 2.8.1
>Reporter: Tanmay Ambre
>Priority: Major
> Attachments: IDX13270.java, IgniteSqlDistributedJoinSelfTest.java
>
>
> After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing 
> massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on 
> each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes 
> are above 80%. On 2.7.5 the same query was performing very nicely. 
> The query is a join with 3 tables having same affinity key. however, we dont 
> know the affinity key when we are querying and there this results in a merge 
> scan. 
> Query:
> select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C
> where
> A.A_ID = B.A_ID AND
> B.B_ID = C.B_ID AND
> A.AFFINITYKEY = B.AFFINITYKEY AND
> B.AFFINITYKEY = C.AFFINITYKEY AND
> B.B_ID = ? AND
> C.C_ID = ?
>  
> Performance:
> 2.7.5 ~ 2 to 5 ms
> 2.8.0 ~ 6 to 12 seconds
> 2.8.1 ~ within 3 seconds
>  
> Volume (we have a EDA based system where messages come in burst. One burst 
> has approx. 150K events - each event correspond to one query). 
>  
> throughput of our java based processor (that fires this query):
> 2.7.5 ~ 750 transactions per second
> 2.8.0 ~ 3 transactions per second
> 2.8.1 ~ 6 transactions per second
>  
> CPU burn
> 2.7.5 ~ 10 to 15% on each node
> 2.8.0 ~ 100% on 2 nodes other nodes are idling
> 2.8.1 ~ 80 to 90% on each node
>  



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


[jira] [Commented] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.

2020-08-18 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13280:
---

[~zstan] test to reproduce (for class {{BasicIndexTest}}):
{code}
/**
 *  Checks index usage for full coverage.
 */
@Test
public void testConditionsWithoutIndexes2() throws Exception {
inlineSize = 10;

srvLog = new ListeningTestLogger(false, log);

IgniteEx ig0 = startGrid(0);

GridQueryProcessor qryProc = ig0.context().query();

populateTable(qryProc, TEST_TBL_NAME, 1, "ID", "VAL0", "VAL1");

String sqlIdx = String.format("create index \"idx1\" on %s(VAL0, 
VAL1)", TEST_TBL_NAME);

qryProc.querySqlFields(new SqlFieldsQuery(sqlIdx), true).getAll();

assertFalse(checkIdxUsed(qryProc, null, TEST_TBL_NAME, "VAL1"));

assertTrue(checkIdxUsed(qryProc, "idx1", TEST_TBL_NAME, "VAL0"));
}


{code}

> Improper index usage, fields enumeration not used with pk index creation.
> -
>
> Key: IGNITE-13280
> URL: https://issues.apache.org/jira/browse/IGNITE-13280
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For example:
> {code:java}
> CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR, 
> ADDRESS VARCHAR, LANG VARCHAR,  CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME, 
> LAST_NAME));
> CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
> {code}
> and further explain:
> {code:java}
> SELECT
> "__Z0"."FIRST_NAME" AS "__C0_0",
> "__Z0"."LAST_NAME" AS "__C0_1",
> "__Z0"."ADDRESS" AS "__C0_2",
> "__Z0"."LANG" AS "__C0_3"
> FROM "PUBLIC"."TEST_TABLE" "__Z0"
> /* PUBLIC.IDX2: ADDRESS > 0 */
> WHERE "__Z0"."ADDRESS" > 0
> {code}
> this is erroneous  to use "idx2" here, because first index field LANG not 
> equals to predicate ADDRESS.
> Looks like this bug brings this ticket [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-10217



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


[jira] [Commented] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.

2020-08-18 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13280:
---

[~zstan], I see no reason not to use one cost function for all indexes. This 
can save you from making mistakes when fixing the cost function later. If you 
know a reason for using different cost functions please specify them.

> Improper index usage, fields enumeration not used with pk index creation.
> -
>
> Key: IGNITE-13280
> URL: https://issues.apache.org/jira/browse/IGNITE-13280
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For example:
> {code:java}
> CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR, 
> ADDRESS VARCHAR, LANG VARCHAR,  CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME, 
> LAST_NAME));
> CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
> {code}
> and further explain:
> {code:java}
> SELECT
> "__Z0"."FIRST_NAME" AS "__C0_0",
> "__Z0"."LAST_NAME" AS "__C0_1",
> "__Z0"."ADDRESS" AS "__C0_2",
> "__Z0"."LANG" AS "__C0_3"
> FROM "PUBLIC"."TEST_TABLE" "__Z0"
> /* PUBLIC.IDX2: ADDRESS > 0 */
> WHERE "__Z0"."ADDRESS" > 0
> {code}
> this is erroneous  to use "idx2" here, because first index field LANG not 
> equals to predicate ADDRESS.
> Looks like this bug brings this ticket [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-10217



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


[jira] [Assigned] (IGNITE-13198) Calcite integration. Rework error / cancel logic at execution

2020-08-14 Thread Taras Ledkov (Jira)


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

Taras Ledkov reassigned IGNITE-13198:
-

Assignee: Igor Seliverstov  (was: Taras Ledkov)

> Calcite integration. Rework error / cancel logic at execution
> -
>
> Key: IGNITE-13198
> URL: https://issues.apache.org/jira/browse/IGNITE-13198
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Igor Seliverstov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Change error & cancel logic on query execution.
> *Error*
> - propagated from source to downstream nodes.
> - Always propagated to the RootNode;
> - RootNode receive an error and cancel all execution tree.
> *Cancel*
> - propagated from downstream to source;
> - any node may cancel its execution sub-tree;
> - (technical details) to prevent race on Inbox creation Outbox resend Cancel 
> message to Inbox.



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


[jira] [Created] (IGNITE-13339) Sql query fails with NullPointerException caused by calling CAST in order by clause

2020-08-07 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-13339:
-

 Summary: Sql query fails with NullPointerException caused by 
calling CAST in order by clause
 Key: IGNITE-13339
 URL: https://issues.apache.org/jira/browse/IGNITE-13339
 Project: Ignite
  Issue Type: Test
  Components: sql
Affects Versions: 2.8.1
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


Sql statements to reproduce:

CREATE TABLE Person(ID INTEGER PRIMARY KEY, NAME VARCHAR(100));
INSERT INTO Person(ID, NAME) VALUES (1, 'Ed'), (2, 'Ann'), (3, 'Emma');
select name,id from Person order by CAST(id as long)

Result:

{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: null
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2572)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2505)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2463)
at 
org.apache.ignite.internal.visor.query.VisorQueryUtils.lambda$scheduleQueryStart$0(VisorQueryUtils.java:409)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7157)
at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:826)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: null
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3050)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2531)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2569)
... 9 more
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlFunction.getSQL(GridSqlFunction.java:124)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuery.getSortLimitSQL(GridSqlQuery.java:171)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlSelect.getSQL(GridSqlSelect.java:182)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQuery(GridSqlQuerySplitter.java:371)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split0(GridSqlQuerySplitter.java:280)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:212)
at 
org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:501)
at 
org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:173)
at 
org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:132)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1115)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2515)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2511)
at 
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:35)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3027)
... 11 more
{code}




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


[jira] [Commented] (IGNITE-13183) Query timeout redesign

2020-08-07 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13183:
---

[~korlov], [~amashenkov] please review the patch.

> Query timeout redesign
> --
>
> Key: IGNITE-13183
> URL: https://issues.apache.org/jira/browse/IGNITE-13183
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.8.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> *Motivation:*
> Now the query timeout is set up for each node separately by the node 
> configuration. This property isn't propagated for the all nodes of cluster. 
> Also user cannot change / disable query timeout without restart all nodes of 
> the cluster.
> *Proposal fix:*
> - Adds the default query timeout property to the 
> {{DistributedSqlConfiguration}}. Use distributed metastore to store and 
> manage the property.
> - Deprecates the {{SqlConfiguration#defaultQueryTimeout}} property and use it 
> to set up initial value of new property 
> {{DistributedSqlConfiguration#defaultQueryTimeout}}
> - Adds info about explicit query timeout to {{GridH2QueryRequest}} (boolean 
> flag {{explicitTimeout=false}} by default). This is necessary so that the 
> default timeout may be used for queries from old nodes.
> - When query timeout is set to zero by old node ({{explicitTimeout=false}}) 
> we assume this is the default value and use default timeout for this queries.



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


[jira] [Resolved] (IGNITE-13243) Add tests for commands to manage metadata

2020-07-10 Thread Taras Ledkov (Jira)


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

Taras Ledkov resolved IGNITE-13243.
---
Resolution: Invalid

> Add tests for commands to manage metadata
> -
>
> Key: IGNITE-13243
> URL: https://issues.apache.org/jira/browse/IGNITE-13243
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>




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


[jira] [Updated] (IGNITE-13243) Add tests for commands to manage metadata

2020-07-10 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-13243:
--
Description: (was: Adds tests for commands to manage metadata (see 
GG-29247))

> Add tests for commands to manage metadata
> -
>
> Key: IGNITE-13243
> URL: https://issues.apache.org/jira/browse/IGNITE-13243
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>




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


[jira] [Created] (IGNITE-13243) Add tests for commands to manage metadata

2020-07-10 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-13243:
-

 Summary: Add tests for commands to manage metadata
 Key: IGNITE-13243
 URL: https://issues.apache.org/jira/browse/IGNITE-13243
 Project: Ignite
  Issue Type: Test
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov


Adds tests for commands to manage metadata (see GG-29247)



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


[jira] [Commented] (IGNITE-9379) Ignite node hangs after OOM in a thread from thin client thread pool

2020-07-09 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-9379:
--

[~alex_pl], the patch is OK with me.
But OOM is really bad case for application. We cannot be sure where OOM is 
thrown: client thread / discovery thread etc.
So, I cannot obtain stable behavior of the grid on real OOM test case, e.g. 
setup small heap size and load data set more than heap size. You could try to 
check it for your patch.

> Ignite node hangs after OOM in a thread from thin client thread pool
> 
>
> Key: IGNITE-9379
> URL: https://issues.apache.org/jira/browse/IGNITE-9379
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> OOM exception handler isn't set up for thin client thread pool.
> The issue is described in details at the [dev 
> list|http://apache-ignite-evelopers.2346864.n4.nabble.com/Binary-Client-Protocol-client-hangs-in-case-of-OOM-on-server-td34224.html].



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


[jira] [Commented] (IGNITE-13200) SQL create index on invalid data type

2020-07-08 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13200:
---

[~korlov], [~ibessonov], please review the patch.

> SQL create index on invalid data type
> -
>
> Key: IGNITE-13200
> URL: https://issues.apache.org/jira/browse/IGNITE-13200
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>
> *Reproduce*
> - Create cache with value class
> {code}
> private static class Value {
> @QuerySqlField
> int val_int;
> java.util.Date val_date;
> }
> {code}
> - alter table with command
> {{ALTER TABLE TEST ADD COLUMN (VAL_DATE DATE)}}
> - try to create index with command
> {{CREATE INDEX TEST_VAL_DATE_IDX ON TEST(VAL_DATE)}}
> {{CorruptedTreeException}} is thrown, the node is stopped.
> {code}
> class org.apache.ignite.IgniteCheckedException: Runtime failure on row: 
> Row@6a2853cd[ key: 0, val: 
> org.apache.ignite.internal.processors.query.CreateIndexOnInvalidDataTypeTest$Value
>  [idHash=1693430008, hash=1583713321, val_int=0, val_date=Thu Jan 01 03:00:00 
> MSK 1970] ][ 0,  java.util.Date cannot be cast to java.sql.Date> ]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2438)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2388)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:434)
>   at 
> org.apache.ignite.internal.processors.query.h2.IndexBuildClosure.apply(IndexBuildClosure.java:52)
>   at 
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCachePartitionWorker$SchemaIndexCacheVisitorClosureWrapper.apply(SchemaIndexCachePartitionWorker.java:298)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:4494)
>   at 
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCachePartitionWorker.processKey(SchemaIndexCachePartitionWorker.java:231)
>   at 
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCachePartitionWorker.processPartition(SchemaIndexCachePartitionWorker.java:188)
>   at 
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCachePartitionWorker.body(SchemaIndexCachePartitionWorker.java:127)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
> wrap object into H2 Value. java.util.Date cannot be cast to java.sql.Date
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.H2CacheRow.wrap(H2CacheRow.java:177)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.H2CacheRow.getValue0(H2CacheRow.java:109)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.H2CacheRow.getValue(H2CacheRow.java:91)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.io.AbstractH2ExtrasLeafIO.storeByOffset(AbstractH2ExtrasLeafIO.java:115)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.io.AbstractH2ExtrasLeafIO.storeByOffset(AbstractH2ExtrasLeafIO.java:37)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.store(BPlusIO.java:185)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.insert(BPlusIO.java:272)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insertSimple(BPlusTree.java:3685)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insert(BPlusTree.java:3667)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$1900(BPlusTree.java:3539)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:452)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:433)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5889)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5875)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:360)
>   at 

[jira] [Updated] (IGNITE-13200) SQL create index on invalid data type

2020-07-03 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-13200:
--
Description: 
*Reproduce*
- Create cache with value class
{code}
private static class Value {
@QuerySqlField
int val_int;
java.util.Date val_date;
}
{code}
- alter table with command
{{ALTER TABLE TEST ADD COLUMN (VAL_DATE DATE)}}
- try to create index with command
{{CREATE INDEX TEST_VAL_DATE_IDX ON TEST(VAL_DATE)}}

{{CorruptedTreeException}} is thrown, the node is stopped.

{code}
class org.apache.ignite.IgniteCheckedException: Runtime failure on row: 
Row@6a2853cd[ key: 0, val: 
org.apache.ignite.internal.processors.query.CreateIndexOnInvalidDataTypeTest$Value
 [idHash=1693430008, hash=1583713321, val_int=0, val_date=Thu Jan 01 03:00:00 
MSK 1970] ][ 0,  ]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2438)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2388)
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:434)
at 
org.apache.ignite.internal.processors.query.h2.IndexBuildClosure.apply(IndexBuildClosure.java:52)
at 
org.apache.ignite.internal.processors.query.schema.SchemaIndexCachePartitionWorker$SchemaIndexCacheVisitorClosureWrapper.apply(SchemaIndexCachePartitionWorker.java:298)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:4494)
at 
org.apache.ignite.internal.processors.query.schema.SchemaIndexCachePartitionWorker.processKey(SchemaIndexCachePartitionWorker.java:231)
at 
org.apache.ignite.internal.processors.query.schema.SchemaIndexCachePartitionWorker.processPartition(SchemaIndexCachePartitionWorker.java:188)
at 
org.apache.ignite.internal.processors.query.schema.SchemaIndexCachePartitionWorker.body(SchemaIndexCachePartitionWorker.java:127)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class 
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to wrap 
object into H2 Value. java.util.Date cannot be cast to java.sql.Date
at 
org.apache.ignite.internal.processors.query.h2.opt.H2CacheRow.wrap(H2CacheRow.java:177)
at 
org.apache.ignite.internal.processors.query.h2.opt.H2CacheRow.getValue0(H2CacheRow.java:109)
at 
org.apache.ignite.internal.processors.query.h2.opt.H2CacheRow.getValue(H2CacheRow.java:91)
at 
org.apache.ignite.internal.processors.query.h2.database.io.AbstractH2ExtrasLeafIO.storeByOffset(AbstractH2ExtrasLeafIO.java:115)
at 
org.apache.ignite.internal.processors.query.h2.database.io.AbstractH2ExtrasLeafIO.storeByOffset(AbstractH2ExtrasLeafIO.java:37)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.store(BPlusIO.java:185)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.insert(BPlusIO.java:272)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insertSimple(BPlusTree.java:3685)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insert(BPlusTree.java:3667)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$1900(BPlusTree.java:3539)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:452)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:433)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5889)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5875)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:360)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:297)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11300(BPlusTree.java:99)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryInsert(BPlusTree.java:3859)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$7100(BPlusTree.java:3539)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2803)
at 

[jira] [Created] (IGNITE-13200) SQL create index on invalid data type

2020-07-01 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-13200:
-

 Summary: SQL create index on invalid data type
 Key: IGNITE-13200
 URL: https://issues.apache.org/jira/browse/IGNITE-13200
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.8.1
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


*Reproduce*
- Create cache with value class
{code}
private static class Value {
@QuerySqlField
int val_int;
java.util.Date val_date;
}
{code}
- alter table with command
{{ALTER TABLE TEST ADD COLUMN (VAL_DATE DATE)}}
- try to create index with command
{{CREATE INDEX TEST_VAL_DATE_IDX ON TEST(VAL_DATE)}}

{{CorruptedTreeException}} is thrown, the node is stopped.



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


[jira] [Updated] (IGNITE-13198) Calcite integration. Rework error / cancel logic at execution

2020-07-01 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-13198:
--
Summary: Calcite integration. Rework error / cancel logic at execution  
(was: Calcite integration. Rework error / cancel logic on execution)

> Calcite integration. Rework error / cancel logic at execution
> -
>
> Key: IGNITE-13198
> URL: https://issues.apache.org/jira/browse/IGNITE-13198
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> Change error & cancel logic on query execution.
> *Error*
> - propagated from source to downstream nodes.
> - Always propagated to the RootNode;
> - RootNode receive an error and cancel all execution tree.
> *Cancel*
> - propagated from downstream to source;
> - any node may cancel its execution sub-tree;
> - (technical details) to prevent race on Inbox creation Outbox resend Cancel 
> message to Inbox.



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


[jira] [Updated] (IGNITE-13198) Calcite integration. Rework error / cancel logic on execution

2020-07-01 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-13198:
--
Summary: Calcite integration. Rework error / cancel logic on execution  
(was: Calcite integration. Rework error / cancel login on execution)

> Calcite integration. Rework error / cancel logic on execution
> -
>
> Key: IGNITE-13198
> URL: https://issues.apache.org/jira/browse/IGNITE-13198
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> Change error & cancel logic on query execution.
> *Error*
> - propagated from source to downstream nodes.
> - Always propagated to the RootNode;
> - RootNode receive an error and cancel all execution tree.
> *Cancel*
> - propagated from downstream to source;
> - any node may cancel its execution sub-tree;
> - (technical details) to prevent race on Inbox creation Outbox resend Cancel 
> message to Inbox.



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


[jira] [Updated] (IGNITE-13198) Calcite integration. Rework error / cancel login on execution

2020-07-01 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-13198:
--
Summary: Calcite integration. Rework error / cancel login on execution  
(was: Calcite integration. Rework error / cancle login on execution)

> Calcite integration. Rework error / cancel login on execution
> -
>
> Key: IGNITE-13198
> URL: https://issues.apache.org/jira/browse/IGNITE-13198
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> Change error & cancel logic on query execution.
> *Error*
> - propagated from source to downstream nodes.
> - Always propagated to the RootNode;
> - RootNode receive an error and cancel all execution tree.
> *Cancel*
> - propagated from downstream to source;
> - any node may cancel its execution sub-tree;
> - (technical details) to prevent race on Inbox creation Outbox resend Cancel 
> message to Inbox.



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


[jira] [Created] (IGNITE-13198) Calcite integration. Rework error / cancle login on execution

2020-07-01 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-13198:
-

 Summary: Calcite integration. Rework error / cancle login on 
execution
 Key: IGNITE-13198
 URL: https://issues.apache.org/jira/browse/IGNITE-13198
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov


Change error & cancel logic on query execution.
*Error*
- propagated from source to downstream nodes.
- Always propagated to the RootNode;
- RootNode receive an error and cancel all execution tree.

*Cancel*
- propagated from downstream to source;
- any node may cancel its execution sub-tree;
- (technical details) to prevent race on Inbox creation Outbox resend Cancel 
message to Inbox.





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


[jira] [Commented] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13194:
---

[~vladsz83], merged to 
[master|https://github.com/apache/ignite/commit/0e385f8883a98c0a9a9e03b715c10363198c8999]

> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.



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


[jira] [Comment Edited] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-13194 at 6/30/20, 10:17 AM:
--

[~vladsz83], thanks a lot for your patch. I've missed this test.
The patch is OK with me. May be the last *typeId* should be placed according 
with previous parameters (with String.format)


was (Author: tledkov-gridgain):
[~vladsz83], thanks a lot for your patch. I've missed this test.
The patch is OK with me. May me the last *typeId* should be placed according 
with previous parameters (with String.format)

> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.



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


[jira] [Commented] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()

2020-06-30 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13194:
---

[~vladsz83], thanks a lot for your patch. I've missed this test.
The patch is OK with me. May me the last *typeId* should be placed according 
with previous parameters (with String.format)

> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test. 
> Became incorrect in IGNITE-13154.



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


[jira] [Created] (IGNITE-13186) Commands for control.sh to manage properties at the distributed metastore

2020-06-25 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-13186:
-

 Summary: Commands for control.sh to manage properties at the 
distributed metastore
 Key: IGNITE-13186
 URL: https://issues.apache.org/jira/browse/IGNITE-13186
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.8.1
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


Now we store some properties (e.g. all properties of the 
{{DistributedSqlConfiguration}}) at the distributed metastore.

Now there is not way to change this properties for user.

*Proposed fix:*
adds command for {{CommandHandler}} to manage properties stored at the 
distibuted metastore. 



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


[jira] [Created] (IGNITE-13183) Query timeout redesign

2020-06-25 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-13183:
-

 Summary: Query timeout redesign
 Key: IGNITE-13183
 URL: https://issues.apache.org/jira/browse/IGNITE-13183
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.8.1
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


*Motivation:*
Now the query timeout is set up for each node separately by the node 
configuration. This property isn't propagated for the all nodes of cluster. 
Also user cannot change / disable query timeout without restart all nodes of 
the cluster.

*Proposal fix:*
- Adds the default query timeout property to the 
{{DistributedSqlConfiguration}}. Use distributed metastore to store and manage 
the property.
- Deprecates the {{SqlConfiguration#defaultQueryTimeout}} property and use it 
to set up initial value of new property 
{{DistributedSqlConfiguration#defaultQueryTimeout}}
- Adds info about explicit query timeout to {{GridH2QueryRequest}} (boolean 
flag {{explicitTimeout=false}} by default). This is necessary so that the 
default timeout may be used for queries from old nodes.
- When query timeout is set to zero by old node ({{explicitTimeout=false}}) we 
assume this is the default value and use default timeout for this queries.




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


[jira] [Created] (IGNITE-13179) Calcite integration. Fix traits at the IgniteLimit

2020-06-23 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-13179:
-

 Summary: Calcite integration. Fix traits at the IgniteLimit
 Key: IGNITE-13179
 URL: https://issues.apache.org/jira/browse/IGNITE-13179
 Project: Ignite
  Issue Type: Improvement
Reporter: Taras Ledkov
Assignee: Taras Ledkov


Current implementation of {{IgniteLimit}} doesn't  support distribution trait 
propagation.
Limit must require singleton distribution.

Now we cannot reproduce invalid behavior (see IGNITE-12819) and IgniteLimit 
isn't placed under the Exchange node.

Also Limit must be propogated (copied) under Exchange to reduce unnecessary 
fetches.



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


[jira] [Commented] (IGNITE-13154) Introduce the ability for a user to manage binary types

2020-06-23 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13154:
---

[~korlov], [~amashenkov], all review comments are fixed. Please review the 
patch.

> Introduce the ability for a user to manage binary types
> ---
>
> Key: IGNITE-13154
> URL: https://issues.apache.org/jira/browse/IGNITE-13154
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 5h 10m
>  Remaining Estimate: 0h
>
> We need a way to change schema (including unsupported changes, such as column 
> type change) without cluster restart. This is for the case when all data 
> associated with the binary type has been removed, so removing the old schema 
> is safe.
> Now users must stop the cluster and remove the folder with binary metadata 
> manually.
> The proposed way is to introduce internal API to manage binary types and 
> public command line interface (via control.sh). That way one can remove a 
> cache from the cluster, then unregister corresponding binary types, then 
> launch a new version of an application that would register the new schema and 
> reload the data.
> *The current implementation has restrictions:*
> - all cluster nodes must support remove type feature.
> - the cluster must not contains data with type to remove.
> - operation of the update type must not be launched on the cluster for the 
> type to remove (operation examples: put into cache, 
> BinaryObjectBuilder#build).
> - client nodes process metadata operation asynchronously so type may be 
> removed at the client after any delay after the remove type operation is 
> completed.
> - if the node that contains the old version of the type joins to the cluster 
> where type was removed the type is propagated to cluster metadata (because 
> metadata tombstone not supported).
> - if the node that contains the old version of the type cannot join to the 
> cluster where type was removed and then updated to the new version (because 
> metadata versioned tombstone not supported).
> So, user scenarios looks like:
> # Be sure that all server nodes supports remove type feature.
> # Remove caches contains the data with type to remove.
> # Stops the client node with older version.
> # Stops all operation with type to remove (don't create binary objects, don't 
> run compute jobs with type to remove).
> # Remove the type on the stable topology (and production destination topolog).
> # Waits any delay (depends on the cluster size and clients count)
> # Produce operations with new version of the type.
> *Proposed command line interface*
> New commands (all commands are _experimental_ ):
> - {{--meta list}} prints info about all available binary types:
> {{typeId=, typeName=, fields=, 
> schemas=, isEnum=}}
> - {{\-\-meta details (\-\- typeId | \-\-typeName )}} prints 
> detailed info info about specified type. The type may be specified by type 
> name or type ID.
> output example:
> {code}
> typeId=0x1FBFBC0C (532659212)
> typeName=TypeName1
> Fields:
>   name=fld3, type=long[], fieldId=0x2FFF95 (3145621)
>   name=fld2, type=double, fieldId=0x2FFF94 (3145620)
>   name=fld1, type=Date, fieldId=0x2FFF93 (3145619)
>   name=fld0, type=int, fieldId=0x2FFF92 (3145618)
> Schemas:
>   schemaId=0x6C5CC179 (1818018169), fields=[fld0]
>   schemaId=0x70E46431 (1894016049), fields=[fld0, fld1, fld2, fld3]
> {code}
> - {{\-\-meta remove (\-\- typeId | \-\-typeName ) [\-\-out 
> ]}} removes metadata for specified type form cluster and saves the 
> removed metadata to the specified file. If the file name isn't specified the 
> output file name is: {{.bin}}
> The command requires confirmation.
> *N.B.*: The all session of thin clients (ODBC, JDBC, thin client) are closed 
> (to cleanup local cache of the binary metadata).
> - {{\-\-meta update \-\-in ]}} update cluster metadata from 
> specified file (file name is required)
> The command requires confirmation.



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


[jira] [Commented] (IGNITE-12903) Fix ML + SQL examples

2020-06-16 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12903:
---

[~zaleslaw], there is not well implemented import from CSV at the Ignite now.
There is CSVREAD command implemented for thin JDBC but CSV parser is 
implemented invalid there.
So for the fix example i see several ways:
- waits for good implementation CSV import functionality (al least for thin 
JDBC see: IGNITE-12852);
- parse cvs files by example's code and use SQL/cache api to insert data;
- populate cache manually not from CSV.

> Fix ML + SQL examples
> -
>
> Key: IGNITE-12903
> URL: https://issues.apache.org/jira/browse/IGNITE-12903
> Project: Ignite
>  Issue Type: Task
>  Components: examples, ml
>Reporter: Taras Ledkov
>Assignee: Alexey Zinoviev
>Priority: Major
>
> The examples
> {{DecisionTreeClassificationTrainerSQLInferenceExample}}
> {{DecisionTreeClassificationTrainerSQLTableExample}}
> are used CSVREAD function to initial load data into cluster.
> Must be changed because this function is disabled by default



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


[jira] [Updated] (IGNITE-13154) Introduce the ability for a user to manage binary types

2020-06-16 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-13154:
--
Summary: Introduce the ability for a user to manage binary types  (was: 
Introduce aility to manage manage binary types by the users)

> Introduce the ability for a user to manage binary types
> ---
>
> Key: IGNITE-13154
> URL: https://issues.apache.org/jira/browse/IGNITE-13154
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>
> We need a way to change schema (including unsupported changes, such as column 
> type change) without cluster restart. This is for the case when all data 
> associated with the binary type has been removed, so removing the old schema 
> is safe.
> Now users must stop the cluster and remove the folder with binary metadata 
> manually.
> The proposed way is to introduce internal API to manage binary types and 
> public command line interface (via control.sh). That way one can remove a 
> cache from the cluster, then unregister corresponding binary types, then 
> launch a new version of an application that would register the new schema and 
> reload the data.
> *The current implementation has restrictions:*
> - all cluster nodes must support remove type feature.
> - the cluster must not contains data with type to remove.
> - operation of the update type must not be launched on the cluster for the 
> type to remove (operation examples: put into cache, 
> BinaryObjectBuilder#build).
> - client nodes process metadata operation asynchronously so type may be 
> removed at the client after any delay after the remove type operation is 
> completed.
> - if the node that contains the old version of the type joins to the cluster 
> where type was removed the type is propagated to cluster metadata (because 
> metadata tombstone not supported).
> - if the node that contains the old version of the type cannot join to the 
> cluster where type was removed and then updated to the new version (because 
> metadata versioned tombstone not supported).
> So, user scenarios looks like:
> # Be sure that all server nodes supports remove type feature.
> # Remove caches contains the data with type to remove.
> # Stops the client node with older version.
> # Stops all operation with type to remove (don't create binary objects, don't 
> run compute jobs with type to remove).
> # Remove the type on the stable topology (and production destination topolog).
> # Waits any delay (depends on the cluster size and clients count)
> # Produce operations with new version of the type.
> *Proposed command line interface*
> New commands (all commands are _experimental_ ):
> - {{--meta list}} prints info about all available binary types:
> {{typeId=, typeName=, fields=, 
> schemas=, isEnum=}}
> - {{\-\-meta details (\-\- typeId | \-\-typeName )}} prints 
> detailed info info about specified type. The type may be specified by type 
> name or type ID.
> output example:
> {code}
> typeId=0x1FBFBC0C (532659212)
> typeName=TypeName1
> Fields:
>   name=fld3, type=long[], fieldId=0x2FFF95 (3145621)
>   name=fld2, type=double, fieldId=0x2FFF94 (3145620)
>   name=fld1, type=Date, fieldId=0x2FFF93 (3145619)
>   name=fld0, type=int, fieldId=0x2FFF92 (3145618)
> Schemas:
>   schemaId=0x6C5CC179 (1818018169), fields=[fld0]
>   schemaId=0x70E46431 (1894016049), fields=[fld0, fld1, fld2, fld3]
> {code}
> - {{\-\-meta remove (\-\- typeId | \-\-typeName ) [\-\-out 
> ]}} removes metadata for specified type form cluster and saves the 
> removed metadata to the specified file. If the file name isn't specified the 
> output file name is: {{.bin}}
> The command requires confirmation.
> *N.B.*: The all session of thin clients (ODBC, JDBC, thin client) are closed 
> (to cleanup local cache of the binary metadata).
> - {{\-\-meta update \-\-in ]}} update cluster metadata from 
> specified file (file name is required)
> The command requires confirmation.



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


[jira] [Created] (IGNITE-13154) Introduce aility to manage manage binary types by the users

2020-06-16 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-13154:
-

 Summary: Introduce aility to manage manage binary types by the 
users
 Key: IGNITE-13154
 URL: https://issues.apache.org/jira/browse/IGNITE-13154
 Project: Ignite
  Issue Type: Improvement
  Components: binary
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


We need a way to change schema (including unsupported changes, such as column 
type change) without cluster restart. This is for the case when all data 
associated with the binary type has been removed, so removing the old schema is 
safe.

Now users must stop the cluster and remove the folder with binary metadata 
manually.

The proposed way is to introduce internal API to manage binary types and public 
command line interface (via control.sh). That way one can remove a cache from 
the cluster, then unregister corresponding binary types, then launch a new 
version of an application that would register the new schema and reload the 
data.

*The current implementation has restrictions:*
- all cluster nodes must support remove type feature.
- the cluster must not contains data with type to remove.
- operation of the update type must not be launched on the cluster for the type 
to remove (operation examples: put into cache, BinaryObjectBuilder#build).
- client nodes process metadata operation asynchronously so type may be removed 
at the client after any delay after the remove type operation is completed.
- if the node that contains the old version of the type joins to the cluster 
where type was removed the type is propagated to cluster metadata (because 
metadata tombstone not supported).
- if the node that contains the old version of the type cannot join to the 
cluster where type was removed and then updated to the new version (because 
metadata versioned tombstone not supported).

So, user scenarios looks like:
# Be sure that all server nodes supports remove type feature.
# Remove caches contains the data with type to remove.
# Stops the client node with older version.
# Stops all operation with type to remove (don't create binary objects, don't 
run compute jobs with type to remove).
# Remove the type on the stable topology (and production destination topolog).
# Waits any delay (depends on the cluster size and clients count)
# Produce operations with new version of the type.

*Proposed command line interface*
New commands (all commands are _experimental_ ):
- {{--meta list}} prints info about all available binary types:
{{typeId=, typeName=, fields=, schemas=, 
isEnum=}}
- {{\-\-meta details (\-\- typeId | \-\-typeName )}} prints detailed 
info info about specified type. The type may be specified by type name or type 
ID.
output example:
{code}
typeId=0x1FBFBC0C (532659212)
typeName=TypeName1
Fields:
  name=fld3, type=long[], fieldId=0x2FFF95 (3145621)
  name=fld2, type=double, fieldId=0x2FFF94 (3145620)
  name=fld1, type=Date, fieldId=0x2FFF93 (3145619)
  name=fld0, type=int, fieldId=0x2FFF92 (3145618)
Schemas:
  schemaId=0x6C5CC179 (1818018169), fields=[fld0]
  schemaId=0x70E46431 (1894016049), fields=[fld0, fld1, fld2, fld3]
{code}
- {{\-\-meta remove (\-\- typeId | \-\-typeName ) [\-\-out 
]}} removes metadata for specified type form cluster and saves the 
removed metadata to the specified file. If the file name isn't specified the 
output file name is: {{.bin}}
The command requires confirmation.
*N.B.*: The all session of thin clients (ODBC, JDBC, thin client) are closed 
(to cleanup local cache of the binary metadata).
- {{\-\-meta update \-\-in ]}} update cluster metadata from 
specified file (file name is required)
The command requires confirmation.




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


[jira] [Assigned] (IGNITE-13025) Calcite integration. Limit and offset support.

2020-06-01 Thread Taras Ledkov (Jira)


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

Taras Ledkov reassigned IGNITE-13025:
-

Assignee: Taras Ledkov

> Calcite integration. Limit and offset support.
> --
>
> Key: IGNITE-13025
> URL: https://issues.apache.org/jira/browse/IGNITE-13025
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Roman Kondakov
>Assignee: Taras Ledkov
>Priority: Major
>
> We can exploit {{Sort}} operator for this purpose or introduce a new operator 
> {{Limit}} by analogy with {{EnumerableLimit}}. Some research is needed.



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


[jira] [Assigned] (IGNITE-13026) Calcite integration. Fix metadata for IgniteTable when it has embedded filters.

2020-06-01 Thread Taras Ledkov (Jira)


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

Taras Ledkov reassigned IGNITE-13026:
-

Assignee: Konstantin Orlov  (was: Taras Ledkov)

> Calcite integration. Fix metadata for IgniteTable when it has embedded 
> filters.
> ---
>
> Key: IGNITE-13026
> URL: https://issues.apache.org/jira/browse/IGNITE-13026
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Roman Kondakov
>Assignee: Konstantin Orlov
>Priority: Major
>
> By default {{RelMdRowCount}} return the actual row count for 
> {{IgniteTables}}. But current implementation of {{IgniteTableScan}} may 
> contain embedded filters and rows that are filtered out by these filters are 
> not taken into account by the metadata subsystem. 
>  For example, table emps contains 1000 rows. Filter name='Vasya' filters out 
> 95% of rows. For now we end up with situation
> {code:java}
> IgniteFilter(name='Vasya') <- estimated cardinality = 50 rows 
>   IgniteTableScan(filters=null) <- estimated cardinality = 1000 rows.
> {code}
> but after merging {{Filter}} into {{Scan}} we get the wrong estimation
> {code:java}
> IgniteTableScan(filters={name='Vasya'}) <- estimated cardinality = 1000 rows. 
> But should be 50 rows.
> {code}
> We need to add a special case in order to compute the actual cardinality 
> returned by {{IgniteTableScan}}



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


[jira] [Created] (IGNITE-13068) SQL: use cache.localSize instead of index scan to calculate row count statistic

2020-05-25 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-13068:
-

 Summary: SQL: use cache.localSize instead of index scan to 
calculate row count statistic 
 Key: IGNITE-13068
 URL: https://issues.apache.org/jira/browse/IGNITE-13068
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


The scan of index is slow on big data set on setup where disc i/o requires warm 
up.
This is the reason that restarting the node can take a long time.



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


[jira] [Assigned] (IGNITE-13026) Calcite integration. Fix metadata for IgniteTable when it has embedded filters.

2020-05-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov reassigned IGNITE-13026:
-

Assignee: Taras Ledkov

> Calcite integration. Fix metadata for IgniteTable when it has embedded 
> filters.
> ---
>
> Key: IGNITE-13026
> URL: https://issues.apache.org/jira/browse/IGNITE-13026
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Roman Kondakov
>Assignee: Taras Ledkov
>Priority: Major
>
> By default {{RelMdRowCount}} return the actual row count for 
> {{IgniteTables}}. But current implementation of {{IgniteTableScan}} may 
> contain embedded filters and rows that are filtered out by these filters are 
> not taken into account by the metadata subsystem. 
>  For example, table emps contains 1000 rows. Filter name='Vasya' filters out 
> 95% of rows. For now we end up with situation
> {code:java}
> IgniteFilter(name='Vasya') <- estimated cardinality = 50 rows 
>   IgniteTableScan(filters=null) <- estimated cardinality = 1000 rows.
> {code}
> but after merging {{Filter}} into {{Scan}} we get the wrong estimation
> {code:java}
> IgniteTableScan(filters={name='Vasya'}) <- estimated cardinality = 1000 rows. 
> But should be 50 rows.
> {code}
> We need to add a special case in order to compute the actual cardinality 
> returned by {{IgniteTableScan}}



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


[jira] [Updated] (IGNITE-13007) JDBC: Introduce feature flags for JDBC thin

2020-05-15 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-13007:
--
Fix Version/s: 2.9

> JDBC: Introduce feature flags for JDBC thin
> ---
>
> Key: IGNITE-13007
> URL: https://issues.apache.org/jira/browse/IGNITE-13007
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Motivation the same as for https://issues.apache.org/jira/browse/IGNITE-12853
> The thin client & JDBC, ODBC have different protocol specific and may require 
> implement different features.
> Each client (thin cli, thin JDBC, ODBC) should have its own feature flags set.



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


[jira] [Commented] (IGNITE-13007) JDBC: Introduce feature flags for JDBC thin

2020-05-15 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-13007:
---

[~korlov], the patch is OK with me. Please take a loot at the one comment about 
empty code block at the new test 
{{JdbcThinConnectionSelfTest#testDisabledFeatures}}

> JDBC: Introduce feature flags for JDBC thin
> ---
>
> Key: IGNITE-13007
> URL: https://issues.apache.org/jira/browse/IGNITE-13007
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Motivation the same as for https://issues.apache.org/jira/browse/IGNITE-12853
> The thin client & JDBC, ODBC have different protocol specific and may require 
> implement different features.
> Each client (thin cli, thin JDBC, ODBC) should have its own feature flags set.



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


[jira] [Commented] (IGNITE-12886) Introduce separate SQL configuration

2020-05-14 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12886:
---

[~amashenkov], I've fixed the minor javadoc issues and reply about thread pool 
property.

> Introduce separate SQL configuration
> 
>
> Key: IGNITE-12886
> URL: https://issues.apache.org/jira/browse/IGNITE-12886
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> A lot of SQL-related configuration parameter are placed at the root of the 
> {{IgniteConfiguration}}.
> It would be better to move them to a separate configuration class, e.g. 
> {{SqlConfiguration}}.
> Thread on [Ignite developers 
> list|http://apache-ignite-developers.2346864.n4.nabble.com/Introduce-separate-SQL-configuration-td46636.html]



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


[jira] [Commented] (IGNITE-12886) Introduce separate SQL configuration

2020-05-14 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12886:
---

[~korlov], [~amashenkov], please review the patch.

> Introduce separate SQL configuration
> 
>
> Key: IGNITE-12886
> URL: https://issues.apache.org/jira/browse/IGNITE-12886
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> A lot of SQL-related configuration parameter are placed at the root of the 
> {{IgniteConfiguration}}.
> It would be better to move them to a separate configuration class, e.g. 
> {{SqlConfiguration}}.
> Thread on [Ignite developers 
> list|http://apache-ignite-developers.2346864.n4.nabble.com/Introduce-separate-SQL-configuration-td46636.html]



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


[jira] [Commented] (IGNITE-12917) SQL: print warning log message when query's result is big

2020-04-24 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12917:
---

[~amashenkov], please review the patch.

> SQL: print warning log message when query's result is big
> -
>
> Key: IGNITE-12917
> URL: https://issues.apache.org/jira/browse/IGNITE-12917
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We have to track queries with big result set.
> Print warning log message when query's result is bigger than threshold 
> specified by JMX.



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


[jira] [Updated] (IGNITE-12732) SQL: KILL QUERY command hangs on query when query cursor is held by user or leak

2020-04-21 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12732:
--
Fix Version/s: 2.9

> SQL: KILL QUERY command hangs on query when query cursor is held by user or 
> leak
> 
>
> Key: IGNITE-12732
> URL: https://issues.apache.org/jira/browse/IGNITE-12732
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Scenario to reproduce:
> 1. Execute a query
> 2. Don't close the query cursor, don't iterate to the end of results.
> 3. Run "KILL QUERY" command. The command hangs.



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


[jira] [Updated] (IGNITE-12609) SQL: GridReduceQueryExecutor refactoring.

2020-04-21 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12609:
--
Fix Version/s: 2.8.1

> SQL: GridReduceQueryExecutor refactoring.
> -
>
> Key: IGNITE-12609
> URL: https://issues.apache.org/jira/browse/IGNITE-12609
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: refactoring
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> For now we have few issues that can be resolved.
> 1. We create fake H2 tables\indices for reduce stage even if there is no need 
> to do so (skipMergeTable=true.
> Let's decouple reduce logic from H2Index adapter code.
> 2. Partition mapping code look to complicated and non-optimal.
> Let's use cached affinity mapping and avoid collections copying when possible.
> 3. Also there is no sense to pass RequestID to mapping code just for logging.
> We'll never be able to match any request as no query really exists at a time 
> when error with RequestID is logged.
> 4. Replicated only flag value semantic (calculation and usage) is not clear.
> 5. GridReduceQueryExecutor.reduce() method is too long (over 400 lines).



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


[jira] [Updated] (IGNITE-12444) SQL: Query reduce can fail with NPE on retry.

2020-04-21 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12444:
--
Fix Version/s: (was: 2.8)
   2.8.1
   2.9

> SQL: Query reduce can fail with NPE on retry.
> -
>
> Key: IGNITE-12444
> URL: https://issues.apache.org/jira/browse/IGNITE-12444
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.6
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> GridReduceQueryExecutor can fail with NPE on retry if it couldn't map during 
> retry timeout.
> So, 'lastRun' can be null here
> {code:java}
>if (attempt > 0 && retryTimeout > 0 && (U.currentTimeMillis() - startTime 
> > retryTimeout)) {
> UUID retryNodeId = lastRun.retryNodeId();
> String retryCause = lastRun.retryCause();
> assert !F.isEmpty(retryCause);
> {code}
> Also assertion above is not correct. 
> It is possible, we failed to send request, then retried with success to remap.
> So, 'lastRun' would be not null, but cause is empty.



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


[jira] [Updated] (IGNITE-12804) SQL: ConnectionManager refactoring

2020-04-21 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12804:
--
Fix Version/s: 2.8.1

> SQL: ConnectionManager refactoring
> --
>
> Key: IGNITE-12804
> URL: https://issues.apache.org/jira/browse/IGNITE-12804
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> As of now ConnectionManager is a mess, really hard to understand. We should 
> refactor it.
> Also ThreadLocal connection is a root cause of complicated behavior of local 
> queries & map queries.
> I guess we have to use simple connection pool. 
> For better performance connection pools will be striped by Thread ID.



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


[jira] [Assigned] (IGNITE-12912) Calcite integration: Add filters merge rule to the planner

2020-04-20 Thread Taras Ledkov (Jira)


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

Taras Ledkov reassigned IGNITE-12912:
-

Assignee: Taras Ledkov

> Calcite integration: Add filters merge rule to the planner
> --
>
> Key: IGNITE-12912
> URL: https://issues.apache.org/jira/browse/IGNITE-12912
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Roman Kondakov
>Assignee: Taras Ledkov
>Priority: Major
>
> We need to add  next rules to planner
>  * FilterMergeRule
>  * FilterProjectTransposeRule
> In order to be able to make this transformation for the query:
> {noformat}
> "select name from (\n"
> + "  select *\n"
> + "  from dept\n"
> + "  where deptno = 10)\n"
> + "where deptno = 10\n"
> BEFORE=
> LogicalProject(NAME=[$1])
>   LogicalFilter(condition=[=(CAST($0):INTEGER, 10)])
> LogicalProject(DEPTNO=[$0], NAME=[$1])
>   LogicalFilter(condition=[=(CAST($0):INTEGER, 10)])
> IgniteTableScan(table=[[PUBLIC, DEPT]])
> AFTER=
> IgniteProject(NAME=[$1])
>   IgniteProject(DEPTNO=[$0], NAME=[$1])
> IgniteFilter(condition=[=(CAST($0):INTEGER, 10)])
>   IgniteTableScan(table=[[PUBLIC, DEPT]])
> {noformat}
>  
>  



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


[jira] [Updated] (IGNITE-12917) SQL: print warning log message when query's result is big

2020-04-20 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12917:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> SQL: print warning log message when query's result is big
> -
>
> Key: IGNITE-12917
> URL: https://issues.apache.org/jira/browse/IGNITE-12917
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We have to track queries with big result set.
> Print warning log message when query's result is bigger than threshold 
> specified by JMX.



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


[jira] [Created] (IGNITE-12917) SQL: print warning log message when query's result is big

2020-04-20 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12917:
-

 Summary: SQL: print warning log message when query's result is big
 Key: IGNITE-12917
 URL: https://issues.apache.org/jira/browse/IGNITE-12917
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


We have to track queries with big result set.
Print warning log message when query's result is bigger than threshold 
specified by JMX.



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


[jira] [Commented] (IGNITE-12717) SQL: index creation refactoring

2020-04-20 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12717:
---

[~nizhikov], I think no. I didn't add this version. The improvements related to 
change index inline behavior depend on this patch.
But i don't see these issues in the 2.8.1 scope.

I've added 2.8.1 to some ticket that looks like critical bug (e.g. connection 
leaks, node stops etc). 

Did you add the 2.8.1 version by bulk update tickets and review one-by-one?

> SQL: index creation refactoring
> ---
>
> Key: IGNITE-12717
> URL: https://issues.apache.org/jira/browse/IGNITE-12717
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Do refactoring children of the H2 IndexBase to simplify the H2 upgrade.



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


[jira] [Issue Comment Deleted] (IGNITE-12579) JDBC SQL INSERT operation hangs with security enabled.

2020-04-17 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12579:
--
Comment: was deleted

(was: Looks like the patch IGNITE-12759 must fix the issue.)

> JDBC SQL INSERT operation hangs with security enabled.
> --
>
> Key: IGNITE-12579
> URL: https://issues.apache.org/jira/browse/IGNITE-12579
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
>  Labels: iep-41
> Attachments: JdbcRemoteKeyInsertTest.java
>
>
>  
> SQL INSERT operation hangs in case INSERT KEY belongs to remote node(node 
> that is different from one to which jdbc connection was established) and 
> security enabled with the following exception in log:
> {code:java}
> [2020-01-24 
> 14:59:42,189][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][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=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.NullPointerException]][2020-01-24 
> 14:59:42,189][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][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=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.NullPointerException]]java.lang.NullPointerException at 
> org.apache.ignite.internal.processors.security.SecurityUtils.nodeSecurityContext(SecurityUtils.java:132)
>  at 
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.lambda$withContext$0(IgniteSecurityProcessor.java:106)
>  at 
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
>  at 
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:105)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1844)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1470)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1365)
>  at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
>  at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at 
> java.lang.Thread.run(Thread.java:748)[2020-01-24 14:59:42,198][WARN 
> ][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][CacheDiagnosticManager] 
> Page locks dump:
> Thread=[name=auth-#83%jdbc.JdbcRemoteKeyInsertTest1%, id=116], 
> state=WAITINGLocked pages = []Locked pages log: 
> name=auth-#83%jdbc.JdbcRemoteKeyInsertTest1% time=(1579867182194, 2020-01-24 
> 14:59:42.194)Thread=[name=db-checkpoint-thread-#101%jdbc.JdbcRemoteKeyInsertTest1%,
>  id=135], state=TIMED_WAITINGLocked pages = []Locked pages log: 
> name=db-checkpoint-thread-#101%jdbc.JdbcRemoteKeyInsertTest1% 
> time=(1579867182194, 2020-01-24 
> 14:59:42.194)Thread=[name=dms-writer-thread-#92%jdbc.JdbcRemoteKeyInsertTest1%,
>  id=126], state=WAITINGLocked pages = []Locked pages log: 
> name=dms-writer-thread-#92%jdbc.JdbcRemoteKeyInsertTest1% 
> time=(1579867182194, 2020-01-24 
> 14:59:42.194)Thread=[name=exchange-worker-#84%jdbc.JdbcRemoteKeyInsertTest1%, 
> id=117], state=TIMED_WAITINGLocked pages = []Locked pages log: 
> name=exchange-worker-#84%jdbc.JdbcRemoteKeyInsertTest1% time=(1579867182194, 
> 2020-01-24 14:59:42.194)Thread=[name=main, id=1], state=TIMED_WAITINGLocked 
> pages = []Locked pages log: name=main time=(1579867182193, 2020-01-24 
> 14:59:42.193)
> [2020-01-24 
> 14:59:42,198][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][G] 
> Failed to execute runnable.java.lang.NullPointerException at 
> org.apache.ignite.internal.processors.security.SecurityUtils.nodeSecurityContext(SecurityUtils.java:132)
>  at 
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.lambda$withContext$0(IgniteSecurityProcessor.java:106)
>  at 
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
>  at 
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:105)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1844)
>  at 
> 

[jira] [Commented] (IGNITE-12833) JDBC thin client SELECT hangs under 2.8.0

2020-04-17 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12833:
---

Looks like the patch IGNITE-12759 must fix the issue.

> JDBC thin client SELECT hangs under 2.8.0
> -
>
> Key: IGNITE-12833
> URL: https://issues.apache.org/jira/browse/IGNITE-12833
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, security
>Affects Versions: 2.8
>Reporter: Veena Mithare
>Priority: Blocker
>  Labels: iep-41
> Attachments: JdbcSelectHangsIn2.8.0Mail.txt
>
>
> |
> |When security is enabled, and an update or select sql is issued from 
> dbeaver, the security context in 
> class GridIOManager , 
> method -createGridIoMessage - 
> line - ctx.security().securityContext() returns  the securitycontext of the 
> thin client. 
> The message generated out of createGridIoMessage  is passed on to the next 
> node. 
> This is used in 
> class - IgniteSecurityProcessor 
> method - ( withContext) 
> line - ctx.discovery().node(uuid) 
> on the next node :     
> @Override public OperationSecurityContext withContext(UUID nodeId) 
> {        return withContext(            secCtxs.computeIfAbsent(nodeId,       
>         
> uuid -> nodeSecurityContext(                    marsh, 
> U.resolveClassLoader(ctx.config()), ctx.discovery().node(uuid)               
> )            )        );    } 
> The ctx.discovery().node(uuid) used to 
> determine the ClusterNode that is passed into nodeSecurityContext() returns 
> null, since the uuid is that of the remote client id not the remote node id. 
> Hence 
> class: SecurityUtils.java 
> method : nodeSecurityContext 
> line :         byte[] subjBytes = 
> node.attribute(IgniteNodeAttributes.ATTR_SECURITY_SUBJECT_V2); 
> Throws null pointer exception since node is null. 
> Related ticket : 
> IGNITE-12579
>  
> Related discussion : 
> [http://apache-ignite-users.70518.x6.nabble.com/2-8-0-JDBC-Thin-Client-Unable-to-load-the-tables-via-DBeaver-td31681.html#a31847]|
> |



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


[jira] [Commented] (IGNITE-12579) JDBC SQL INSERT operation hangs with security enabled.

2020-04-17 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12579:
---

Looks like the patch IGNITE-12759 must fix the issue.

> JDBC SQL INSERT operation hangs with security enabled.
> --
>
> Key: IGNITE-12579
> URL: https://issues.apache.org/jira/browse/IGNITE-12579
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
>  Labels: iep-41
> Attachments: JdbcRemoteKeyInsertTest.java
>
>
>  
> SQL INSERT operation hangs in case INSERT KEY belongs to remote node(node 
> that is different from one to which jdbc connection was established) and 
> security enabled with the following exception in log:
> {code:java}
> [2020-01-24 
> 14:59:42,189][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][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=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.NullPointerException]][2020-01-24 
> 14:59:42,189][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][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=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.NullPointerException]]java.lang.NullPointerException at 
> org.apache.ignite.internal.processors.security.SecurityUtils.nodeSecurityContext(SecurityUtils.java:132)
>  at 
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.lambda$withContext$0(IgniteSecurityProcessor.java:106)
>  at 
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
>  at 
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:105)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1844)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1470)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1365)
>  at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
>  at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at 
> java.lang.Thread.run(Thread.java:748)[2020-01-24 14:59:42,198][WARN 
> ][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][CacheDiagnosticManager] 
> Page locks dump:
> Thread=[name=auth-#83%jdbc.JdbcRemoteKeyInsertTest1%, id=116], 
> state=WAITINGLocked pages = []Locked pages log: 
> name=auth-#83%jdbc.JdbcRemoteKeyInsertTest1% time=(1579867182194, 2020-01-24 
> 14:59:42.194)Thread=[name=db-checkpoint-thread-#101%jdbc.JdbcRemoteKeyInsertTest1%,
>  id=135], state=TIMED_WAITINGLocked pages = []Locked pages log: 
> name=db-checkpoint-thread-#101%jdbc.JdbcRemoteKeyInsertTest1% 
> time=(1579867182194, 2020-01-24 
> 14:59:42.194)Thread=[name=dms-writer-thread-#92%jdbc.JdbcRemoteKeyInsertTest1%,
>  id=126], state=WAITINGLocked pages = []Locked pages log: 
> name=dms-writer-thread-#92%jdbc.JdbcRemoteKeyInsertTest1% 
> time=(1579867182194, 2020-01-24 
> 14:59:42.194)Thread=[name=exchange-worker-#84%jdbc.JdbcRemoteKeyInsertTest1%, 
> id=117], state=TIMED_WAITINGLocked pages = []Locked pages log: 
> name=exchange-worker-#84%jdbc.JdbcRemoteKeyInsertTest1% time=(1579867182194, 
> 2020-01-24 14:59:42.194)Thread=[name=main, id=1], state=TIMED_WAITINGLocked 
> pages = []Locked pages log: name=main time=(1579867182193, 2020-01-24 
> 14:59:42.193)
> [2020-01-24 
> 14:59:42,198][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][G] 
> Failed to execute runnable.java.lang.NullPointerException at 
> org.apache.ignite.internal.processors.security.SecurityUtils.nodeSecurityContext(SecurityUtils.java:132)
>  at 
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.lambda$withContext$0(IgniteSecurityProcessor.java:106)
>  at 
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
>  at 
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:105)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1844)
>  at 
> 

[jira] [Created] (IGNITE-12903) Fix ML + SQL examples

2020-04-16 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12903:
-

 Summary: Fix ML + SQL examples
 Key: IGNITE-12903
 URL: https://issues.apache.org/jira/browse/IGNITE-12903
 Project: Ignite
  Issue Type: Task
  Components: examples
Reporter: Taras Ledkov
Assignee: Taras Ledkov


The examples
{{DecisionTreeClassificationTrainerSQLInferenceExample}}
{{DecisionTreeClassificationTrainerSQLTableExample}}
are used CSVREAD function to initial load data into cluster.

Must be changed because this function is disabled by default



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


[jira] [Created] (IGNITE-12887) Node stops on type mismatch error between index type and type of value from searched row

2020-04-10 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12887:
-

 Summary: Node stops on type mismatch error between index type and 
type of value from searched row
 Key: IGNITE-12887
 URL: https://issues.apache.org/jira/browse/IGNITE-12887
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.8
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.8.1


Steps to reproduce:
1. Create table with value fields types: (INT, OTHER) and create indexes for 
the fields:
{code}
CREATE TABLE TEST (ID INT PRIMARY KEY, val_int INT, VAL_OBJ OTHER)
CREATE INDEX TEST_VAL_INT ON TEST(VAL_INT)
CREATE INDEX TEST_VAL_OBJ ON TEST(VAL_OBJ)
{code}

2. Add any data to the table:
{code}
INSERT INTO TEST VALUES (0, 0, ?)
{code}

3. Any of the query below crushes and node stops:
SELECT * FROM TEST WHERE VAL_OBJ < CURRENT_TIMESTAMP()
SELECT * FROM TEST WHERE VAL_INT < CURRENT_TIMESTAMP()


*Root cause*: all runtime exception inside {{Index.find}} is converted to 
{{CorruptedTreeException}} and stops the node,



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


[jira] [Created] (IGNITE-12886) Introduce separate SQL configuration

2020-04-10 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12886:
-

 Summary: Introduce separate SQL configuration
 Key: IGNITE-12886
 URL: https://issues.apache.org/jira/browse/IGNITE-12886
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


A lot of SQL-related configuration parameter are placed at the root of the 
{{IgniteConfiguration}}.
It would be better to move them to a separate configuration class, e.g. 
{{SqlConfiguration}}.

Thread on [Ignite developers 
list|http://apache-ignite-developers.2346864.n4.nabble.com/Introduce-separate-SQL-configuration-td46636.html]



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


[jira] [Comment Edited] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used

2020-04-09 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-12764 at 4/9/20, 10:54 AM:
-

[~cyberdemon], the path is OK with me.
Please fix codestyle (empty lines) at the 
{{JdbcSqlStreamingTest#JdbcSqlStreamingTest}}


was (Author: tledkov-gridgain):
[~cyberdemon], the path is OK with me.
Please fix codestyle at the {{JdbcSqlStreamingTest#JdbcSqlStreamingTest}}

> Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
> --
>
> Key: IGNITE-12764
> URL: https://issues.apache.org/jira/browse/IGNITE-12764
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Dmitriy Sorokin
>Priority: Blocker
> Fix For: 2.8.1
>
> Attachments: SqlMain.java
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> insert INTO  city1(id,name,name1) VALUES(?,?,RANDOM_UUID())
> happily worked in 2.7.6 but will fail on 2.8.0 with:
> Exception in thread "main" java.sql.BatchUpdateException: class 
> org.apache.ignite.IgniteCheckedException: null
>   at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> Suspected reason is that function RANDOM_UUID() is not processed correctly 
> here. Column type does not matter between UUID and VARCHAR.



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


[jira] [Comment Edited] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used

2020-04-09 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-12764 at 4/9/20, 10:54 AM:
-

[~cyberdemon], the path is OK with me.
Please fix codestyle at the {{JdbcSqlStreamingTest#JdbcSqlStreamingTest}}


was (Author: tledkov-gridgain):
[~cyberdemon], the path is OK with me.

> Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
> --
>
> Key: IGNITE-12764
> URL: https://issues.apache.org/jira/browse/IGNITE-12764
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Dmitriy Sorokin
>Priority: Blocker
> Fix For: 2.8.1
>
> Attachments: SqlMain.java
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> insert INTO  city1(id,name,name1) VALUES(?,?,RANDOM_UUID())
> happily worked in 2.7.6 but will fail on 2.8.0 with:
> Exception in thread "main" java.sql.BatchUpdateException: class 
> org.apache.ignite.IgniteCheckedException: null
>   at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> Suspected reason is that function RANDOM_UUID() is not processed correctly 
> here. Column type does not matter between UUID and VARCHAR.



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


[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used

2020-04-09 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12764:
---

[~cyberdemon]m the path is OK with me.

> Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
> --
>
> Key: IGNITE-12764
> URL: https://issues.apache.org/jira/browse/IGNITE-12764
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Dmitriy Sorokin
>Priority: Blocker
> Fix For: 2.8.1
>
> Attachments: SqlMain.java
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> insert INTO  city1(id,name,name1) VALUES(?,?,RANDOM_UUID())
> happily worked in 2.7.6 but will fail on 2.8.0 with:
> Exception in thread "main" java.sql.BatchUpdateException: class 
> org.apache.ignite.IgniteCheckedException: null
>   at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> Suspected reason is that function RANDOM_UUID() is not processed correctly 
> here. Column type does not matter between UUID and VARCHAR.



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


[jira] [Comment Edited] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used

2020-04-09 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-12764 at 4/9/20, 10:52 AM:
-

[~cyberdemon], the path is OK with me.


was (Author: tledkov-gridgain):
[~cyberdemon]m the path is OK with me.

> Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
> --
>
> Key: IGNITE-12764
> URL: https://issues.apache.org/jira/browse/IGNITE-12764
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Dmitriy Sorokin
>Priority: Blocker
> Fix For: 2.8.1
>
> Attachments: SqlMain.java
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> insert INTO  city1(id,name,name1) VALUES(?,?,RANDOM_UUID())
> happily worked in 2.7.6 but will fail on 2.8.0 with:
> Exception in thread "main" java.sql.BatchUpdateException: class 
> org.apache.ignite.IgniteCheckedException: null
>   at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> Suspected reason is that function RANDOM_UUID() is not processed correctly 
> here. Column type does not matter between UUID and VARCHAR.



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


[jira] [Issue Comment Deleted] (IGNITE-12848) SQL: H2Connection leaks on INSERT

2020-04-09 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12848:
--
Comment: was deleted

(was: [~ilyak], I think no.
As far as i know not constant values aren't supported in streaming mode. Needs 
to investigation.)

> SQL: H2Connection leaks on INSERT
> -
>
> Key: IGNITE-12848
> URL: https://issues.apache.org/jira/browse/IGNITE-12848
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> H2 connection leaks on INSERT query when one row is inserted and not constant 
> values are used:
> e.g.:
> {{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}
> *Root cause:*
> Query cursor isn't closed at the 
> {{IgniteH2Indexing#executeUpdateNonTransactional}} after 
> {{DmlUtils#processSelectResult}}.



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


[jira] [Created] (IGNITE-12870) Fix test JdbcThinTransactionsLeaksMvccTest after connection manager refactoring

2020-04-07 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12870:
-

 Summary: Fix test JdbcThinTransactionsLeaksMvccTest after 
connection manager refactoring
 Key: IGNITE-12870
 URL: https://issues.apache.org/jira/browse/IGNITE-12870
 Project: Ignite
  Issue Type: Test
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


The test {{JdbcThinTransactionsLeaksMvccTest#testLeaks}} is broken by the patch 
IGNITE-12804. The method  {{detachedConnectionCount}} must be change to check 
used connection after connection manager refactoring.




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


[jira] [Commented] (IGNITE-12804) SQL: ConnectionManager refactoring

2020-04-03 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12804:
---

[~amashenkov], the review comments are fixed and tests are re-run.
Please review.

> SQL: ConnectionManager refactoring
> --
>
> Key: IGNITE-12804
> URL: https://issues.apache.org/jira/browse/IGNITE-12804
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> As of now ConnectionManager is a mess, really hard to understand. We should 
> refactor it.
> Also ThreadLocal connection is a root cause of complicated behavior of local 
> queries & map queries.
> I guess we have to use simple connection pool. 
> For better performance connection pools will be striped by Thread ID.



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


[jira] [Commented] (IGNITE-12848) SQL: H2Connection leaks on INSERT

2020-04-01 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12848:
---

[~ilyak], I think no.
As far as i know not constant values aren't supported in streaming mode. Needs 
to investigation.

> SQL: H2Connection leaks on INSERT
> -
>
> Key: IGNITE-12848
> URL: https://issues.apache.org/jira/browse/IGNITE-12848
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> H2 connection leaks on INSERT query when one row is inserted and not constant 
> values are used:
> e.g.:
> {{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}
> *Root cause:*
> Query cursor isn't closed at the 
> {{IgniteH2Indexing#executeUpdateNonTransactional}} after 
> {{DmlUtils#processSelectResult}}.



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


[jira] [Updated] (IGNITE-12848) SQL: H2Connection leaks on INSERT

2020-03-31 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12848:
--
Description: 
H2 connection leaks on INSERT query when one row is inserted and not constant 
values are used:
e.g.:
{{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}

*Root cause:*
Query cursor isn't closed at the 
{{IgniteH2Indexing#executeUpdateNonTransactional}} after 
{{DmlUtils#processSelectResult}}.

  was:
H2 connection leaks on INSERT query when one row is inserted and not constant 
values are used:
e.g.:
{{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}

*Root cause:*
Query cursor isn't closed at the IgniteH2Indexing#executeUpdateNonTransactional 
after {{DmlUtils#processSelectResult}}.


> SQL: H2Connection leaks on INSERT
> -
>
> Key: IGNITE-12848
> URL: https://issues.apache.org/jira/browse/IGNITE-12848
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> H2 connection leaks on INSERT query when one row is inserted and not constant 
> values are used:
> e.g.:
> {{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}
> *Root cause:*
> Query cursor isn't closed at the 
> {{IgniteH2Indexing#executeUpdateNonTransactional}} after 
> {{DmlUtils#processSelectResult}}.



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


[jira] [Created] (IGNITE-12848) SQL: H2Connection leaks on INSERT

2020-03-31 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12848:
-

 Summary: SQL: H2Connection leaks on INSERT
 Key: IGNITE-12848
 URL: https://issues.apache.org/jira/browse/IGNITE-12848
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.8
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.8.1


H2 connection leaks on INSERT query when one row is inserted and not constant 
values are used:
e.g.:
{{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}

*Root cause:*
Query cursor isn't closed at the IgniteH2Indexing#executeUpdateNonTransactional 
after {{DmlUtils#processSelectResult}}.



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


[jira] [Comment Edited] (IGNITE-12804) SQL: ConnectionManager refactoring

2020-03-26 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-12804 at 3/26/20, 7:16 PM:
-

Benchmark results: performance drop about 2%-3%:

sql-query benchmark (two runs):
|| master || patch ||
| 42786.50 | 41625.50 (-2.71%) |
| 42629.80 | 41557.00 (-2.52%) |


was (Author: tledkov-gridgain):
Benchmark results: performance drop about 2%-3%:

sql-query benchmark (two runs):
|| master || patch ||
| 42786.50  0.00% | 41625.50-2.71% |
| 42629.80  0.00% | 41557.00-2.52% |

> SQL: ConnectionManager refactoring
> --
>
> Key: IGNITE-12804
> URL: https://issues.apache.org/jira/browse/IGNITE-12804
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As of now ConnectionManager is a mess, really hard to understand. We should 
> refactor it.
> Also ThreadLocal connection is a root cause of complicated behavior of local 
> queries & map queries.
> I guess we have to use simple connection pool. 
> For better performance connection pools will be striped by Thread ID.



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


[jira] [Commented] (IGNITE-12804) SQL: ConnectionManager refactoring

2020-03-26 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12804:
---

Benchmark results: performance drop about 2%-3%:

sql-query benchmark (two runs):
|| master || patch ||
| 42786.50  0.00% | 41625.50-2.71% |
| 42629.80  0.00% | 41557.00-2.52% |

> SQL: ConnectionManager refactoring
> --
>
> Key: IGNITE-12804
> URL: https://issues.apache.org/jira/browse/IGNITE-12804
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As of now ConnectionManager is a mess, really hard to understand. We should 
> refactor it.
> Also ThreadLocal connection is a root cause of complicated behavior of local 
> queries & map queries.
> I guess we have to use simple connection pool. 
> For better performance connection pools will be striped by Thread ID.



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


[jira] [Commented] (IGNITE-12804) SQL: ConnectionManager refactoring

2020-03-26 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12804:
---

Master base branch to benchmark: 
[PR7576|https://github.com/apache/ignite/pull/7576]

> SQL: ConnectionManager refactoring
> --
>
> Key: IGNITE-12804
> URL: https://issues.apache.org/jira/browse/IGNITE-12804
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As of now ConnectionManager is a mess, really hard to understand. We should 
> refactor it.
> Also ThreadLocal connection is a root cause of complicated behavior of local 
> queries & map queries.
> I guess we have to use simple connection pool. 
> For better performance connection pools will be striped by Thread ID.



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


[jira] [Updated] (IGNITE-12804) SQL: ConnectionManager refactoring

2020-03-25 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12804:
--
Description: 
As of now ConnectionManager is a mess, really hard to understand. We should 
refactor it.

Also ThreadLocal connection is a root cause of complicated behavior of local 
queries & map queries.

I guess we have to use simple connection pool. 
For better performance connection pools will be striped by Thread ID.


  was:
As of now ConnectionManager is a mess, really hard to understand. We should 
refactor it.

AlsoThreadLocal connection is a root cause of complicated behavior of local 
queries & map queries.

I guess we have to use simple connection pool. 
For better performance several striped by Thread ID connection pools may be 
used.



> SQL: ConnectionManager refactoring
> --
>
> Key: IGNITE-12804
> URL: https://issues.apache.org/jira/browse/IGNITE-12804
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>
> As of now ConnectionManager is a mess, really hard to understand. We should 
> refactor it.
> Also ThreadLocal connection is a root cause of complicated behavior of local 
> queries & map queries.
> I guess we have to use simple connection pool. 
> For better performance connection pools will be striped by Thread ID.



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


[jira] [Resolved] (IGNITE-11537) SQL: enchanced log mode for SQL queries

2020-03-23 Thread Taras Ledkov (Jira)


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

Taras Ledkov resolved IGNITE-11537.
---
Fix Version/s: 2.8
   Resolution: Duplicate

The major functions of the issue are covered by IGNITE-11143.
e.g. long running query timeout {{SqlQueryMXBean#setLongQueryWarningTimeout}} 
may be set to 1 ms and the most queries are logged in this case.

> SQL: enchanced log mode for SQL queries
> ---
>
> Key: IGNITE-11537
> URL: https://issues.apache.org/jira/browse/IGNITE-11537
> Project: Ignite
>  Issue Type: Task
>Reporter: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
>
> Additional information about run queries are needed:
> - log each query start execution on H2 engine includes local queries and map 
> parts of distributed query (needs to monitoring node SQL pressure);
> - EXPLAIN / ANALYZE for long running queries;
> - ResultSet cardinality for long running queries (e.g. by threshold);
> Enable / disable enhanced log mode may be managed by JMX, internal SQL 
> command or other way.



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


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-20 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-8152:
--

[~Aleksei_Litsov], right way, great results!

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



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


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-8152:
--

Hi, I mean the run All status of TC.
See for example: IGNITE-12740
[TC Bot|https://mtcga.gridgain.com/]


> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



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


[jira] [Commented] (IGNITE-12800) SQL: local queries cursors must be closed or full read to unlock the GridH2Table.

2020-03-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12800:
---

I've added the ticket for refactoring {{ConnectionManager}}: IGNITE-12804
Now It's really mess and hard to understand.

> SQL: local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> -
>
> Key: IGNITE-12800
> URL: https://issues.apache.org/jira/browse/IGNITE-12800
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> *Root cause:* local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> *Proposal fix:*
> - modify {{H2ResultSetIterator}} to use "paged mode": iterator reads N 
> records into internal buffer and unlock the tables (similar to 
> {{MapQueryResult}}; later we have to refactor these classes. They must use 
> one code base to fetch data and lok/unlock tables)
> - modify the state logic of the {{QueryCursorImpl}} for lazy mode. Now the 
> real query cancellation isn't called when result set is gathered. It is not 
> valid for lazy mode.
> - add wrapper for iterator at the {{RegisteredQueryCursor}} because the state 
> of query isn't tracked when results are read via Iterator at the client code.
> - fix tests that doesn't close query cursor for local queries.



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


[jira] [Updated] (IGNITE-12800) SQL: local queries cursors must be closed or full read to unlock the GridH2Table.

2020-03-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12800:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> SQL: local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> -
>
> Key: IGNITE-12800
> URL: https://issues.apache.org/jira/browse/IGNITE-12800
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> *Root cause:* local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> *Proposal fix:*
> - modify {{H2ResultSetIterator}} to use "paged mode": iterator reads N 
> records into internal buffer and unlock the tables (similar to 
> {{MapQueryResult}}; later we have to refactor these classes. They must use 
> one code base to fetch data and lok/unlock tables)
> - modify the state logic of the {{QueryCursorImpl}} for lazy mode. Now the 
> real query cancellation isn't called when result set is gathered. It is not 
> valid for lazy mode.
> - add wrapper for iterator at the {{RegisteredQueryCursor}} because the state 
> of query isn't tracked when results are read via Iterator at the client code.
> - fix tests that doesn't close query cursor for local queries.



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


[jira] [Created] (IGNITE-12804) SQL: ConnectionManager refactoring

2020-03-19 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12804:
-

 Summary: SQL: ConnectionManager refactoring
 Key: IGNITE-12804
 URL: https://issues.apache.org/jira/browse/IGNITE-12804
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.8
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


As of now ConnectionManager is a mess, really hard to understand. We should 
refactor it.

AlsoThreadLocal connection is a root cause of complicated behavior of local 
queries & map queries.

I guess we have to use simple connection pool. 
For better performance several striped by Thread ID connection pools may be 
used.




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


[jira] [Comment Edited] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-8152 at 3/19/20, 8:26 AM:


[~Aleksei_Litsov], the patch is OK with me. Please fix minor codestyle:
1. {{H2ConnectionWrapper#connection(java.lang.String)}} empty string
2. javadoc for {{BaseSqlTest#executeFrom(java.lang.String, 
org.apache.ignite.Ignite, java.lang.String)}}

What about tests visa from TC Bot?


was (Author: tledkov-gridgain):
[~Aleksei_Litsov], the patch is OK with me. Please fix minor codestyle:
1. {{H2ConnectionWrapper#connection(java.lang.String)}} empty string
2. javadoc for {{BaseSqlTest#executeFrom(java.lang.String, 
org.apache.ignite.Ignite, java.lang.String)}}

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



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


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-8152:
--

[~Aleksei_Litsov], the patch is OK with me. Please fix minor codestyle:
1. {{H2ConnectionWrapper#connection(java.lang.String)}} empty string
2. javadoc for {{BaseSqlTest#executeFrom(java.lang.String, 
org.apache.ignite.Ignite, java.lang.String)}}

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



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


[jira] [Updated] (IGNITE-12800) SQL: local queries cursors must be closed or full read to unlock the GridH2Table.

2020-03-18 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12800:
--
Priority: Critical  (was: Major)

> SQL: local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> -
>
> Key: IGNITE-12800
> URL: https://issues.apache.org/jira/browse/IGNITE-12800
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> *Root cause:* local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> *Proposal fix:*
> - modify {{H2ResultSetIterator}} to use "paged mode": iterator reads N 
> records into internal buffer and unlock the tables (similar to 
> {{MapQueryResult}}; later we have to refactor these classes. They must use 
> one code base to fetch data and lok/unlock tables)
> - modify the state logic of the {{QueryCursorImpl}} for lazy mode. Now the 
> real query cancellation isn't called when result set is gathered. It is not 
> valid for lazy mode.
> - add wrapper for iterator at the {{RegisteredQueryCursor}} because the state 
> of query isn't tracked when results are read via Iterator at the client code.
> - fix tests that doesn't close query cursor for local queries.



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


[jira] [Updated] (IGNITE-12800) SQL: local queries cursors must be closed or full read to unlock the GridH2Table.

2020-03-18 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12800:
--
Fix Version/s: (was: 2.9)
   2.8.1

> SQL: local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> -
>
> Key: IGNITE-12800
> URL: https://issues.apache.org/jira/browse/IGNITE-12800
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8.1
>
>
> *Root cause:* local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> *Proposal fix:*
> - modify {{H2ResultSetIterator}} to use "paged mode": iterator reads N 
> records into internal buffer and unlock the tables (similar to 
> {{MapQueryResult}}; later we have to refactor these classes. They must use 
> one code base to fetch data and lok/unlock tables)
> - modify the state logic of the {{QueryCursorImpl}} for lazy mode. Now the 
> real query cancellation isn't called when result set is gathered. It is not 
> valid for lazy mode.
> - add wrapper for iterator at the {{RegisteredQueryCursor}} because the state 
> of query isn't tracked when results are read via Iterator at the client code.
> - fix tests that doesn't close query cursor for local queries.



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


[jira] [Created] (IGNITE-12800) SQL: local queries cursors must be closed or full read to unlock the GridH2Table.

2020-03-18 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12800:
-

 Summary: SQL: local queries cursors must be closed or full read to 
unlock the GridH2Table.
 Key: IGNITE-12800
 URL: https://issues.apache.org/jira/browse/IGNITE-12800
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.8
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


*Root cause:* local queries cursors must be closed or full read to unlock the 
GridH2Table.

*Proposal fix:*
- modify {{H2ResultSetIterator}} to use "paged mode": iterator reads N records 
into internal buffer and unlock the tables (similar to {{MapQueryResult}}; 
later we have to refactor these classes. They must use one code base to fetch 
data and lok/unlock tables)
- modify the state logic of the {{QueryCursorImpl}} for lazy mode. Now the real 
query cancellation isn't called when result set is gathered. It is not valid 
for lazy mode.
- add wrapper for iterator at the {{RegisteredQueryCursor}} because the state 
of query isn't tracked when results are read via Iterator at the client code.
- fix tests that doesn't close query cursor for local queries.




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


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-12 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-8152:
--

[~Aleksei_Litsov], the patch is not clear for me.

Disallow use empty string for schema is useful patch, but I guess the schema's 
name must be checked on the schema creation (see {{SchemaManager#createSchema}})

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



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


[jira] [Comment Edited] (IGNITE-12740) Supports feature flags on index meta page

2020-03-06 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-12740 at 3/6/20, 8:33 AM:


[~amashenkov], [~ivan.glukos] please review the patch.


was (Author: tledkov-gridgain):
[~amashenkov], please review the patch.

> Supports feature flags on index meta page
> -
>
> Key: IGNITE-12740
> URL: https://issues.apache.org/jira/browse/IGNITE-12740
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Some changes on indexing e.g. inl;ine java objects, unwrap PK columns and 
> several planned features (change inline pojo format, inline DECIMAL fields 
> etc) break backward compatibility.
> We have to add metadata about index layout and format to index tree meta-page.



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


[jira] [Updated] (IGNITE-12740) Supports feature flags on index meta page

2020-03-03 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12740:
--
Summary: Supports feature flags on index meta page  (was: Supports feature 
flags on index meta pages)

> Supports feature flags on index meta page
> -
>
> Key: IGNITE-12740
> URL: https://issues.apache.org/jira/browse/IGNITE-12740
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>
> Some changes on indexing e.g. inl;ine java objects, unwrap PK columns and 
> several planned features (change inline pojo format, inline DECIMAL fields 
> etc) break backward compatibility.
> We have to add metadata about index layout and format to index tree meta-page.



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


[jira] [Created] (IGNITE-12740) Supports feature flags on index meta pages

2020-03-03 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12740:
-

 Summary: Supports feature flags on index meta pages
 Key: IGNITE-12740
 URL: https://issues.apache.org/jira/browse/IGNITE-12740
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


Some changes on indexing e.g. inl;ine java objects, unwrap PK columns and 
several planned features (change inline pojo format, inline DECIMAL fields etc) 
break backward compatibility.

We have to add metadata about index layout and format to index tree meta-page.



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


[jira] [Updated] (IGNITE-12717) SQL: index creation refactoring

2020-02-26 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12717:
--
Summary: SQL: index creation refactoring  (was: SQL: indexing DB object 
creation refactoring)

> SQL: index creation refactoring
> ---
>
> Key: IGNITE-12717
> URL: https://issues.apache.org/jira/browse/IGNITE-12717
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>
> Do refactoring children of the H2 IndexBase to simplify the H2 upgrade.



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


[jira] [Created] (IGNITE-12717) SQL: indexing DB object creation refactoring

2020-02-26 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12717:
-

 Summary: SQL: indexing DB object creation refactoring
 Key: IGNITE-12717
 URL: https://issues.apache.org/jira/browse/IGNITE-12717
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


Do refactoring children of the H2 IndexBase to simplify the H2 upgrade.



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


[jira] [Commented] (IGNITE-12590) MERGE INTO query is failing on Ignite client node

2020-02-17 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12590:
---

The review issues are fixed.
[~amashenkov], please review and merge the patch.

> MERGE INTO query is failing on Ignite client node
> -
>
> Key: IGNITE-12590
> URL: https://issues.apache.org/jira/browse/IGNITE-12590
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Precondition: server nodes (any amount), webconsole is running.
> 1. Create the table as following:
> CREATE TABLE USERPUBSTATICDATA (BOOK VARCHAR, DESK VARCHAR, TRADERS VARCHAR, 
> REGION VARCHAR, LOB VARCHAR, EXCLUDE VARCHAR, TRANSIT VARCHAR, 
> MAPBOOKTOTHISBOOK VARCHAR, CONSTRAINT USERPUBSTATICDATA_PK PRIMARY KEY 
> (BOOK,DESK)) WITH "template=replicated"
> 2. Execute merge into query:
> MERGE INTO USERPUBSTATICDATA(BOOK, DESK, TRADERS, REGION, LOB, EXCLUDE, 
> TRANSIT, MAPBOOKTOTHISBOOK) VALUES('CADOIS', 'FRT TOR', 'Robin Das/Dave 
> Carlson', 'Toronto', 'FRT', null, null, 'CADOIS');
> Step 2 is successfull on Web Console and called on IgniteCache from the 
> server node, but fails when called from the Ignite client node with exception:
> {code}
> javax.cache.CacheException: Invalid column name in KEYS clause of MERGE - it 
> may include only key and/or affinity columns: BOOK
> {code}



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


[jira] [Commented] (IGNITE-12665) SQL: Potential race on MapResult close.

2020-02-13 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12665:
---

[~amashenkov], the patch is OK with me.

> SQL: Potential race on MapResult close.
> ---
>
> Key: IGNITE-12665
> URL: https://issues.apache.org/jira/browse/IGNITE-12665
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: refactoring
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Seems, a race possible on MapQueryResult*s*.close() as this code can be 
> called twice.
> Let's rewrite it make sure every map result is closed via 
> MapQueryResult*s*.closeResult(int) method only.
> Then allow cleanup once all map results are closed.
> Then MapQueryResult*s*.allClosed() can be optimized as we always know number 
> of map results and all map results are closed via MapQueryResult*s* instance.
> Seems, MepQueryExecutor.onQueryRequest0() has dead code. See 
> "res.openResult(rs)" call when 'null' passed as argument.
>  
> Start point is MapQueryResult.openResult(res). 
>  



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


[jira] [Commented] (IGNITE-12609) SQL: GridReduceQueryExecutor refactoring.

2020-02-11 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12609:
---

[~amashenkov], the patch is OK with me.

> SQL: GridReduceQueryExecutor refactoring.
> -
>
> Key: IGNITE-12609
> URL: https://issues.apache.org/jira/browse/IGNITE-12609
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: refactoring
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For now we have few issues that can be resolved.
> 1. We create fake H2 tables\indices for reduce stage even if there is no need 
> to do so (skipMergeTable=true.
> Let's decouple reduce logic from H2Index adapter code.
> 2. Partition mapping code look to complicated and non-optimal.
> Let's use cached affinity mapping and avoid collections copying when possible.
> 3. Also there is no sense to pass RequestID to mapping code just for logging.
> We'll never be able to match any request as no query really exists at a time 
> when error with RequestID is logged.
> 4. Replicated only flag value semantic (calculation and usage) is not clear.
> 5. GridReduceQueryExecutor.reduce() method is too long (over 400 lines).



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


[jira] [Commented] (IGNITE-12590) MERGE INTO query is failing on Ignite client node

2020-02-11 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12590:
---

[~amashenkov], [~Pavlukhin] please review the patch.

> MERGE INTO query is failing on Ignite client node
> -
>
> Key: IGNITE-12590
> URL: https://issues.apache.org/jira/browse/IGNITE-12590
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Precondition: server nodes (any amount), webconsole is running.
> 1. Create the table as following:
> CREATE TABLE USERPUBSTATICDATA (BOOK VARCHAR, DESK VARCHAR, TRADERS VARCHAR, 
> REGION VARCHAR, LOB VARCHAR, EXCLUDE VARCHAR, TRANSIT VARCHAR, 
> MAPBOOKTOTHISBOOK VARCHAR, CONSTRAINT USERPUBSTATICDATA_PK PRIMARY KEY 
> (BOOK,DESK)) WITH "template=replicated"
> 2. Execute merge into query:
> MERGE INTO USERPUBSTATICDATA(BOOK, DESK, TRADERS, REGION, LOB, EXCLUDE, 
> TRANSIT, MAPBOOKTOTHISBOOK) VALUES('CADOIS', 'FRT TOR', 'Robin Das/Dave 
> Carlson', 'Toronto', 'FRT', null, null, 'CADOIS');
> Step 2 is successfull on Web Console and called on IgniteCache from the 
> server node, but fails when called from the Ignite client node with exception:
> {code}
> javax.cache.CacheException: Invalid column name in KEYS clause of MERGE - it 
> may include only key and/or affinity columns: BOOK
> {code}



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


[jira] [Commented] (IGNITE-11798) Memory leak on unstable topology caused by partition reservation

2020-01-29 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-11798:
---

[~amashenkov], that's right.
We must to check reservations map on each exchange because 
lastAffinityChangedTopologyVersion may return current version instead of really 
last changed version *when exchange isn't done*.
So. reservation map may contain any older versions which is added when query 
request is processed.


> Memory leak on unstable topology caused by partition reservation
> 
>
> Key: IGNITE-11798
> URL: https://issues.apache.org/jira/browse/IGNITE-11798
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Affects Versions: 2.7
>Reporter: Pavel Vinokurov
>Assignee: Taras Ledkov
>Priority: Major
> Attachments: PartitionReservationReproducer.java
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Executing queries on unstable topology leads to OOM caused by leak of  the 
> partition reservation.
> The reproducer is attached.



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


  1   2   3   4   5   6   7   8   9   10   >