[jira] [Created] (IGNITE-12067) SQL: metrics of executions of user queries
Pavel Kuznetsov created IGNITE-12067: Summary: SQL: metrics of executions of user queries Key: IGNITE-12067 URL: https://issues.apache.org/jira/browse/IGNITE-12067 Project: Ignite Issue Type: Bug Components: sql Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov Lets add: - Counter of success executed user queries. - Counter of failed executed user queries. - Counter of failed by OOM executed user queries. - Counter of cancelled user queries. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12043) Metrics: JMX exporter reports incorrect description.
Pavel Kuznetsov created IGNITE-12043:
Summary: Metrics: JMX exporter reports incorrect description.
Key: IGNITE-12043
URL: https://issues.apache.org/jira/browse/IGNITE-12043
Project: Ignite
Issue Type: Bug
Reporter: Pavel Kuznetsov
JMX exporter creates bean for each metric. Metric's registration takes human
readable description field.
If we open any MBean explorer and get Metadata of any metric, we see
{{description = .}} instead of human readable
description, specified by metric developer.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12020) SQL: Metrics of using memory quotas.
Pavel Kuznetsov created IGNITE-12020: Summary: SQL: Metrics of using memory quotas. Key: IGNITE-12020 URL: https://issues.apache.org/jira/browse/IGNITE-12020 Project: Ignite Issue Type: New Feature Components: sql Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov Only local (per node) metrics are in scope. Metrics to implement: 1) How many times memory quota have been requested on the node by all the queries in total. (org.apache.ignite.internal.processors.query.h2.QueryMemoryManager) 2) How much memory all the queries are allowed to reserve on this node in total. (Possibly constant value until node reboot) 3) How much memory currently available for the queries on this node. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
Pavel Kuznetsov created IGNITE-11997: Summary: TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1 Key: IGNITE-11997 URL: https://issues.apache.org/jira/browse/IGNITE-11997 Project: Ignite Issue Type: Task Components: sql Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov IgniteCacheQueriesLoadTest1.testQueries have long execution. Need to investigate the reasons and fix it if possible. org.apache.ignite.testsuites.IgniteBinaryCacheQueryTestSuite2: org.apache.ignite.internal.processors.cache.IgniteCacheQueriesLoadTest1.testQueries 2m 52.81s -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-11991) [TC Bot]: Rerun possible blockers sets incorrect "SCALE FACTOR" build parameter
Pavel Kuznetsov created IGNITE-11991: Summary: [TC Bot]: Rerun possible blockers sets incorrect "SCALE FACTOR" build parameter Key: IGNITE-11991 URL: https://issues.apache.org/jira/browse/IGNITE-11991 Project: Ignite Issue Type: Improvement Reporter: Pavel Kuznetsov 1) Issue "Trigger build" during PR check from the Bot UI. Scheduled build has parameter SCALE FACTOR=0.1 which is ok, because we want to get results sooner. 2) Issue "Rerun possible blockers" and see that SF for the "rerun" TC builds is 1.0 (default). Expected that SF of the rerun builds should be the same as in the initial RunAll build. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-11938) SQL: Support java.time.Instant type as native time type
Pavel Kuznetsov created IGNITE-11938: Summary: SQL: Support java.time.Instant type as native time type Key: IGNITE-11938 URL: https://issues.apache.org/jira/browse/IGNITE-11938 Project: Ignite Issue Type: Improvement Reporter: Pavel Kuznetsov Currently Instant type is treated by Ignite as JAVA_OBJECT sql type(IGNITE-10690). But it can be possibly supported as one of the internal sql types. This probably breaks backward compatibility, since indexes should be rebuild -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11918) extend test coverage for KILL QUERY
Pavel Kuznetsov created IGNITE-11918: Summary: extend test coverage for KILL QUERY Key: IGNITE-11918 URL: https://issues.apache.org/jira/browse/IGNITE-11918 Project: Ignite Issue Type: Test Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov Currently we have implemented KILL QUERY COMMAND. However not all cases covered by tests and probably it doesn't work properly for all cases. On first look need to add following test scenarios for KILL QUERY command: 1) not stable topology - when node couldn't reserve partitions. 2) map and reduce parts 3) with concrete partition 4) when partition pruning is work. 5) local query 6) distributed joins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11916) reorder fields for GridQueryKillResponse and GridQueryKillRequest
Pavel Kuznetsov created IGNITE-11916: Summary: reorder fields for GridQueryKillResponse and GridQueryKillRequest Key: IGNITE-11916 URL: https://issues.apache.org/jira/browse/IGNITE-11916 Project: Ignite Issue Type: Bug Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov need to reorder all fields for GridQueryKillResponse and GridQueryKillRequest messages using MessageCodeGenerator to have right order of fields to avoid upgrade issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11666) C++ : remove internal macro usages in the examples
Pavel Kuznetsov created IGNITE-11666:
Summary: C++ : remove internal macro usages in the examples
Key: IGNITE-11666
URL: https://issues.apache.org/jira/browse/IGNITE-11666
Project: Ignite
Issue Type: Bug
Components: examples, platforms
Reporter: Pavel Kuznetsov
Currently c++ examples are using internal macros. For example to specify how to
serialize/deserialize user's c++ structs.
{code:c++ person.h}
IGNITE_BINARY_TYPE_START(ignite::examples::Person)
typedef ignite::examples::Person Person;
IGNITE_BINARY_GET_TYPE_ID_AS_HASH(Person)
IGNITE_BINARY_GET_TYPE_NAME_AS_IS(Person)
IGNITE_BINARY_GET_FIELD_ID_AS_HASH
IGNITE_BINARY_IS_NULL_FALSE(Person)
IGNITE_BINARY_GET_NULL_DEFAULT_CTOR(Person)
//...
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11538) SQL: Support new features (precision, scale, etc) in JDBC drivers
Pavel Kuznetsov created IGNITE-11538:
Summary: SQL: Support new features (precision, scale, etc) in JDBC
drivers
Key: IGNITE-11538
URL: https://issues.apache.org/jira/browse/IGNITE-11538
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Kuznetsov
Currently JDBC result set meta data return dummy value (0 or -1 depending on
the driver) for the precision and scale, but we already have all the info to
return correct values.
*Both thin and v2 driver are affected.*
See
{{org.apache.ignite.internal.jdbc2.JdbcResultSetMetadata#getPrecision}} - dummy 0
{{org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryCursor#meta}} - thin
driver actually uses v1 version of the JdbcColumnMeta which returns -1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11505) Validation of starting cache configuration wraps original exception into Suppressed section
Pavel Kuznetsov created IGNITE-11505:
Summary: Validation of starting cache configuration wraps original
exception into Suppressed section
Key: IGNITE-11505
URL: https://issues.apache.org/jira/browse/IGNITE-11505
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Kuznetsov
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#validate}} :
If user starts cache dynamically via {{getOrCreateCache}} on *server node* and
{{validate}} method throws an
exception, this exception will be shown to user in the as Suppressed. So user
need to get the cause as {{ String origMessage =
catchedUserExc.getSuppressed()[0].getCause().getMessage();}}.
To reproduce, it is important, that validation should be performed on the
server node.
take a look at stacktraces.
cache started from server node:
{noformat}
class org.apache.ignite.IgniteCheckedException: Failed to complete exchange
process.
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3209)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3237)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3323)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3304)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2906)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:145)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2713)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2701)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2701)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1812)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1200(GridCachePartitionExchangeManager.java:148)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:385)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:343)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3368)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3347)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1126)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1561)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1086)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[jira] [Created] (IGNITE-11329) Support data page scan for JDBC v2 driver
Pavel Kuznetsov created IGNITE-11329:
Summary: Support data page scan for JDBC v2 driver
Key: IGNITE-11329
URL: https://issues.apache.org/jira/browse/IGNITE-11329
Project: Ignite
Issue Type: Improvement
Components: jdbc, sql
Reporter: Pavel Kuznetsov
We need to fix compatibility issue in compute task of jdbc v2 driver and add
support of this flag.
Currently jdbc thick driver doen't ask cluster nodes for theirs versions.
Guess we have node with only {{JdbcQueryTaskV2}} and v3 is missing in that
version of the node. If we use new feature, introduced in v3, driver performs
v3 with no regards what versions is supported on the node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11305) Support data page scan for ODBC
Pavel Kuznetsov created IGNITE-11305: Summary: Support data page scan for ODBC Key: IGNITE-11305 URL: https://issues.apache.org/jira/browse/IGNITE-11305 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Kuznetsov Just like IGNITE-10937, we need the same for ODBC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11251) SQL: getMoreResults() infinitely reports about update operation on zeroCursor
Pavel Kuznetsov created IGNITE-11251:
Summary: SQL: getMoreResults() infinitely reports about update
operation on zeroCursor
Key: IGNITE-11251
URL: https://issues.apache.org/jira/browse/IGNITE-11251
Project: Ignite
Issue Type: Bug
Components: jdbc, sql
Reporter: Pavel Kuznetsov
If we got sql query that contain empty statement, jdbc thin driver will allways
return {{true}} from {{getMoreResults}} method.
Jdbc spec says:
{noformat}
oves to this Statement object's next result, returns true if it is a ResultSet
object,
<...>
Returns:
true if the next result is a ResultSet object; false if it is an update count
or there are no more results
{noformat}
so test :
{code:java}
@Test
public void test () throws Exception {
try (Connection c = GridTestUtils.connect(grid(0), null)) {
try (PreparedStatement p = c.prepareStatement(";")) {
boolean isResultSet = p.execute();
// Adding next line works the problem around:
// p.getUpdateCount() == 0;
boolean isResultSetReturned = p.getMoreResults();
// should be false:
assertFalse(isResultSetReturned); // == true
}
}
}
{code}
{{getResultSet}} is {{null}} in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10964) SQL: Concurrent dml and alter table
Pavel Kuznetsov created IGNITE-10964:
Summary: SQL: Concurrent dml and alter table
Key: IGNITE-10964
URL: https://issues.apache.org/jira/browse/IGNITE-10964
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Our tests doesn't cover the case first user select or insert to table and
another user alters the same table. There are some parts of {{GridH2Table}}
that may cause data races in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10939) SQL: UPDATE of second level fields fails if parent field was set to null previously
Pavel Kuznetsov created IGNITE-10939:
Summary: SQL: UPDATE of second level fields fails if parent field
was set to null previously
Key: IGNITE-10939
URL: https://issues.apache.org/jira/browse/IGNITE-10939
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Given table in the cache Integer -> Value
{code:java}
static final class Value implements Serializable {
@QuerySqlField
Long longCol;
/** Inner type object. */
@QuerySqlField
InnerType innerTypeCol;
static final class InnerType implements Serializable {
@QuerySqlField
Long innerLongCol;
@QuerySqlField
String innerStrCol;
}
}
{code}
We insert so data, to have {{innerTypeCol}} in default value null:
{code:sql}
INSERT INTO Value (_key, longCol) VALUES (42, 123);
{code}
Updates of the inner fields {{innerLongCol}} and {{innerStrCol}}
{code:sql}
UPDATE AllTypes SET innerLongCol = 3
{code}
will result to error:
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Individual properties can be set for binary builders only
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2248)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2197)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2124)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:794)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:742)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:386)
at
org.apache.ignite.internal.processors.cache.IgniteCacheInsertSqlQuerySelfTest.testCacheRestartHandling(IgniteCacheInsertSqlQuerySelfTest.java:253)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Individual
properties can be set for binary builders only
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2743)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2225)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2245)
... 16 more
Caused by: java.lang.UnsupportedOperationException: Individual properties can
be set for binary builders only
at
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.setValue(QueryBinaryProperty.java:194)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.setColumnValue(GridH2RowDescriptor.java:246)
at
org.apache.ignite.internal.processors.query.h2.dml.UpdatePlan.processRowForUpdate(UpdatePlan.java:354)
at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doUpdate(DmlStatementsProcessor.java:861)
at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.processDmlSelectResult(DmlStatementsProcessor.java:739)
at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:685)
at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:208)
at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:381)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1593)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1534)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2207)
at
[jira] [Created] (IGNITE-10906) SQL: UPDATE statement allows null for entire value cache object
Pavel Kuznetsov created IGNITE-10906:
Summary: SQL: UPDATE statement allows null for entire value cache
object
Key: IGNITE-10906
URL: https://issues.apache.org/jira/browse/IGNITE-10906
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Currently next query doesn't cause error:
{code:sql}
CREATE TABLE SIMPLE (id INT PRIMARY KEY, name VARCHAR) WITH "wrap_value=false,
wrap_key=false"
UPDATE SIMPLE SET _val = null
{code}
But it should, because underlying cache doesn't support null values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10824) SQL: mixing _key and key columns in the DML queries must be disallowed
Pavel Kuznetsov created IGNITE-10824:
Summary: SQL: mixing _key and key columns in the DML queries must
be disallowed
Key: IGNITE-10824
URL: https://issues.apache.org/jira/browse/IGNITE-10824
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Assignee: Pavel Kuznetsov
DML should contain either placeholder for _key (_val) or subset of key (value)
columns but not both. Also we should keep in mind _key/_value aliases
Given table with primary key column {{id}}. Next query should be validated to
parsing error:
{code:sql}
INSERT INTO TEST_TABLE (_key, id, salary) VALUES (1, 2, 42);
UPDATE TEST_TABLE SET _val = 1, salary = 2;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10745) SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
Pavel Kuznetsov created IGNITE-10745:
Summary: SQL: jdbc metadata's getColumns returns wrong value for
"ORDINAL_POSITION"
Key: IGNITE-10745
URL: https://issues.apache.org/jira/browse/IGNITE-10745
Project: Ignite
Issue Type: Bug
Components: jdbc
Reporter: Pavel Kuznetsov
Affected both thin and jdbc v2 drivers.
jdbc spec says :
{noformat}
ORDINAL_POSITION int => index of column in table (starting at 1)
{noformat}
but in fact it is a position in the metadata table itself, not position in the
original table.
For example we have table
{code:sql}
Person(id int primary key, val1 int, val2 bigint, val3 int)
{code:sql}
Oridinal number for {{val3}} is 4, but if we specified patterns that leave only
1 result ({{PUBLIC.Person.val3}}) returned value will be 1. If we select 2
tables - 2 or 1 and so on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
Pavel Kuznetsov created IGNITE-10645: Summary: SQL properties ownership flag should be set at configuration parsing, not query execution. Key: IGNITE-10645 URL: https://issues.apache.org/jira/browse/IGNITE-10645 Project: Ignite Issue Type: Bug Components: sql Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov At processing time, query entities are transformed and validated, table descriptors with properties are created. Now in some case (thre's no keyFields and key is of complex non-sql type), ownership flag of query property is calculated at execution time (for example at first put()): https://github.com/apache/ignite/blob/dcdb27a24a450f63487290360b265e1570534629/modules/core/src/main/java/org/apache/ignite/internal/processors/query/property/QueryBinaryProperty.java#L132 So we can't access metadata, that uses this not-yet-initialized field before we put the data. But we already have all necessary info to set this field at processing time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10210) SQL: jdbc thin connected to newly started client, misses "old" tables
Pavel Kuznetsov created IGNITE-10210:
Summary: SQL: jdbc thin connected to newly started client, misses
"old" tables
Key: IGNITE-10210
URL: https://issues.apache.org/jira/browse/IGNITE-10210
Project: Ignite
Issue Type: Bug
Components: jdbc, sql
Affects Versions: 2.6
Reporter: Pavel Kuznetsov
Given cluster.
We are creating table using thin driver.
After that we are starting new client node and connecting to it.
Metadata of this new connection doesn't contain information about this table.
Affected all methods that use
{{org.apache.ignite.internal.processors.query.GridQueryProcessor#types}} under
the hood.
Such as:
1) getPrimaryKeys()
2) getColumns()
3) getSchemas() (if no tables are created getSchemas() returns empty list.)
4) getTables()
5) getIndexes()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10118) JDBC v2: metadata.getSchemas returns cache names instead of schema names
Pavel Kuznetsov created IGNITE-10118:
Summary: JDBC v2: metadata.getSchemas returns cache names instead
of schema names
Key: IGNITE-10118
URL: https://issues.apache.org/jira/browse/IGNITE-10118
Project: Ignite
Issue Type: Bug
Reporter: Pavel Kuznetsov
jdbc v2 returns list of cache names instead of list of schemas.
It is correct only if we have a cache and table created in it using cache API.
If we create tables using ddl we expect to see "PUBLIC" schema name in results
of {{connection.getMetadata().getSchemas()}} not "SQL_PUBLIC_TABLENAME"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10070) SQL: If table not found, error message should contain full table name including schema.
Pavel Kuznetsov created IGNITE-10070: Summary: SQL: If table not found, error message should contain full table name including schema. Key: IGNITE-10070 URL: https://issues.apache.org/jira/browse/IGNITE-10070 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Kuznetsov If we do a query and we make a typo in the schema name or table name or if we make incorrect assumtions about default schema name, we won't see schema name in the error message. It's good for usability to print full table name SCHEMA.TABLE in the error message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10069) SQL implicit schema is incorrectly resolved in native api.
Pavel Kuznetsov created IGNITE-10069:
Summary: SQL implicit schema is incorrectly resolved in native api.
Key: IGNITE-10069
URL: https://issues.apache.org/jira/browse/IGNITE-10069
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Without explicit schema declaration (either sql syntax SCHEMA.TABLE or
SqlFieldsQuery#setSchema), do:
1) Create table using cache.query()
2) Perform select to this table
reproducer:
{noformat}
public void testSchema(){
IgniteCache c = ignite.getOrCreateCache("testCache");
c.query(new SqlFieldsQuery("CREATE TABLE TEST1 (ID LONG PRIMARY KEY,
VAL LONG) WITH \"template=replicated\";")).getAll();
c.query(new SqlFieldsQuery("SELECT * FROM TEST1")).getAll();
}
{noformat}
Got exception:
{noformat}
javax.cache.CacheException: Failed to parse query. Таблица "TEST1" не найдена
Table "TEST1" not found; SQL statement:
SELECT * FROM "testCache".TEST1 [42102-197]
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:697)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
at
org.apache.ignite.internal.processors.query.h2.sql.ExplainSelfTest.testSchema(ExplainSelfTest.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2209)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:745)
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse
query. Таблица "TEST1" не найдена
Table "TEST1" not found; SQL statement:
SELECT * FROM "testCache".TEST1 [42102-197]
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2628)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:2327)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2171)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2141)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2136)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2713)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2150)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:685)
... 12 more
Caused by: org.h2.jdbc.JdbcSQLException: Таблица "TEST1" не найдена
Table "TEST1" not found; SQL statement:
SELECT * FROM "testCache".TEST1 [42102-197]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at org.h2.schema.Schema.getTableOrView(Schema.java:506)
at org.h2.command.Parser.readTableOrView(Parser.java:5903)
at org.h2.command.Parser.readTableFilter(Parser.java:1430)
at org.h2.command.Parser.parseSelectSimpleFromPart(Parser.java:2138)
at org.h2.command.Parser.parseSelectSimple(Parser.java:2287)
at org.h2.command.Parser.parseSelectSub(Parser.java:2133)
at org.h2.command.Parser.parseSelectUnion(Parser.java:1946)
at org.h2.command.Parser.parseSelect(Parser.java:1919)
at org.h2.command.Parser.parsePrepared(Parser.java:463)
at org.h2.command.Parser.parse(Parser.java:335)
at org.h2.command.Parser.parse(Parser.java:307)
at org.h2.command.Parser.prepareCommand(Parser.java:278)
at org.h2.engine.Session.prepareLocal(Session.java:611)
at org.h2.engine.Session.prepareCommand(Session.java:549)
at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
at
[jira] [Created] (IGNITE-10005) SQL table catalog documentation
Pavel Kuznetsov created IGNITE-10005:
Summary: SQL table catalog documentation
Key: IGNITE-10005
URL: https://issues.apache.org/jira/browse/IGNITE-10005
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Pavel Kuznetsov
When IGNITE-3467 is done, we need to add few words about possible catalog
tables catalog name.
What we need to document:
1) Thre are no tables without catalog (tables which catalog is equal to empty
string {{""}}, not null!).
2) The only possible catalog for tables is "IGNITE".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9989) JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME
Pavel Kuznetsov created IGNITE-9989: --- Summary: JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME Key: IGNITE-9989 URL: https://issues.apache.org/jira/browse/IGNITE-9989 Project: Ignite Issue Type: Bug Reporter: Pavel Kuznetsov Jdbc v2 driver has hardcoded values for meta attibutes : COLUMN_NAME = _KEY KEY_SEQ = 1 PK_NAME = _KEY But this values should be different for different tables. how to reproduce: 1) connect to the cluser using jdbcv2 driver 2) CREATE TABLE TAB (ID LONG, SEC_ID LONG, VAL LONG, PRIMARY KEY(ID, SEC_ID)) 3) check result of connection.getMetadata().getPrimaryKeys() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9947) JDBC thin: Batch update is not performed if streaming state changed before executeBatch()
Pavel Kuznetsov created IGNITE-9947: --- Summary: JDBC thin: Batch update is not performed if streaming state changed before executeBatch() Key: IGNITE-9947 URL: https://issues.apache.org/jira/browse/IGNITE-9947 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.6 Reporter: Pavel Kuznetsov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9874) SQL: Jdbc benchmarks should use all cluster nodes in the jdbc url
Pavel Kuznetsov created IGNITE-9874: --- Summary: SQL: Jdbc benchmarks should use all cluster nodes in the jdbc url Key: IGNITE-9874 URL: https://issues.apache.org/jira/browse/IGNITE-9874 Project: Ignite Issue Type: Improvement Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov Currectly we use first host in the cluster that matches condition. We should use all cluster nodes in the jdbc url separated by "," see org.apache.ignite.yardstick.jdbc.AbstractJdbcBenchmark#findThinAddress -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9873) SQL: MERGE requires column names specified explicitly
Pavel Kuznetsov created IGNITE-9873:
---
Summary: SQL: MERGE requires column names specified explicitly
Key: IGNITE-9873
URL: https://issues.apache.org/jira/browse/IGNITE-9873
Project: Ignite
Issue Type: Bug
Reporter: Pavel Kuznetsov
Doc (https://apacheignite-sql.readme.io/docs/merge) defines MEGE operator:
{noformat}
MERGE INTO tableName [(columnName [,...])]
[KEY (columnName [,...])]
{VALUES {({ DEFAULT | expression } [,...])} [,...] | select}
{noformat}
So square brackets tell us columnName part can ben ommited. But in this case
we'll have parsing error.
How to reproduce:
execute sql script via any api.
{noformat}
CREATE TABLE TEST (ID LONG PRIMARY KEY, VAL LONG);
MERGE INTO TEST VALUES (1, 2);
{noformat}
But command below works well though:
{noformat}
MERGE INTO TEST (ID, VAL) VALUES (1, 2);
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9712) SQL: Select query benchmarks
Pavel Kuznetsov created IGNITE-9712: --- Summary: SQL: Select query benchmarks Key: IGNITE-9712 URL: https://issues.apache.org/jira/browse/IGNITE-9712 Project: Ignite Issue Type: Task Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov We need to create benchmark suite for select operations. We already have benchmarks for selects, so we need to update this code to support 1) select the single row with by PK; indexed field 2) select the range of rows filtered with PK; indexed field Selects by non-indexed fields are out of scope. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9655) SQL: Create benchmark suite for DML operations.
Pavel Kuznetsov created IGNITE-9655: --- Summary: SQL: Create benchmark suite for DML operations. Key: IGNITE-9655 URL: https://issues.apache.org/jira/browse/IGNITE-9655 Project: Ignite Issue Type: Task Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov Create benchmark configuration that contains benchmark runs for DML operations. 1) insert + delete 2) update (single, range with/without contention). Currently we have benchmark code for 1 and 2 without contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9637) SQL: Add indexes to data load benchmarks
Pavel Kuznetsov created IGNITE-9637: --- Summary: SQL: Add indexes to data load benchmarks Key: IGNITE-9637 URL: https://issues.apache.org/jira/browse/IGNITE-9637 Project: Ignite Issue Type: Bug Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov We want to measure data load with indexes. We already have table with several fileds. We need benchmark parameter that handles number of indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9458) SQL benchmarks: absence of "--mvcc" benchmark flag should not overwrite config values
Pavel Kuznetsov created IGNITE-9458: --- Summary: SQL benchmarks: absence of "--mvcc" benchmark flag should not overwrite config values Key: IGNITE-9458 URL: https://issues.apache.org/jira/browse/IGNITE-9458 Project: Ignite Issue Type: Bug Reporter: Pavel Kuznetsov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9447) Benchmarks hangs intemittently due to distributed race condition.
Pavel Kuznetsov created IGNITE-9447:
---
Summary: Benchmarks hangs intemittently due to distributed race
condition.
Key: IGNITE-9447
URL: https://issues.apache.org/jira/browse/IGNITE-9447
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Assignee: Pavel Kuznetsov
If we run more than one yardstick driver, benchmark hangs intermittently.
We've got yardstick's base driver class
org.apache.ignite.yardstick.IgniteAbstractBenchmark it has logic to wait all
the nodes in the cluster.
{noformat}
final CountDownLatch nodesStartedLatch = new CountDownLatch(1);
ignite().events().localListen(new IgnitePredicate() {
@Override public boolean apply(Event gridEvt) {
if (nodesStarted())
nodesStartedLatch.countDown();
return true;
}
}, EVT_NODE_JOINED);
if (!nodesStarted()) {
println(cfg, "Waiting for " + (args.nodes() - 1) + " nodes to
start...");
nodesStartedLatch.await();
}
{noformat}
This code is executed on every driver node.
If we want to close local ignite instance just after cluster is ready
(containing expected number of nodes), sometimes we'll have dead lock:
1) cluster contains N-1 nodes, all nodes are waiting for the Nth node.
2) Nth node is connected, cluster receives message, waitForNodes code of Nth
node is not executed.
3) N-1 nodes got this message and stop waiting.
4) N-1 thinks that cluster is ready and call ignite.close() on their local
instances
5) Nth node starts waiting for cluster to contain number of nodes, but N-1 of
them closed their instances
6) Nth node is waiting infinitely.
We can avoid this problem if we use distributed CountDownLatch
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8822) SQL: Failed to run map query remotely.
Pavel Kuznetsov created IGNITE-8822: --- Summary: SQL: Failed to run map query remotely. Key: IGNITE-8822 URL: https://issues.apache.org/jira/browse/IGNITE-8822 Project: Ignite Issue Type: Bug Components: sql Environment: reproduce on ignite cluster with 1 node. Default data region should be increased to 4 GiB. Reporter: Pavel Kuznetsov Given tables and indexes created (see attached create_tables.sql and create_indexes.sql) If we run 11.sql we'll get an error: "Error: class org.apache.ignite.IgniteException: Failed to generate REDUCE query. Data table found: PUBLIC.PARTSUPP" see full output in attached 11-out.txt and 11-server-err.txt (server errors) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8720) SQL: Failed to generate REDUCE query
Pavel Kuznetsov created IGNITE-8720:
---
Summary: SQL: Failed to generate REDUCE query
Key: IGNITE-8720
URL: https://issues.apache.org/jira/browse/IGNITE-8720
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Attached query fails with
{noformat}
java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
generate REDUCE query. Data table found: PUBLIC.LINEITEM
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8609) SQL: Get rid of syncronization in mvcc processor.
Pavel Kuznetsov created IGNITE-8609: --- Summary: SQL: Get rid of syncronization in mvcc processor. Key: IGNITE-8609 URL: https://issues.apache.org/jira/browse/IGNITE-8609 Project: Ignite Issue Type: Task Components: sql Reporter: Pavel Kuznetsov Assignee: Igor Seliverstov Currently we have to do synchronized actions in org/apache/ignite/internal/managers/communication/GridIoManager.java:1124 (org.apache.ignite.internal.managers.communication.GridIoManager#processRegularMessage) due to fails on nio thread on load. We are able to optimize this code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8342) Semi colon in CREATE INDEX causes infinite loop execution
Pavel Kuznetsov created IGNITE-8342:
---
Summary: Semi colon in CREATE INDEX causes infinite loop execution
Key: IGNITE-8342
URL: https://issues.apache.org/jira/browse/IGNITE-8342
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Given created table in cache
{noformat}
cache.query(new SqlFieldsQuery("CREATE INDEX AgeIndex ON Employee
(age);")).getAll();
{noformat}
seems to cause infinite loop
jstack :
{noformat}
"main" #1 prio=5 os_prio=0 tid=0x7fa1a800d000 nid=0x4b7c runnable
[0x7fa1b1932000]
java.lang.Thread.State: RUNNABLE
at org.apache.ignite.internal.sql.SqlLexer.lookAhead(SqlLexer.java:73)
at
org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parseIndexProperties(SqlCreateIndexCommand.java:250)
at
org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parse(SqlCreateIndexCommand.java:172)
at
org.apache.ignite.internal.sql.SqlParser.processCreate(SqlParser.java:207)
at
org.apache.ignite.internal.sql.SqlParser.nextCommand0(SqlParser.java:106)
at
org.apache.ignite.internal.sql.SqlParser.nextCommand(SqlParser.java:76)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.tryQueryDistributedSqlFieldsNative(IgniteH2Indexing.java:1509)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1599)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:664)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:615)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:356)
at
org.apache.ignite.sqltests.BaseSqlTest.fillCommonData(BaseSqlTest.java:107)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8186) SQL: Create test base to cover sql by features with flexible configuration
Pavel Kuznetsov created IGNITE-8186: --- Summary: SQL: Create test base to cover sql by features with flexible configuration Key: IGNITE-8186 URL: https://issues.apache.org/jira/browse/IGNITE-8186 Project: Ignite Issue Type: Task Components: sql Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov We need to cover sql feature by feature. We need to be able to run the same test cases with different configurations. At the moment configurations in scope: 1) Inmemory/persistence 2) Distributed joins: on/off 3) Cache mode: PARTITIONED/REPLICATED Features in scope: 1) Simple SELECT 2) JOIN (distributed and local) 3) GROUP BY Data model: Employee (1000) Department (50-100) Status of distributed joins affects affinity key of data model. Test cluster should contain 1 client and 2 server nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8152) Forbid empty sql schema name
Pavel Kuznetsov created IGNITE-8152:
---
Summary: Forbid empty sql schema name
Key: IGNITE-8152
URL: https://issues.apache.org/jira/browse/IGNITE-8152
Project: Ignite
Issue Type: Bug
Reporter: Pavel Kuznetsov
Assignee: Vladimir Ozerov
Currently we allow empty schema name (quoted) in cache configuration
org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
{noformat}
When sqlSchema is not specified, quoted cacheName is used instead.
sqlSchema could not be an empty string. Has to be "\"\"" instead.
Params:
sqlSchema - Schema name for current cache according to SQL ANSI-99. Should not
be null.
{noformat}
Specifying schema \"\" results in empty string schema name.
No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
It's better to disallow usage of \"\" schema
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8151) ODBC driver should scheck schema on connection start
Pavel Kuznetsov created IGNITE-8151: --- Summary: ODBC driver should scheck schema on connection start Key: IGNITE-8151 URL: https://issues.apache.org/jira/browse/IGNITE-8151 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.5 Reporter: Pavel Kuznetsov Assignee: Igor Sapego We need to add validation of schema in odbc driver. 1) Need to update protocol to send schema with connection start. 2) Forbid empty sql id (\"\") as sql schema. see IGNITE-7743 for details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8100) jdbc getSchemas method could miss schemas for not started remote caches
Pavel Kuznetsov created IGNITE-8100:
---
Summary: jdbc getSchemas method could miss schemas for not started
remote caches
Key: IGNITE-8100
URL: https://issues.apache.org/jira/browse/IGNITE-8100
Project: Ignite
Issue Type: Bug
Reporter: Pavel Kuznetsov
On jdbc side we have
org.apache.ignite.internal.jdbc.thin.JdbcThinDatabaseMetadata#getSchemas(java.lang.String,
java.lang.String)
on the server side result is constructed by this:
{noformat}
for (String cacheName : ctx.cache().publicCacheNames()) {
for (GridQueryTypeDescriptor table : ctx.query().types(cacheName)) {
if (matches(table.schemaName(), schemaPtrn))
schemas.add(table.schemaName());
}
}
{noformat}
see
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler#getSchemas
This if we have not started cache(with a table) on some remote node, we will
miss that scheme.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7988) SQL: Upload benchmarks in mvcc mode
Pavel Kuznetsov created IGNITE-7988: --- Summary: SQL: Upload benchmarks in mvcc mode Key: IGNITE-7988 URL: https://issues.apache.org/jira/browse/IGNITE-7988 Project: Ignite Issue Type: Task Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov We need to know how does mvcc sql feature affect performance. dev branch: ignite-4191 cache atomicity mode: TRANSACTIONAL We need to adopt existing jdbc benchmarks to be able to run in mvcc. Only thin driver and native sql should be benchmarked. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7950) SQL: Add upload benchmarks for sql streamer feature
Pavel Kuznetsov created IGNITE-7950: --- Summary: SQL: Add upload benchmarks for sql streamer feature Key: IGNITE-7950 URL: https://issues.apache.org/jira/browse/IGNITE-7950 Project: Ignite Issue Type: Task Components: sql, yardstick Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov IGNITE-7253 introduces streaming mode. We need to update/create benchmarks to measure total upload time. Data model remains the same as in IGNITE-7531 : incrementaly generated long primary key, 5 long and 5 strings (contains random long value in string representation) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7715) If client cannot find dml entity in local storage, it should ask server for updates
Pavel Kuznetsov created IGNITE-7715: --- Summary: If client cannot find dml entity in local storage, it should ask server for updates Key: IGNITE-7715 URL: https://issues.apache.org/jira/browse/IGNITE-7715 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Kuznetsov Assignee: Vladimir Ozerov Assume we have n servers and at least 2 clients client 1 creates table (via thin driver) after that (in global time) client 2 tries to insert data in that table Currently, if client 2 didn't received from server that table is created, it rejects query execution But in this case client 2 could ask connected server for updates before rejection -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7710) copy from csv fails to find existing table (intermittently)
Pavel Kuznetsov created IGNITE-7710:
---
Summary: copy from csv fails to find existing table
(intermittently)
Key: IGNITE-7710
URL: https://issues.apache.org/jira/browse/IGNITE-7710
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Assignee: Kirill Shirokov
1) create table via new SqlFieldsQuery()
2) perform sql via thin driver
{{COPY FROM "/tmp/mydata.csv" INTO table_name FORMAT CSV;}}
client gets:
{{java.sql.SQLException: Table does not exist: TEST_UPLOAD
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:653)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:136)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinPreparedStatement.executeWithArguments(JdbcThinPreparedStatement.java:252)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinPreparedStatement.executeUpdate(JdbcThinPreparedStatement.java:96)
at
org.apache.ignite.yardstick.upload.CopyBenchmark.warmup(CopyBenchmark.java:67)
at
org.apache.ignite.yardstick.upload.AbstractUploadBenchmark.setUp(AbstractUploadBenchmark.java:50)
at
org.yardstickframework.BenchmarkDriverStartUp.main(BenchmarkDriverStartUp.java:130)}}
server gets
{{[2018-02-14 19:57:47,840][ERROR][client-connector-#47][JdbcRequestHandler]
Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
[schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=COPY FROM
"/tmp/warmup1971356426935
538953.csv" INTO TEST_UPLOAD (id, val_1, val_2, val_3, val_4, val_5, val_6,
val_7, val_8, val_9, val_10) FORMAT CSV;, args=[], stmtType=UPDATE_STMT_TYPE]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Table
does not exist: TEST_UPLOAD
at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.processBulkLoadCommand(DmlStatementsProcessor.java:1020)
at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.runNativeDmlStatement(DmlStatementsProcessor.java:992)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.tryQueryDistributedSqlFieldsNative(IgniteH2Indexing.java:1482)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1518)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2037)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2032)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2553)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2046)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1977)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:374)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:179)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:156)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:41)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7575) Concurrent updates of common keys cause silent wrong update count (intermittent issue)
Pavel Kuznetsov created IGNITE-7575: --- Summary: Concurrent updates of common keys cause silent wrong update count (intermittent issue) Key: IGNITE-7575 URL: https://issues.apache.org/jira/browse/IGNITE-7575 Project: Ignite Issue Type: Bug Components: sql Reporter: Pavel Kuznetsov Assignee: Alexander Paschenko In case of concurrent updates that affects some common keys we get silent wrong update count There's single table with two columns: key and val. I'm performing the same query that updates the same 1000 rows. Query doesn't update keys, it only increments val. In some cases I get expected exception "Failed to update some keys because they had been modified concurrently" or have 1000 updated rows In the other case, API tells me that more than 1000 rows updated. Expected result are exception or successfull update of 1000 rows see reproducer attached. It should be run against ```ignite/examples/src/main/java/org/apache/ignite/examples/ExampleNodeStartup.java``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
