[jira] [Comment Edited] (IGNITE-16098) Key type and schema must be validated on a data insertion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483637#comment-17483637
]
Taras Ledkov edited comment on IGNITE-16098 at 1/28/22, 8:22 AM:
-
Validation schema of the key object contains backward compatibility broken
changes because:
- when QueryEntity is created from real classes: {{new QueryEntity(MyKey.class,
MyValue.class)}}, because {{QueryEntityTypeDescriptor#keyProps}} not preserve
order.
- SQL INSERT not preserve order of the keyField on key object building;
- SQL INSERT now creates different schemas for
{{INSERT INTO T0 (ID0, VAL) VALUES (?, ?, ?)}}
and
{{INSERT INTO T0 (ID0, ID1, VAL) VALUES (?, ?, ?)}}
was (Author: tledkov-gridgain):
Validation schema of the key object contains backward compatibility broken
changes:
- when QueryEntity is created from real classes: {{new QueryEntity(MyKey.class,
MyValue.class)}}, because {{QueryEntityTypeDescriptor#keyProps}} not preserve
order.
- SQL INSERT not preserve order of the keyField on key object building;
- SQL INSERT now creates different schemas for
{{INSERT INTO T0 (ID0, VAL) VALUES (?, ?, ?)}}
and
{{INSERT INTO T0 (ID0, ID1, VAL) VALUES (?, ?, ?)}}
> Key type and schema must be validated on a data insertion
> -
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are two cases that break the consistency between indexes and data and
> can cause the index tree to break.
> *1. Put different entities that are logically same for SQL*
> {{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int, PRIMARY KEY (ID0, ID1)) WITH
> "KEY_TYPE=MyType,CACHE_NAME=test"}};
> then create to keys with hidden field and put to cache test.
> {code}
> BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 0);
> BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 1);
> {code}
> These key object are different by hidden field and cache will contains two
> entries.
> But (ID0, ID1) fields are same and sorted PK index will contain only one
> record.
> Now this case is applied only for SQL CREATE TABLE and cannot be reproduced
> via cache API.
> Because PK fields are unwrap only for SQL tables.
> Different functions of the cache API and SQL API should be fixed by
> IGNITE-11402.
> It should be possible to create identical tables by SQL and cache API.
> *2. Object with different key types*
> Now the value type is specify the table. If the value type doesn't not equal
> to value type specified by the {{QueryEntity#valueType}} the entity is not
> indexed (not applied fr the table).
> But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
> fields of inserted entry are validated.
> Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
> different types. Such insertion produce critical error.
> But this property is set up on the first insertion on the node locally.
> So, the steps to fail:
> 1. Put key with type "Key0" on the one node - OK;
> 2. Put key with type "Key1" on the other node - OK;
> 3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
> build index);
> *Suggestion fix:*
> 1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the second case);
> 2. *Before* table creation register {{BinaryMetadata}} for specified key type;
> 3. If the type corresponding for KEY is already registered and schemas differ
> - fail the table creation;
> 3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
> cluster-wide propagation and store at the persistence configuration;
> 4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the first case)
> 5. Introduce distributed property to disable these validation for backward
> compatibility.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483629#comment-17483629 ] Ivan Daschinsky commented on IGNITE-16359: -- [^check_odbc.py] Issue proved. Checked on apache ignite 2.9.1 with protocol 2.7.0 ODBC driver 2.9.1 -- works ODBC driver since 2.10.0 and master -- set streaming failed. Checked on pyodbc 4.0.32 and python 3.9.9, reproducer attached [~isapego] Could you please take a look? > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.12, 2.11.1 >Reporter: Abhay >Priority: Major > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-16098) Key type and schema must be validated on a data insertion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483637#comment-17483637
]
Taras Ledkov edited comment on IGNITE-16098 at 1/28/22, 8:23 AM:
-
Validation schema of the key object contains backward compatibility broken
changes because:
- when QueryEntity is created from real classes: {{new QueryEntity(MyKey.class,
MyValue.class)}}, {{QueryEntityTypeDescriptor#keyProps}} not preserve fields
order of the MyKey class.
- SQL INSERT not preserve order of the keyField on key object building;
- SQL INSERT now creates different schemas for
{{INSERT INTO T0 (ID0, VAL) VALUES (?, ?, ?)}}
and
{{INSERT INTO T0 (ID0, ID1, VAL) VALUES (?, ?, ?)}}
was (Author: tledkov-gridgain):
Validation schema of the key object contains backward compatibility broken
changes because:
- when QueryEntity is created from real classes: {{new QueryEntity(MyKey.class,
MyValue.class)}}, because {{QueryEntityTypeDescriptor#keyProps}} not preserve
order.
- SQL INSERT not preserve order of the keyField on key object building;
- SQL INSERT now creates different schemas for
{{INSERT INTO T0 (ID0, VAL) VALUES (?, ?, ?)}}
and
{{INSERT INTO T0 (ID0, ID1, VAL) VALUES (?, ?, ?)}}
> Key type and schema must be validated on a data insertion
> -
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are two cases that break the consistency between indexes and data and
> can cause the index tree to break.
> *1. Put different entities that are logically same for SQL*
> {{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int, PRIMARY KEY (ID0, ID1)) WITH
> "KEY_TYPE=MyType,CACHE_NAME=test"}};
> then create to keys with hidden field and put to cache test.
> {code}
> BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 0);
> BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 1);
> {code}
> These key object are different by hidden field and cache will contains two
> entries.
> But (ID0, ID1) fields are same and sorted PK index will contain only one
> record.
> Now this case is applied only for SQL CREATE TABLE and cannot be reproduced
> via cache API.
> Because PK fields are unwrap only for SQL tables.
> Different functions of the cache API and SQL API should be fixed by
> IGNITE-11402.
> It should be possible to create identical tables by SQL and cache API.
> *2. Object with different key types*
> Now the value type is specify the table. If the value type doesn't not equal
> to value type specified by the {{QueryEntity#valueType}} the entity is not
> indexed (not applied fr the table).
> But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
> fields of inserted entry are validated.
> Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
> different types. Such insertion produce critical error.
> But this property is set up on the first insertion on the node locally.
> So, the steps to fail:
> 1. Put key with type "Key0" on the one node - OK;
> 2. Put key with type "Key1" on the other node - OK;
> 3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
> build index);
> *Suggestion fix:*
> 1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the second case);
> 2. *Before* table creation register {{BinaryMetadata}} for specified key type;
> 3. If the type corresponding for KEY is already registered and schemas differ
> - fail the table creation;
> 3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
> cluster-wide propagation and store at the persistence configuration;
> 4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the first case)
> 5. Introduce distributed property to disable these validation for backward
> compatibility.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-16359: - Attachment: check_odbc.py > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.12, 2.11.1 >Reporter: Abhay >Priority: Major > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483629#comment-17483629 ] Ivan Daschinsky edited comment on IGNITE-16359 at 1/28/22, 8:08 AM: [^check_odbc.py] Issue proved. Checked on apache ignite 2.9.1 with protocol 2.7.0 ODBC driver 2.9.1 -- works ODBC driver since 2.10.0 and master -- set streaming failed. May be this ticket introduce this behaviour IGNITE-12126? Checked on pyodbc 4.0.32 and python 3.9.9, reproducer attached [~isapego] Could you please take a look? was (Author: ivandasch): [^check_odbc.py] Issue proved. Checked on apache ignite 2.9.1 with protocol 2.7.0 ODBC driver 2.9.1 -- works ODBC driver since 2.10.0 and master -- set streaming failed. Checked on pyodbc 4.0.32 and python 3.9.9, reproducer attached [~isapego] Could you please take a look? > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.12, 2.11.1 >Reporter: Abhay >Priority: Major > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16098) Key type and schema must be validated on a data insertion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483637#comment-17483637
]
Taras Ledkov commented on IGNITE-16098:
---
Validation schema of the key object contains backward compatibility broken
changes:
- when QueryEntity is created from real classes: {{new QueryEntity(MyKey.class,
MyValue.class)}}, because {{QueryEntityTypeDescriptor#keyProps}} not preserve
order.
- SQL INSERT not preserve order of the keyField on key object building;
- SQL INSERT now creates different schemas for
{{INSERT INTO T0 (ID0, VAL) VALUES (?, ?, ?)}}
and
{{INSERT INTO T0 (ID0, ID1, VAL) VALUES (?, ?, ?)}}
> Key type and schema must be validated on a data insertion
> -
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are two cases that break the consistency between indexes and data and
> can cause the index tree to break.
> *1. Put different entities that are logically same for SQL*
> {{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int, PRIMARY KEY (ID0, ID1)) WITH
> "KEY_TYPE=MyType,CACHE_NAME=test"}};
> then create to keys with hidden field and put to cache test.
> {code}
> BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 0);
> BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 1);
> {code}
> These key object are different by hidden field and cache will contains two
> entries.
> But (ID0, ID1) fields are same and sorted PK index will contain only one
> record.
> Now this case is applied only for SQL CREATE TABLE and cannot be reproduced
> via cache API.
> Because PK fields are unwrap only for SQL tables.
> Different functions of the cache API and SQL API should be fixed by
> IGNITE-11402.
> It should be possible to create identical tables by SQL and cache API.
> *2. Object with different key types*
> Now the value type is specify the table. If the value type doesn't not equal
> to value type specified by the {{QueryEntity#valueType}} the entity is not
> indexed (not applied fr the table).
> But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
> fields of inserted entry are validated.
> Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
> different types. Such insertion produce critical error.
> But this property is set up on the first insertion on the node locally.
> So, the steps to fail:
> 1. Put key with type "Key0" on the one node - OK;
> 2. Put key with type "Key1" on the other node - OK;
> 3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
> build index);
> *Suggestion fix:*
> 1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the second case);
> 2. *Before* table creation register {{BinaryMetadata}} for specified key type;
> 3. If the type corresponding for KEY is already registered and schemas differ
> - fail the table creation;
> 3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
> cluster-wide propagation and store at the persistence configuration;
> 4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the first case)
> 5. Introduce distributed property to disable these validation for backward
> compatibility.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-16359: - Affects Version/s: 2.10 2.10.1 > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.10, 2.10.1, 2.12, 2.11.1 >Reporter: Abhay >Priority: Major > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-16359: - Affects Version/s: 2.11 > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.10, 2.11, 2.10.1, 2.12, 2.11.1 >Reporter: Abhay >Priority: Major > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-16359: - Affects Version/s: (was: 2.10.1) > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.10, 2.11, 2.12, 2.11.1 >Reporter: Abhay >Priority: Major > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16341) .NET: Thin 3.0: Emit efficient POCO serialization code
[ https://issues.apache.org/jira/browse/IGNITE-16341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-16341: Description: Initial POCO serialization (IGNITE-16227) uses a simple but inefficient reflection API. * Use *Reflection.Emit* to compile efficient POCO serialization code for user types. * Use fields instead of properties to support read-only classes, records, and so on. * Update XMLDoc for *ITable.GetRecordView* and explain how the mapping works. was: Initial POCO serialization (IGNITE-16227) uses a simple but inefficient reflection API. * Use *Reflection.Emit* to compile efficient POCO serialization code for user types. * Use fields instead of properties to support read-only classes, records, and so on. * Update XMLDoc for *ITable.GetRecordView* and explain how the mapping works. * Consider a way to provide custom column names for mapped classes - attributes or converters (separate ticket?) > .NET: Thin 3.0: Emit efficient POCO serialization code > -- > > Key: IGNITE-16341 > URL: https://issues.apache.org/jira/browse/IGNITE-16341 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-alpha5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-alpha5 > > > Initial POCO serialization (IGNITE-16227) uses a simple but inefficient > reflection API. > * Use *Reflection.Emit* to compile efficient POCO serialization code for user > types. > * Use fields instead of properties to support read-only classes, records, and > so on. > * Update XMLDoc for *ITable.GetRecordView* and explain how the mapping works. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16389) Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop
[ https://issues.apache.org/jira/browse/IGNITE-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483706#comment-17483706 ] Evgeny Stanilovsky commented on IGNITE-16389: - [~vermakov], [~tledkov-gridgain] fix ready for review. > Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop > - > > Key: IGNITE-16389 > URL: https://issues.apache.org/jira/browse/IGNITE-16389 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Assignee: Evgeny Stanilovsky >Priority: Blocker > Labels: ignite-3 > Attachments: image (1).png > > > Test > org.apache.ignite.internal.sql.engine.StopCalciteModuleTest#testStopQueryOnNodeStop > is flacky. To reproduce: repeat the test until NPE appears. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15330) Read Repair should support strategies
[
https://issues.apache.org/jira/browse/IGNITE-15330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483724#comment-17483724
]
Anton Vinogradov commented on IGNITE-15330:
---
Merged to the master.
[~timonin.maksim], thanks for the review!
> Read Repair should support strategies
> -
>
> Key: IGNITE-15330
> URL: https://issues.apache.org/jira/browse/IGNITE-15330
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.13
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> Possible strategies:
> {noformat}
> LWW, // Currently implemented
> PRIMARY,
> MAJORITY,
> REMOVE,
> CHECK_ONLY;
> {noformat}
> The strategy should not fix entries when impossible, eg LWW when versions are
> the same but values differ.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16421) Wrap_key doesn't work with custom value_type
Yury Gerzhedovich created IGNITE-16421:
--
Summary: Wrap_key doesn't work with custom value_type
Key: IGNITE-16421
URL: https://issues.apache.org/jira/browse/IGNITE-16421
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
Assignee: Yury Gerzhedovich
Steps to reproduce:
1. Create a table
{{1CREATE TABLE City (2 name varchar primary key,3 code int4) WITH
"wrap_key=true,value_type=org.apache.ignite.internal.processors.cache.index.CodeType";}}
2. Put something with cache API
{{1cache.put("123", new CodeType(1));}}
3. [Expected] Entity is put correctly
4. [Actual] Unexcepted binary object class
{{1class org.apache.ignite.IgniteCheckedException: Unexpected binary object
class [type=class
org.apache.ignite.internal.processors.cache.KeyCacheObjectImpl]2
at
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:127)3
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:244)}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16421) Wrap_key doesn't work with custom value_type
[
https://issues.apache.org/jira/browse/IGNITE-16421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-16421:
---
Description:
Steps to reproduce:
1. Create a table
{{}}
{code:java}
{code}
{{CREATE TABLE City (}}
{{ name varchar primary key,}}
{{ code int}}
{{) WITH
"wrap_key=true,value_type=org.apache.ignite.internal.processors.cache.index.CodeType";}}
2. Put something with cache API
{{}}
{code:java}
{code}
{{cache.put("123", new CodeType(1));}}
3. [Expected] Entity is put correctly
4. [Actual] Unexcepted binary object class
{code:java}
class org.apache.ignite.IgniteCheckedException: Unexpected binary object class
[type=class org.apache.ignite.internal.processors.cache.KeyCacheObjectImpl]
at
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:127)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:244)(({code}
was:
Steps to reproduce:
1. Create a table
{{1CREATE TABLE City (2 name varchar primary key,3 code int4) WITH
"wrap_key=true,value_type=org.apache.ignite.internal.processors.cache.index.CodeType";}}
2. Put something with cache API
{{1cache.put("123", new CodeType(1));}}
3. [Expected] Entity is put correctly
4. [Actual] Unexcepted binary object class
{{1class org.apache.ignite.IgniteCheckedException: Unexpected binary object
class [type=class
org.apache.ignite.internal.processors.cache.KeyCacheObjectImpl]2
at
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:127)3
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:244)}}
> Wrap_key doesn't work with custom value_type
>
>
> Key: IGNITE-16421
> URL: https://issues.apache.org/jira/browse/IGNITE-16421
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>
> Steps to reproduce:
> 1. Create a table
> {{}}
> {code:java}
> {code}
> {{CREATE TABLE City (}}
> {{ name varchar primary key,}}
> {{ code int}}
> {{) WITH
> "wrap_key=true,value_type=org.apache.ignite.internal.processors.cache.index.CodeType";}}
> 2. Put something with cache API
> {{}}
> {code:java}
> {code}
> {{cache.put("123", new CodeType(1));}}
> 3. [Expected] Entity is put correctly
> 4. [Actual] Unexcepted binary object class
>
> {code:java}
> class org.apache.ignite.IgniteCheckedException: Unexpected binary object
> class [type=class
> org.apache.ignite.internal.processors.cache.KeyCacheObjectImpl]
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:127)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:244)(({code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16341) .NET: Thin 3.0: Emit efficient POCO serialization code
[ https://issues.apache.org/jira/browse/IGNITE-16341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483717#comment-17483717 ] Igor Sapego commented on IGNITE-16341: -- [~ptupitsyn] looks good to me. > .NET: Thin 3.0: Emit efficient POCO serialization code > -- > > Key: IGNITE-16341 > URL: https://issues.apache.org/jira/browse/IGNITE-16341 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-alpha5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > Initial POCO serialization (IGNITE-16227) uses a simple but inefficient > reflection API. > * Use *Reflection.Emit* to compile efficient POCO serialization code for user > types. > * Use fields instead of properties to support read-only classes, records, and > so on. > * Update XMLDoc for *ITable.GetRecordView* and explain how the mapping works. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16424) Generate test data in several threads in DataGenerationApplication
Sergey Korotkov created IGNITE-16424: Summary: Generate test data in several threads in DataGenerationApplication Key: IGNITE-16424 URL: https://issues.apache.org/jira/browse/IGNITE-16424 Project: Ignite Issue Type: Improvement Reporter: Sergey Korotkov Assignee: Sergey Korotkov DataGenerationApplication app is used to fill ignite cluster with test data. Now It accepts as parameters: * number of caches to create * number of entries to put to each cache (interval of integer keys in fact) * size of each cache entry * number of backup partitions for caches created Currently application creates and fills caches one by one in one thread. For huge caches it is a very time-consuming operation. On the other hand it's known that the parallell load in several threads via the Ignite Streamer works fine and can speed up the process significantly. It's also known that such parallell operations are very heap-memory intensive. Special attention should be paid to this issue. --- So, the tasks looks like: # Modify the DataGenerationApplication as it would load data in several threads. It should accept new integer parameter: _*threads*_ (1 by default) and use this number of threads to load data trying to spread work evenly between them. # Try to figure out some heuristic of the dependence of the required heap memory on the number of threads, caches and data size. It may require to implement some tool to get actual heap usage metrics from DataGenerationApplication after test run. # Implement this heuristic in python (to start DataGenerationApplication with the appropriate heap memory JVM options) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16422) Calcite: ArrayOutOfBoundException on row update
[ https://issues.apache.org/jira/browse/IGNITE-16422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16422: -- Description: After IGNITE-16296 new bug with row update logic is appeared. To reproduce run ItJdbcStatementSelfTest#testExecuteUpdate(). > Calcite: ArrayOutOfBoundException on row update > --- > > Key: IGNITE-16422 > URL: https://issues.apache.org/jira/browse/IGNITE-16422 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Critical > Labels: ignite-3 > > After IGNITE-16296 new bug with row update logic is appeared. > To reproduce run ItJdbcStatementSelfTest#testExecuteUpdate(). > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16424) Generate test data in several threads in DataGenerationApplication
[ https://issues.apache.org/jira/browse/IGNITE-16424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483726#comment-17483726 ] Sergey Korotkov commented on IGNITE-16424: -- [~NIzhikov] would you please review the description > Generate test data in several threads in DataGenerationApplication > -- > > Key: IGNITE-16424 > URL: https://issues.apache.org/jira/browse/IGNITE-16424 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > > DataGenerationApplication app is used to fill ignite cluster with test data. > Now It accepts as parameters: > * number of caches to create > * number of entries to put to each cache (interval of integer keys in fact) > * size of each cache entry > * number of backup partitions for caches created > Currently application creates and fills caches one by one in one thread. For > huge caches it is a very time-consuming operation. On the other hand it's > known that the parallell load in several threads via the Ignite Streamer > works fine and can speed up the process significantly. > It's also known that such parallell operations are very heap-memory > intensive. Special attention should be paid to this issue. > --- > So, the tasks looks like: > # Modify the DataGenerationApplication as it would load data in several > threads. It should accept new integer parameter: _*threads*_ (1 by default) > and use this number of threads to load data trying to spread work evenly > between them. > # Try to figure out some heuristic of the dependence of the required heap > memory on the number of threads, caches and data size. It may require to > implement some tool to get actual heap usage metrics from > DataGenerationApplication after test run. > # Implement this heuristic in python (to start DataGenerationApplication > with the appropriate heap memory JVM options) > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14925) Sorted indexes engine
[ https://issues.apache.org/jira/browse/IGNITE-14925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-14925: -- Description: The umbrella ticket to track improvements and issues related to design and development sorted index engine for Ignite 3.0. Feature branch: [ignite-14925-sorted-indexes|https://github.com/apache/ignite-3/tree/ignite-14925-sorted-indexes] was:The umbrella ticket to track improvements and issues related to design and development sorted index engine for Ignite 3.0. > Sorted indexes engine > - > > Key: IGNITE-14925 > URL: https://issues.apache.org/jira/browse/IGNITE-14925 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Taras Ledkov >Priority: Major > Labels: ignite-3 > > The umbrella ticket to track improvements and issues related to design and > development sorted index engine for Ignite 3.0. > Feature branch: > [ignite-14925-sorted-indexes|https://github.com/apache/ignite-3/tree/ignite-14925-sorted-indexes] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16422) Calcite: ArrayOutOfBoundException on row update
[ https://issues.apache.org/jira/browse/IGNITE-16422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16422: -- Priority: Critical (was: Major) > Calcite: ArrayOutOfBoundException on row update > --- > > Key: IGNITE-16422 > URL: https://issues.apache.org/jira/browse/IGNITE-16422 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Critical > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16115) Implement getNullable and getOrDefault operations.
[
https://issues.apache.org/jira/browse/IGNITE-16115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483712#comment-17483712
]
Andrey Mashenkov commented on IGNITE-16115:
---
[~agura] done.
> Implement getNullable and getOrDefault operations.
> --
>
> Key: IGNITE-16115
> URL: https://issues.apache.org/jira/browse/IGNITE-16115
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> It is allowed to map an object to a single nullable column, which makes
> 'null' values legal in the KeyValue view.
> Once the 'null' value is possible there is no way to distinguish, if there is
> no row in a table for the given key, or the row exists and the mapped column
> contains the 'null' value.
> Let's introduce {{NullableValue}} class-wrapper for a value and implement
> {{{}getNullable(){}}}, and {{getOrDefault()}} + bulk methods.
> {{getNullable()}} is useful for cases, when it's not possible to use a
> "default", but creates an additional wrapper.
> Also, the KeyValueView.get(key) method behavior should be changed:
> * return {{null}} if the table has no row for the key.
> * return a non-null value for the key.
> * fail with a suggestion to use a getNullable, if a {{null}} value returned
> for the key to avoid ambiguity.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16405) NoClassDefFound on invokeAsync when using BinaryObjects.
[
https://issues.apache.org/jira/browse/IGNITE-16405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483713#comment-17483713
]
Ignite TC Bot commented on IGNITE-16405:
{panel:title=Branch: [pull/9772/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9772/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6388903]]
* {color:#013220}IgniteBinaryCacheTestSuite:
IgniteCacheManyAsyncOperationsTest.testInvokeAsyncWithKeepBinary - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6388974buildTypeId=IgniteTests24Java8_RunAll]
> NoClassDefFound on invokeAsync when using BinaryObjects.
>
>
> Key: IGNITE-16405
> URL: https://issues.apache.org/jira/browse/IGNITE-16405
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Attachments: stacktrace.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Tx cache async operation may fail with an error on retry in case when the
> binary projection is used.
> This happens due to the lost CacheOperationContext, which holds 'keepBinary'
> flag, on retry and leads to object deserialization when TX is trying to
> enlist en entry.
> PFA stacktrace.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16375) GridAbstractTest.startClientGrid() method does not guarantee that started node will be the client
[
https://issues.apache.org/jira/browse/IGNITE-16375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483745#comment-17483745
]
Anton Vinogradov commented on IGNITE-16375:
---
It seems to be a broken test case when the configuration has explicit server
mode, instead of null and we're trying to start it as a client.
That's not a huge problem, but we have weak logic here.
And client nodes may be unexpected at abstract test (where configuration is
set) while used at implementation.
Setting client mode at configuration you setting the contract it always server
or client.
Otherwise, you must keep it null (default) or set it only when necessary.
{code:java}
cfg.setClientMode(false); // Bad code when client nodes starts are expected
{code}
Once again, that's not a severe issue, in contrast to startClientGrid(name)
behavior, but ... let's keep the same contract here.
> GridAbstractTest.startClientGrid() method does not guarantee that started
> node will be the client
> -
>
> Key: IGNITE-16375
> URL: https://issues.apache.org/jira/browse/IGNITE-16375
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Sergey Korotkov
>Priority: Major
> Labels: newbie
> Attachments: Client_node_start_failed_reproducer.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If {{cfg.setClientMode(false)}} was applied to the Ignite configuration,
> {{GridAbstractTest.startClientGrid()}} will start the server node, while
> client node is expected according to the method name and JavaDoc.
> {noformat}
> Starts new client grid with given index.
> {noformat}
> {{GridAbstractTest.startClientGrid()}} should start client node even when
> {{cfg.setClientMode(false)}} is set or throw an exception (preferred).
> See reproducer at [^Client_node_start_failed_reproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16422) Calcite: ArrayOutOfBoundException on row update
Vladimir Ermakov created IGNITE-16422: - Summary: Calcite: ArrayOutOfBoundException on row update Key: IGNITE-16422 URL: https://issues.apache.org/jira/browse/IGNITE-16422 Project: Ignite Issue Type: Bug Components: sql Reporter: Vladimir Ermakov Assignee: Vladimir Ermakov -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16421) Wrap_key doesn't work with custom value_type
[
https://issues.apache.org/jira/browse/IGNITE-16421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-16421:
---
Description:
Steps to reproduce:
1. Create a table
{code:java}
CREATE TABLE City (
name varchar primary key,
code int
) WITH
"wrap_key=true,value_type=org.apache.ignite.internal.processors.cache.index.CodeType";{code}
2. Put something with cache API
{code:java}
cache.put("123", new CodeType(1));{code}
3. [Expected] Entity is put correctly
4. [Actual] Unexcepted binary object class
{code:java}
class org.apache.ignite.IgniteCheckedException: Unexpected binary object class
[type=class org.apache.ignite.internal.processors.cache.KeyCacheObjectImpl]
at
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:127)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:244)(({code}
was:
Steps to reproduce:
1. Create a table
{{}}
{code:java}
{code}
{{CREATE TABLE City (}}
{{ name varchar primary key,}}
{{ code int}}
{{) WITH
"wrap_key=true,value_type=org.apache.ignite.internal.processors.cache.index.CodeType";}}
2. Put something with cache API
{{}}
{code:java}
{code}
{{cache.put("123", new CodeType(1));}}
3. [Expected] Entity is put correctly
4. [Actual] Unexcepted binary object class
{code:java}
class org.apache.ignite.IgniteCheckedException: Unexpected binary object class
[type=class org.apache.ignite.internal.processors.cache.KeyCacheObjectImpl]
at
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:127)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:244)(({code}
> Wrap_key doesn't work with custom value_type
>
>
> Key: IGNITE-16421
> URL: https://issues.apache.org/jira/browse/IGNITE-16421
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>
> Steps to reproduce:
> 1. Create a table
> {code:java}
> CREATE TABLE City (
> name varchar primary key,
> code int
> ) WITH
> "wrap_key=true,value_type=org.apache.ignite.internal.processors.cache.index.CodeType";{code}
> 2. Put something with cache API
> {code:java}
> cache.put("123", new CodeType(1));{code}
> 3. [Expected] Entity is put correctly
> 4. [Actual] Unexcepted binary object class
>
> {code:java}
> class org.apache.ignite.IgniteCheckedException: Unexpected binary object
> class [type=class
> org.apache.ignite.internal.processors.cache.KeyCacheObjectImpl]
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:127)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:244)(({code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15431) .NET: Thin 3.0: Custom data types support
[ https://issues.apache.org/jira/browse/IGNITE-15431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-15431: Description: Add support for all data types in .NET thin client: Date, Time, etc - see org.apache.ignite.client.proto.ClientDataType (was: Add support all data types: Date, Time, etc - see org.apache.ignite.client.proto.ClientDataType) > .NET: Thin 3.0: Custom data types support > - > > Key: IGNITE-15431 > URL: https://issues.apache.org/jira/browse/IGNITE-15431 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-alpha3 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-78, ignite-3 > > Add support for all data types in .NET thin client: Date, Time, etc - see > org.apache.ignite.client.proto.ClientDataType -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16422) Calcite: ArrayOutOfBoundException on row update
[ https://issues.apache.org/jira/browse/IGNITE-16422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-16422: --- Priority: Blocker (was: Critical) > Calcite: ArrayOutOfBoundException on row update > --- > > Key: IGNITE-16422 > URL: https://issues.apache.org/jira/browse/IGNITE-16422 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Blocker > Labels: ignite-3 > > After IGNITE-16296 new bug with row update logic is appeared. > To reproduce run ItJdbcStatementSelfTest#testExecuteUpdate(). > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16341) .NET: Thin 3.0: Emit efficient POCO serialization code
[ https://issues.apache.org/jira/browse/IGNITE-16341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483736#comment-17483736 ] Pavel Tupitsyn commented on IGNITE-16341: - Merged to main: 34d7af9a97d69461e6bdf344dc24069dd5ee6112 > .NET: Thin 3.0: Emit efficient POCO serialization code > -- > > Key: IGNITE-16341 > URL: https://issues.apache.org/jira/browse/IGNITE-16341 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-alpha5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Initial POCO serialization (IGNITE-16227) uses a simple but inefficient > reflection API. > * Use *Reflection.Emit* to compile efficient POCO serialization code for user > types. > * Use fields instead of properties to support read-only classes, records, and > so on. > * Update XMLDoc for *ITable.GetRecordView* and explain how the mapping works. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16389) Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop
[ https://issues.apache.org/jira/browse/IGNITE-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-16389: --- Assignee: Evgeny Stanilovsky > Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop > - > > Key: IGNITE-16389 > URL: https://issues.apache.org/jira/browse/IGNITE-16389 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Assignee: Evgeny Stanilovsky >Priority: Blocker > Labels: ignite-3 > Attachments: image (1).png > > > Test > org.apache.ignite.internal.sql.engine.StopCalciteModuleTest#testStopQueryOnNodeStop > is flacky. To reproduce: repeat the test until NPE appears. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16423) [%my-first-node%JRaft-Common-Executor-1][SnapshotExecutorImpl] Fail to close writer
Fedor Malchikov created IGNITE-16423:
-
Summary:
[%my-first-node%JRaft-Common-Executor-1][SnapshotExecutorImpl] Fail to close
writer
Key: IGNITE-16423
URL: https://issues.apache.org/jira/browse/IGNITE-16423
Project: Ignite
Issue Type: Bug
Affects Versions: 3.0.0-alpha3
Reporter: Fedor Malchikov
Attachments: my-first-node(sql).log, my-first-node.log
{code:java}
2022-01-28 13:17:41:192 +0300
[ERROR][%my-first-node%JRaft-Common-Executor-1][SnapshotExecutorImpl] Fail to
close writerjava.io.IOExceptionat
org.apache.ignite.raft.jraft.storage.snapshot.local.LocalSnapshotStorage.close(LocalSnapshotStorage.java:242)
at
org.apache.ignite.raft.jraft.storage.snapshot.local.LocalSnapshotWriter.close(LocalSnapshotWriter.java:93)
at
org.apache.ignite.raft.jraft.storage.snapshot.local.LocalSnapshotWriter.close(LocalSnapshotWriter.java:88)
at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl.onSnapshotSaveDone(SnapshotExecutorImpl.java:387)
at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl$SaveSnapshotDone.continueRun(SnapshotExecutorImpl.java:135)
at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl$SaveSnapshotDone.lambda$run$0(SnapshotExecutorImpl.java:131)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)2022-01-28 13:17:41:202
+0300
[ERROR][%my-first-node%JRaft-FSMCaller-Disruptor-_stripe_10-0][StateMachineAdapter]
Encountered an error=Status[EIO<1014>: Fail to save snapshot.] on StateMachine
org.apache.ignite.internal.raft.server.impl.JraftServerImpl$DelegatingStateMachine,
it's highly recommended to implement this method as raft stops working since
some error occurs, you should figure out the cause and repair or remove this
node.Error [type=ERROR_TYPE_SNAPSHOT, status=Status[EIO<1014>: Fail to save
snapshot.]]at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl.reportError(SnapshotExecutorImpl.java:682)
at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl.onSnapshotSaveDone(SnapshotExecutorImpl.java:406)
at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl$SaveSnapshotDone.continueRun(SnapshotExecutorImpl.java:135)
at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl$SaveSnapshotDone.lambda$run$0(SnapshotExecutorImpl.java:131)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)2022-01-28 13:17:41:203
+0300
[WARNING][%my-first-node%JRaft-FSMCaller-Disruptor-_stripe_10-0][NodeImpl] Node
got error: Error
[type=ERROR_TYPE_SNAPSHOT, status=Status[EIO<1014>: Fail to save
snapshot.]].2022-01-28 13:17:41:203 +0300
[WARNING][%my-first-node%JRaft-FSMCaller-Disruptor-_stripe_10-0][FSMCallerImpl]
FSMCaller already in error status, ignore new errorError
[type=ERROR_TYPE_SNAPSHOT, status=Status[EIO<1014>: Fail to save snapshot.]]
at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl.reportError(SnapshotExecutorImpl.java:682)
at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl.onSnapshotSaveDone(SnapshotExecutorImpl.java:406)
at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl$SaveSnapshotDone.continueRun(SnapshotExecutorImpl.java:135)
at
org.apache.ignite.raft.jraft.storage.snapshot.SnapshotExecutorImpl$SaveSnapshotDone.lambda$run$0(SnapshotExecutorImpl.java:131)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)2022-01-28 13:17:41:205
+0300
[INFO][%my-first-node%JRaft-FSMCaller-Disruptor-_stripe_10-0][ReplicatorGroupImpl]
Fail to find the next candidate.2022-01-28 13:17:41:205 +0300
[INFO][%my-first-node%JRaft-FSMCaller-Disruptor-_stripe_10-0][StateMachineAdapter]
onLeaderStop: status=Status[EBADNODE<10009>: Raft node(leader or candidate) is
in error.].2022-01-28 13:17:51:262 +0300
[ERROR][Thread-72][MetaStorageServiceImpl] Unexpected exceptionclass
org.apache.ignite.lang.IgniteInternalException:
java.util.concurrent.TimeoutExceptionat
org.apache.ignite.internal.metastorage.client.CursorImpl$InnerIterator.hasNext(CursorImpl.java:121)
at
org.apache.ignite.internal.metastorage.client.MetaStorageServiceImpl$WatchProcessor$Watcher.run(MetaStorageServiceImpl.java:476)Caused
by: java.util.concurrent.ExecutionException:
[jira] [Updated] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-16359: - Fix Version/s: 2.13 > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.10, 2.11, 2.12, 2.11.1 >Reporter: Abhay >Assignee: Ivan Daschinsky >Priority: Major > Fix For: 2.13 > > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-16359: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.10, 2.11, 2.12, 2.11.1 >Reporter: Abhay >Assignee: Ivan Daschinsky >Priority: Major > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14999) Support dynamic restoration of encrypted snapshots.
[ https://issues.apache.org/jira/browse/IGNITE-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14999: -- Description: After manual replacements of encrypted snapshots works, let's enable dynamic snapshot restoration (`SnapshotRestoreProcess`) Supposed new general features: * Dynamic restoration of encrypted snapshot on a running node ( `IgniteSnapshotManager#restoreSnapshot()` ) * Validation of encrypted snapshot ( `IgniteSnapshotManager#checkSnapshot()` ) Same master key is still required. NOTE: To restore an encrypted snapshot, we have to read the keys it was encrypted with. The better place for the is Metastore. But it is currently unreadable as a simple structure. This ticket suggests holding the keys in `StoredCacheData`. It always goes together with the data and is included in snapshot. was: After manual replacements of encrypted snapshots works, let's enable dynamic snapshot restoration (`SnapshotRestoreProcess`) Supposed new general features: * Dynamic restoration of encrypted snapshot on a running node ( `IgniteSnapshotManager#restoreSnapshot()` ) * Validation of encrypted snapshot ( `IgniteSnapshotManager#checkSnapshot()` ) Same master key is still required. > Support dynamic restoration of encrypted snapshots. > --- > > Key: IGNITE-14999 > URL: https://issues.apache.org/jira/browse/IGNITE-14999 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > After manual replacements of encrypted snapshots works, let's enable dynamic > snapshot restoration (`SnapshotRestoreProcess`) > Supposed new general features: > * Dynamic restoration of encrypted snapshot on a running node ( > `IgniteSnapshotManager#restoreSnapshot()` ) > * Validation of encrypted snapshot ( `IgniteSnapshotManager#checkSnapshot()` ) > Same master key is still required. > NOTE: > To restore an encrypted snapshot, we have to read the keys it was encrypted > with. The better place for the is Metastore. But it is currently unreadable > as a simple structure. This ticket suggests holding the keys in > `StoredCacheData`. It always goes together with the data and is included in > snapshot. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16405) NoClassDefFound on invokeAsync when using BinaryObjects.
[ https://issues.apache.org/jira/browse/IGNITE-16405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-16405: -- Fix Version/s: 2.13 > NoClassDefFound on invokeAsync when using BinaryObjects. > > > Key: IGNITE-16405 > URL: https://issues.apache.org/jira/browse/IGNITE-16405 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Fix For: 2.13 > > Attachments: stacktrace.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Tx cache async operation may fail with an error on retry in case when the > binary projection is used. > This happens due to the lost CacheOperationContext, which holds 'keepBinary' > flag, on retry and leads to object deserialization when TX is trying to > enlist en entry. > PFA stacktrace. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-14698) Investigate memory overhead for method ByteUtils.toBytes
[
https://issues.apache.org/jira/browse/IGNITE-14698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-14698:
--
Assignee: Ivan Bessonov
> Investigate memory overhead for method ByteUtils.toBytes
> -
>
> Key: IGNITE-14698
> URL: https://issues.apache.org/jira/browse/IGNITE-14698
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
>
> Investigate memory overhead when serializing using {{ByteUtils.toBytes}}.
> Currently
> {{ByteUtils.toBytes}} uses native java serialization mechanism.
> Seems that for int, long, double, boolean, string, arrays of above it could
> be optimized.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483819#comment-17483819 ] Ivan Daschinsky edited comment on IGNITE-16359 at 1/28/22, 3:22 PM: [~isapego] Could you please review my patch? was (Author: ivandasch): [~isapego] Could you please review my issues? > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.10, 2.11, 2.12, 2.11.1 >Reporter: Abhay >Assignee: Ivan Daschinsky >Priority: Major > Fix For: 2.13 > > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483819#comment-17483819 ] Ivan Daschinsky commented on IGNITE-16359: -- [~isapego] Could you please review my issues? > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.10, 2.11, 2.12, 2.11.1 >Reporter: Abhay >Assignee: Ivan Daschinsky >Priority: Major > Fix For: 2.13 > > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16425) Use effective direct access in TableManager#directTableId
[ https://issues.apache.org/jira/browse/IGNITE-16425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-16425: --- Summary: Use effective direct access in TableManager#directTableId (was: Use more effective serialization of configuration.) > Use effective direct access in TableManager#directTableId > - > > Key: IGNITE-16425 > URL: https://issues.apache.org/jira/browse/IGNITE-16425 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > More effective data format is required instead of default JDK serialization. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16425) Use effective direct access in TableManager#directTableId
[ https://issues.apache.org/jira/browse/IGNITE-16425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-16425: --- Epic Link: (was: IGNITE-14904) > Use effective direct access in TableManager#directTableId > - > > Key: IGNITE-16425 > URL: https://issues.apache.org/jira/browse/IGNITE-16425 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Current implementation reads too much data -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16425) Use effective direct access in TableManager#directTableId
[ https://issues.apache.org/jira/browse/IGNITE-16425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-16425: --- Description: Current implementation reads too much data (was: More effective data format is required instead of default JDK serialization.) > Use effective direct access in TableManager#directTableId > - > > Key: IGNITE-16425 > URL: https://issues.apache.org/jira/browse/IGNITE-16425 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Current implementation reads too much data -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16425) Use more effective serialization of configuration.
Ivan Bessonov created IGNITE-16425: -- Summary: Use more effective serialization of configuration. Key: IGNITE-16425 URL: https://issues.apache.org/jira/browse/IGNITE-16425 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Fix For: 3.0.0-alpha5 More effective data format is required instead of default JDK serialization. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16359) SET STREAMING ON/OFF not working
[
https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483817#comment-17483817
]
Ignite TC Bot commented on IGNITE-16359:
{panel:title=Branch: [pull/9778/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9778/head] Base: [master] : New Tests
(1038)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
1038|https://ci2.ignite.apache.org/viewLog.html?buildId=6287957]]
* {color:#013220}IgniteThinClientTest: CacheClientTestSuite:
CacheClientGetAndPutIfAbsentComplexKey - PASSED{color}
* {color:#013220}IgniteThinClientTest: ComputeClientTestSuite: EchoTaskNull -
PASSED{color}
* {color:#013220}IgniteThinClientTest: ComputeClientTestSuite:
EchoTaskPrimitives - PASSED{color}
* {color:#013220}IgniteThinClientTest: ComputeClientTestSuite: EchoTaskObject -
PASSED{color}
* {color:#013220}IgniteThinClientTest: ComputeClientTestSuite: EchoTaskGuid -
PASSED{color}
* {color:#013220}IgniteThinClientTest: ComputeClientTestSuite: TaskWithTimeout
- PASSED{color}
* {color:#013220}IgniteThinClientTest: ComputeClientTestSuite:
TaskWithNoFailover - PASSED{color}
* {color:#013220}IgniteThinClientTest: ComputeClientTestSuite:
TaskWithNoResultCache - PASSED{color}
* {color:#013220}IgniteThinClientTest: IgniteClientTestSuite:
IgniteClientConnection - PASSED{color}
* {color:#013220}IgniteThinClientTest: IgniteClientTestSuite:
IgniteClientConnectionFailover - PASSED{color}
* {color:#013220}IgniteThinClientTest: IgniteClientTestSuite:
IgniteClientConnectionLimit - PASSED{color}
... and 1027 new tests
{panel}
[TeamCity *- Run :: CPP*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6287961buildTypeId=IgniteTests24Java8_RunCpp]
> SET STREAMING ON/OFF not working
> -
>
> Key: IGNITE-16359
> URL: https://issues.apache.org/jira/browse/IGNITE-16359
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.10, 2.11, 2.12, 2.11.1
>Reporter: Abhay
>Assignee: Ivan Daschinsky
>Priority: Major
> Fix For: 2.13
>
> Attachments: check_odbc.py
>
>
> In ODBC set steaming was working till 2.9.1 . In the newer version if we run
> the command we get error
> SQL> set streaming on
> [ISQL]ERROR: Could not SQLNumResultCols
> [ODBC][24581][1643012198.417732][SQLPrepare.c][196]
> Entry:
> Statement = 0x555c08ebc6a0
> SQL = [set streaming on][length = 16]
> [ODBC][24581][1643012198.417825][SQLPrepare.c][377]
> Exit:[SQL_SUCCESS]
> [ODBC][24581][1643012198.417852][SQLExecute.c][187]
> Entry:
> Statement = 0x555c08ebc6a0
> [ODBC][24581][1643012198.418666][SQLExecute.c][357]
> Exit:[SQL_SUCCESS]
> [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156]
> Entry:
> Statement = 0x555c08ebc6a0
> Column Count = 0x7fffedb35566
> [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251]
> Exit:[SQL_ERROR]
> [ODBC][24581][1643012198.418772][SQLError.c][424]
> Entry:
> Statement = 0x555c08ebc6a0
> SQLState = 0x7fffedb35306
> Native = 0x7fffedb35300
> Message Text = 0x7fffedb35310
> Buffer Length = 500
> Text Len Ptr = 0x7fffedb352fe
> [ODBC][24581][1643012198.418801][SQLError.c][474]
> Exit:[SQL_NO_DATA]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16359) SET STREAMING ON/OFF not working
[
https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483787#comment-17483787
]
Ivan Daschinsky commented on IGNITE-16359:
--
Yep, bug was introduced in IGNITE-12125, fix is straightforward
{code}
Index: modules/platforms/cpp/odbc/src/query/streaming_query.cpp
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
diff --git a/modules/platforms/cpp/odbc/src/query/streaming_query.cpp
b/modules/platforms/cpp/odbc/src/query/streaming_query.cpp
--- a/modules/platforms/cpp/odbc/src/query/streaming_query.cpp (revision
7c7ea9bfe4c678a6fde5754bf6ce4c6443cd8104)
+++ b/modules/platforms/cpp/odbc/src/query/streaming_query.cpp (date
1643377511759)
@@ -51,7 +51,9 @@
const meta::ColumnMetaVector* StreamingQuery::GetMeta()
{
-return 0;
+static meta::ColumnMetaVector empty;
+
+return
}
SqlResult::Type
StreamingQuery::FetchNextRow(app::ColumnBindingMap&)
{code}
> SET STREAMING ON/OFF not working
> -
>
> Key: IGNITE-16359
> URL: https://issues.apache.org/jira/browse/IGNITE-16359
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.10, 2.11, 2.12, 2.11.1
>Reporter: Abhay
>Assignee: Ivan Daschinsky
>Priority: Major
> Attachments: check_odbc.py
>
>
> In ODBC set steaming was working till 2.9.1 . In the newer version if we run
> the command we get error
> SQL> set streaming on
> [ISQL]ERROR: Could not SQLNumResultCols
> [ODBC][24581][1643012198.417732][SQLPrepare.c][196]
> Entry:
> Statement = 0x555c08ebc6a0
> SQL = [set streaming on][length = 16]
> [ODBC][24581][1643012198.417825][SQLPrepare.c][377]
> Exit:[SQL_SUCCESS]
> [ODBC][24581][1643012198.417852][SQLExecute.c][187]
> Entry:
> Statement = 0x555c08ebc6a0
> [ODBC][24581][1643012198.418666][SQLExecute.c][357]
> Exit:[SQL_SUCCESS]
> [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156]
> Entry:
> Statement = 0x555c08ebc6a0
> Column Count = 0x7fffedb35566
> [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251]
> Exit:[SQL_ERROR]
> [ODBC][24581][1643012198.418772][SQLError.c][424]
> Entry:
> Statement = 0x555c08ebc6a0
> SQLState = 0x7fffedb35306
> Native = 0x7fffedb35300
> Message Text = 0x7fffedb35310
> Buffer Length = 500
> Text Len Ptr = 0x7fffedb352fe
> [ODBC][24581][1643012198.418801][SQLError.c][474]
> Exit:[SQL_NO_DATA]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16359) SET STREAMING ON/OFF not working
[ https://issues.apache.org/jira/browse/IGNITE-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky reassigned IGNITE-16359: Assignee: Ivan Daschinsky > SET STREAMING ON/OFF not working > - > > Key: IGNITE-16359 > URL: https://issues.apache.org/jira/browse/IGNITE-16359 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.10, 2.11, 2.12, 2.11.1 >Reporter: Abhay >Assignee: Ivan Daschinsky >Priority: Major > Attachments: check_odbc.py > > > In ODBC set steaming was working till 2.9.1 . In the newer version if we run > the command we get error > SQL> set streaming on > [ISQL]ERROR: Could not SQLNumResultCols > [ODBC][24581][1643012198.417732][SQLPrepare.c][196] > Entry: > Statement = 0x555c08ebc6a0 > SQL = [set streaming on][length = 16] > [ODBC][24581][1643012198.417825][SQLPrepare.c][377] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.417852][SQLExecute.c][187] > Entry: > Statement = 0x555c08ebc6a0 > [ODBC][24581][1643012198.418666][SQLExecute.c][357] > Exit:[SQL_SUCCESS] > [ODBC][24581][1643012198.418709][SQLNumResultCols.c][156] > Entry: > Statement = 0x555c08ebc6a0 > Column Count = 0x7fffedb35566 > [ODBC][24581][1643012198.418743][SQLNumResultCols.c][251] > Exit:[SQL_ERROR] > [ODBC][24581][1643012198.418772][SQLError.c][424] > Entry: > Statement = 0x555c08ebc6a0 > SQLState = 0x7fffedb35306 > Native = 0x7fffedb35300 > Message Text = 0x7fffedb35310 > Buffer Length = 500 > Text Len Ptr = 0x7fffedb352fe > [ODBC][24581][1643012198.418801][SQLError.c][474] > Exit:[SQL_NO_DATA] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16425) Use effective direct access in TableManager#directTableId
[ https://issues.apache.org/jira/browse/IGNITE-16425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-16425: -- Assignee: Ivan Bessonov > Use effective direct access in TableManager#directTableId > - > > Key: IGNITE-16425 > URL: https://issues.apache.org/jira/browse/IGNITE-16425 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > Current implementation reads too much data -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16225) Read Repair control.sh command should have named params
[
https://issues.apache.org/jira/browse/IGNITE-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-16225:
--
Summary: Read Repair control.sh command should have named params (was:
Read Repair control.sh command should have named params.)
> Read Repair control.sh command should have named params
> ---
>
> Key: IGNITE-16225
> URL: https://issues.apache.org/jira/browse/IGNITE-16225
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current syntax is
> {noformat}
> --consistency repair consistencyCacheName consistencyCachePartition
> readRepairStrategy
> {noformat}
> while it can be more readable like
> {noformat}
> --consistency repair -c/--cache consistencyCacheName -p/--partition
> consistencyCachePartition -s/--strategy readRepairStrategy
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16306) [POC] In-Memory storage integration
[ https://issues.apache.org/jira/browse/IGNITE-16306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-16306: Assignee: Aleksandr Polovtcev > [POC] In-Memory storage integration > --- > > Key: IGNITE-16306 > URL: https://issues.apache.org/jira/browse/IGNITE-16306 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha3 >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: iep-74, ignite-3 > > h3. Goals > We need an in-memory store, similar to Ignite-2. This store must reuse common > replication infrastructure, in other words, be integrated into raft STM and > support transactions. > The raft protocol implies some persistent state: metadata, logs, snapshot. > Simplest solution - write a raft persistent state on disk (this is already > implemented for > org.apache.ignite.internal.storage.basic.ConcurrentHashMapPartitionStorage). > Drawback - not fully in-memory solution, doesn't much differ from a database > cache > We can go the pure in-memory way - keep all raft state in a volatile store. > h3. Raft metadata > Must not be persisted for a pure in-memory cluster, because the state is > always lost on restart. > Note: a node must always be removed from the raft group when it’s removed > from baseline by auto adjust and should join as new (in-memory always works > with auto-adjust similarly to Ignite 2). *Out of scope.* > h3. Log store > Has working in-memory implementation (currently used in tests): > org.apache.ignite.raft.jraft.storage.impl.LocalLogStorage > Note: generally speaking, log is only required for "historical rebalancing" > after the snapshot rebalance. It won't be needed at all once it is possible > to apply snapshot and concurrent updates at the same time, for example when a > solution like mvcc is implemented. > h3. Snapshots > Can be implemented over any kv store extended with some kind of Copy-On-Write > support. Not implemented currently. More details below. > h3. COW buffer > To create an in-memory snapshot, the snapshot data is written to a separate > in-memory buffer. The buffer is populated from the state machine update > thread either by the update operations or by a snapshot advance mini-task > which is submitted to the state machine update thread as needed. > To maintain a snapshot, the state machine needs to keep an snapshot iterator > boundary key. If a key being updated is smaller or equal than the boundary > key, there is no need in any additional action because the snapshot iterator > has already processed this key. If a key being updated is larger than the > boundary key, the old version of the key is eagerly put to the snapshot > buffer and the key is marked with snapshot ID (so that the key is skipped > during further iteration). Snapshot advance mini-task iterates over a next > batch of the keys starting from the boundary key and puts to the snapshot > buffer only keys that are not yet marked by the snapshot ID. > This approach has similar memory requirements to the first alternative, but > does not require to modify the storage tree so that it can store multiple > versions of the same key. This approach, however, allows for transparent > snapshot buffer offloading to disk which can reduce memory requirements. It > is also simpler in implementation because the code is essentially > single-threaded and only requires synchronization for the in-memory buffer. > The downside is that snapshot advance tasks will increase tail latency of > state machine update operations. > Can be implemented on top of any kv store. > Note: we should consider the possibility of streaming the snapshot instead of > storing it in memory until it is completed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16426) Add tests for known scenarios that lead to index corruption.
Andrey Mashenkov created IGNITE-16426: - Summary: Add tests for known scenarios that lead to index corruption. Key: IGNITE-16426 URL: https://issues.apache.org/jira/browse/IGNITE-16426 Project: Ignite Issue Type: Test Reporter: Andrey Mashenkov Let's add test for next known scenarios that lead to index tree corruption. # Dropping cache while index (re)build is in progress lead to index corruption. In that case, a put operation will failed after the cache re-creation due to BTree corruption. Seems, we forgot to drop the index tree for incomplete index when the index (re)build task aborted. # Affinity index can be shadowed by a user cache (composite or not), which the very first column is affinity column. On node start, we detect if there is such user index available and use the user index, and use Affinity_Key system index otherwise. Thus if a user adds or removes such index between node restart, Ignite can switch either to one or to another tree, and this leads to inconsistent indices and corruption. # Similar to p.2. , a user can get a corrupted tree if he drops a cache with such index, and create a new cache with the same name. A new cache will 'resurrect' system Affinity_Key from the old cache. Seems, we never cleanup Affinity_Key on cache destroy if it is shadowed by the user index. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16427) Broken code formatting in 3.0.0-alpha4 documentation
Valentin Kulichenko created IGNITE-16427: Summary: Broken code formatting in 3.0.0-alpha4 documentation Key: IGNITE-16427 URL: https://issues.apache.org/jira/browse/IGNITE-16427 Project: Ignite Issue Type: Bug Components: documentation Reporter: Valentin Kulichenko Fix For: 3.0.0-alpha4 There are formatting issues on these two pages: * [https://ignite.apache.org/docs/3.0.0-alpha/transactions/performing-transactions] * https://ignite.apache.org/docs/3.0.0-alpha/table-views -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16427) Broken code formatting in 3.0.0-alpha4 documentation
[ https://issues.apache.org/jira/browse/IGNITE-16427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-16427: - Labels: ignite-3 (was: ) > Broken code formatting in 3.0.0-alpha4 documentation > > > Key: IGNITE-16427 > URL: https://issues.apache.org/jira/browse/IGNITE-16427 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Valentin Kulichenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > > There are formatting issues on these two pages: > * > [https://ignite.apache.org/docs/3.0.0-alpha/transactions/performing-transactions] > * https://ignite.apache.org/docs/3.0.0-alpha/table-views -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16343) Update hash and sig links on the Downloads page
[ https://issues.apache.org/jira/browse/IGNITE-16343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-16343: - Fix Version/s: (was: 3.0.0-alpha4) > Update hash and sig links on the Downloads page > --- > > Key: IGNITE-16343 > URL: https://issues.apache.org/jira/browse/IGNITE-16343 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Major > Labels: ignite-3 > > See dev list thread: > https://lists.apache.org/thread/b693db4rpll8fnwoc01xpspcvjjggsp6 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16416) Unreadable result on cluster deactivation via IgniteMXBean
[
https://issues.apache.org/jira/browse/IGNITE-16416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483931#comment-17483931
]
Ignite TC Bot commented on IGNITE-16416:
{panel:title=Branch: [pull/9775/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9775/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6388652buildTypeId=IgniteTests24Java8_RunAll]
> Unreadable result on cluster deactivation via IgniteMXBean
> --
>
> Key: IGNITE-16416
> URL: https://issues.apache.org/jira/browse/IGNITE-16416
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Attachments: Scr_Bad.png, Scr_Good.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IgniteMXBean can throw IgniteException on the cluster deactivation. It's is
> OK with the exception itself - cluster must not be deactivated without
> 'force' flag if that would issue data loss. Unfortunately, I'd forgotten that
> such exception is bound to the class path and might not be serialized by
> other remote size like jconsole.
> See 'bad' picture. Same refuse on the deactivation, bad the error is
> unreadable.
> See 'good' picture. Some readable result.
> Solution: let's convert the exception to a 'java-core' one.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (IGNITE-16343) Update hash and sig links on the Downloads page
[ https://issues.apache.org/jira/browse/IGNITE-16343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-16343. > Update hash and sig links on the Downloads page > --- > > Key: IGNITE-16343 > URL: https://issues.apache.org/jira/browse/IGNITE-16343 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Major > Labels: ignite-3 > > See dev list thread: > https://lists.apache.org/thread/b693db4rpll8fnwoc01xpspcvjjggsp6 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16343) Update hash and sig links on the Downloads page
[ https://issues.apache.org/jira/browse/IGNITE-16343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko resolved IGNITE-16343. -- Resolution: Fixed > Update hash and sig links on the Downloads page > --- > > Key: IGNITE-16343 > URL: https://issues.apache.org/jira/browse/IGNITE-16343 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Major > Labels: ignite-3 > > See dev list thread: > https://lists.apache.org/thread/b693db4rpll8fnwoc01xpspcvjjggsp6 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16428) Thick client :: Getting failed to start manager and spi. Local node's grid security processor class is not equal to remote node's grid security processor.
[ https://issues.apache.org/jira/browse/IGNITE-16428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Chaturvedi updated IGNITE-16428: - Description: As per Ignite : IGNITE-15969 * h1. Enabling authentication requires the client node to enable persistence in the configuration * This issue was fixed in 2.12.0 but now getting other exceptions which are mentioned below. +++ Thick client is not connecting with server node and fails with ignite 2.12.0. Server side authentication and persistance both are enabled in ignite-config.xml. Application related thick client's configuration in ignite-config.xml is mentioned below:: http://www.springframework.org/schema/beans; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=" [http://www.springframework.org/schema/beans] [http://www.springframework.org/schema/beans/spring-beans.xsd];> 127.0.0.1:47500 +++ Once execute code :: Ignition.start(igniteConfigResource.getFile().getAbsolutePath()); Getting below exception:: Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apache.ignite.Ignite]: Factory method 'igniteInstance' threw exception; nested exception is class org.apache.ignite.IgniteException: Failed to start manager: GridManagerAdapter [enabled=true, name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:653) ... 41 more Caused by: class org.apache.ignite.IgniteException: Failed to start manager: GridManagerAdapter [enabled=true, name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] at org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1113) at org.apache.ignite.Ignition.start(Ignition.java:356) at com.avis.biverve.config.IgniteConfig.igniteInstance(IgniteConfig.java:22) at com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998.CGLIB$igniteInstance$0() at com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998$$FastClassBySpringCGLIB$$457f046.invoke() at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331) at com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998.igniteInstance() at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) ... 42 more Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start manager: GridManagerAdapter [enabled=true, name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1958) at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1300) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1798) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720) at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1159) at org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1053) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:939) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:838) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:708) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:677) at org.apache.ignite.Ignition.start(Ignition.java:353) ... 53 more Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start SPI: TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000, ackTimeout=5000, marsh=JdkMarshaller
[jira] [Created] (IGNITE-16428) Getting failed to start manager and spi. Local node's grid security processor class is not equal to remote node's grid security processor.
Abhishek Chaturvedi created IGNITE-16428: Summary: Getting failed to start manager and spi. Local node's grid security processor class is not equal to remote node's grid security processor. Key: IGNITE-16428 URL: https://issues.apache.org/jira/browse/IGNITE-16428 Project: Ignite Issue Type: Bug Components: clients Affects Versions: 2.11.1 Reporter: Abhishek Chaturvedi Thick client is not connecting with server node and fails with ignite 2.12.0 but same was working fine with 2.9.1 V. Server side authentication and persistance are enabled in ignite-config.xml. Application side Thick Client's ignite-config.xml configuration is mentioned below:: http://www.springframework.org/schema/beans; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd;> 127.0.0.1:47500 +++ Once execute code :: Ignition.start(igniteConfigResource.getFile().getAbsolutePath()); Getting below exception:: Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apache.ignite.Ignite]: Factory method 'igniteInstance' threw exception; nested exception is class org.apache.ignite.IgniteException: Failed to start manager: GridManagerAdapter [enabled=true, name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:653) ... 41 more Caused by: class org.apache.ignite.IgniteException: Failed to start manager: GridManagerAdapter [enabled=true, name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] at org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1113) at org.apache.ignite.Ignition.start(Ignition.java:356) at com.avis.biverve.config.IgniteConfig.igniteInstance(IgniteConfig.java:22) at com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998.CGLIB$igniteInstance$0() at com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998$$FastClassBySpringCGLIB$$457f046.invoke() at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331) at com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998.igniteInstance() at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) ... 42 more Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start manager: GridManagerAdapter [enabled=true, name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1958) at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1300) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1798) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720) at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1159) at org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1053) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:939) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:838) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:708) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:677) at org.apache.ignite.Ignition.start(Ignition.java:353) ... 53 more Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start SPI: TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000, ackTimeout=5000,
[jira] [Updated] (IGNITE-16428) Thick client :: Getting failed to start manager and spi. Local node's grid security processor class is not equal to remote node's grid security processor.
[ https://issues.apache.org/jira/browse/IGNITE-16428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Chaturvedi updated IGNITE-16428: - Summary: Thick client :: Getting failed to start manager and spi. Local node's grid security processor class is not equal to remote node's grid security processor. (was: Getting failed to start manager and spi. Local node's grid security processor class is not equal to remote node's grid security processor.) > Thick client :: Getting failed to start manager and spi. Local node's grid > security processor class is not equal to remote node's grid security > processor. > -- > > Key: IGNITE-16428 > URL: https://issues.apache.org/jira/browse/IGNITE-16428 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.12 >Reporter: Abhishek Chaturvedi >Priority: Major > > Thick client is not connecting with server node and fails with ignite 2.12.0 > but same was working fine with 2.9.1 V. Server side authentication and > persistance are enabled in ignite-config.xml. > Application side Thick Client's ignite-config.xml configuration is mentioned > below:: > http://www.springframework.org/schema/beans; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd;> > > > > > > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder"> > > > 127.0.0.1:47500 > > > > > > > > > +++ > Once execute code :: > Ignition.start(igniteConfigResource.getFile().getAbsolutePath()); > Getting below exception:: > Caused by: org.springframework.beans.BeanInstantiationException: Failed to > instantiate [org.apache.ignite.Ignite]: Factory method 'igniteInstance' threw > exception; nested exception is class org.apache.ignite.IgniteException: > Failed to start manager: GridManagerAdapter [enabled=true, > name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) > at > org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:653) > ... 41 more > Caused by: class org.apache.ignite.IgniteException: Failed to start manager: > GridManagerAdapter [enabled=true, > name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1113) > at org.apache.ignite.Ignition.start(Ignition.java:356) > at > com.avis.biverve.config.IgniteConfig.igniteInstance(IgniteConfig.java:22) > at > com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998.CGLIB$igniteInstance$0() > at > com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998$$FastClassBySpringCGLIB$$457f046.invoke() > at > org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) > at > org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331) > at > com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998.igniteInstance() > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) > ... 42 more > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start > manager: GridManagerAdapter [enabled=true, > name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] > at > org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1958) > at > org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1300) > at >
[jira] [Updated] (IGNITE-16428) Thick client :: Getting failed to start manager and spi. Local node's grid security processor class is not equal to remote node's grid security processor.
[ https://issues.apache.org/jira/browse/IGNITE-16428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Chaturvedi updated IGNITE-16428: - Description: As per Ignite : IGNITE-15969 * h1. Enabling authentication requires the client node to enable persistence in the configuration * This issue was fixed in 2.12.0 but now getting other exceptions which are mentioned below. +++ Thick client is not connecting with server node and fails with ignite 2.12.0 but same was working fine with 2.9.1 V. Server side authentication and persistance are enabled in ignite-config.xml. Application side Thick Client's ignite-config.xml configuration is mentioned below:: http://www.springframework.org/schema/beans; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=" [http://www.springframework.org/schema/beans] [http://www.springframework.org/schema/beans/spring-beans.xsd];> 127.0.0.1:47500 +++ Once execute code :: Ignition.start(igniteConfigResource.getFile().getAbsolutePath()); Getting below exception:: Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apache.ignite.Ignite]: Factory method 'igniteInstance' threw exception; nested exception is class org.apache.ignite.IgniteException: Failed to start manager: GridManagerAdapter [enabled=true, name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:653) ... 41 more Caused by: class org.apache.ignite.IgniteException: Failed to start manager: GridManagerAdapter [enabled=true, name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] at org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1113) at org.apache.ignite.Ignition.start(Ignition.java:356) at com.avis.biverve.config.IgniteConfig.igniteInstance(IgniteConfig.java:22) at com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998.CGLIB$igniteInstance$0() at com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998$$FastClassBySpringCGLIB$$457f046.invoke() at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331) at com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998.igniteInstance() at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) ... 42 more Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start manager: GridManagerAdapter [enabled=true, name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1958) at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1300) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1798) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720) at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1159) at org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1053) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:939) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:838) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:708) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:677) at org.apache.ignite.Ignition.start(Ignition.java:353) ... 53 more Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start SPI: TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000, ackTimeout=5000,
[jira] [Updated] (IGNITE-16428) Getting failed to start manager and spi. Local node's grid security processor class is not equal to remote node's grid security processor.
[ https://issues.apache.org/jira/browse/IGNITE-16428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Chaturvedi updated IGNITE-16428: - Affects Version/s: 2.12 (was: 2.11.1) > Getting failed to start manager and spi. Local node's grid security processor > class is not equal to remote node's grid security processor. > -- > > Key: IGNITE-16428 > URL: https://issues.apache.org/jira/browse/IGNITE-16428 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.12 >Reporter: Abhishek Chaturvedi >Priority: Major > > Thick client is not connecting with server node and fails with ignite 2.12.0 > but same was working fine with 2.9.1 V. Server side authentication and > persistance are enabled in ignite-config.xml. > Application side Thick Client's ignite-config.xml configuration is mentioned > below:: > http://www.springframework.org/schema/beans; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd;> > > > > > > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder"> > > > 127.0.0.1:47500 > > > > > > > > > +++ > Once execute code :: > Ignition.start(igniteConfigResource.getFile().getAbsolutePath()); > Getting below exception:: > Caused by: org.springframework.beans.BeanInstantiationException: Failed to > instantiate [org.apache.ignite.Ignite]: Factory method 'igniteInstance' threw > exception; nested exception is class org.apache.ignite.IgniteException: > Failed to start manager: GridManagerAdapter [enabled=true, > name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) > at > org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:653) > ... 41 more > Caused by: class org.apache.ignite.IgniteException: Failed to start manager: > GridManagerAdapter [enabled=true, > name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1113) > at org.apache.ignite.Ignition.start(Ignition.java:356) > at > com.avis.biverve.config.IgniteConfig.igniteInstance(IgniteConfig.java:22) > at > com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998.CGLIB$igniteInstance$0() > at > com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998$$FastClassBySpringCGLIB$$457f046.invoke() > at > org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) > at > org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331) > at > com.avis.biverve.config.IgniteConfig$$EnhancerBySpringCGLIB$$92287998.igniteInstance() > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) > ... 42 more > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start > manager: GridManagerAdapter [enabled=true, > name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] > at > org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1958) > at > org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1300) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1798) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720) > at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1159) > at >
