[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] [Updated] (IGNITE-12043) Metrics: JMX exporter reports incorrect description.
[
https://issues.apache.org/jira/browse/IGNITE-12043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-12043:
-
Attachment: screenshoot.png
> 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
>Priority: Major
> Attachments: screenshoot.png
>
>
> 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] [Updated] (IGNITE-12043) Metrics: JMX exporter reports incorrect description.
[
https://issues.apache.org/jira/browse/IGNITE-12043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-12043:
-
Attachment: (was: Снимок экрана от 2019-08-05 17-25-49.png)
> 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
>Priority: Major
>
> 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-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] [Commented] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[ https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892773#comment-16892773 ] Pavel Kuznetsov commented on IGNITE-11997: -- [~amashenkov] would you please take a look at the patch? > 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 >Priority: Major > Labels: tests > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Commented] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[ https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889087#comment-16889087 ] Pavel Kuznetsov commented on IGNITE-11997: -- Rerun with deleted test: https://ci.ignite.apache.org/viewQueued.html?itemId=4357164 > 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 >Priority: Major > Labels: tests > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Comment Edited] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[
https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889060#comment-16889060
]
Pavel Kuznetsov edited comment on IGNITE-11997 at 7/19/19 5:49 PM:
---
Got feedback from [~amashenkov]. According to the IGNITE-3300 this test cannot
reproduce original issue because topology is stable and assignment is not
changed.
[~agoncharuk] could you please take a look at the
{{IgniteCacheQueriesLoadTest1.testQueries}}? We want to remove it at all.
was (Author: pkouznet):
Got feedback from [~amashenkov]. According to the IGNITE-3300 this test cannot
reproduce original issue because topology is stable and assignment is not
changed.
[~agoncharuk] can you please take a look at the
{{IgniteCacheQueriesLoadTest1.testQueries}}? We want to remove it at all.
> 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
>Priority: Major
> Labels: tests
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [Commented] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[
https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889060#comment-16889060
]
Pavel Kuznetsov commented on IGNITE-11997:
--
Got feedback from [~amashenkov]. According to the IGNITE-3300 this test cannot
reproduce original issue because topology is stable and assignment is not
changed.
[~agoncharuk] can you please take a look at the
{{IgniteCacheQueriesLoadTest1.testQueries}}? We want to remove it at all.
> 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
>Priority: Major
> Labels: tests
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [Commented] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[ https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889043#comment-16889043 ] Pavel Kuznetsov commented on IGNITE-11997: -- [~amashenkov] would you please take a look at the patch? > 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 >Priority: Major > Labels: tests > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Commented] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[ https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889042#comment-16889042 ] Pavel Kuznetsov commented on IGNITE-11997: -- Now test took 15 seconds: https://ci.ignite.apache.org/viewLog.html?buildId=4354867=IgniteTests24Java8_RunAll=testsInfo_IgniteTests24Java8=pull%2F6525%2Fhead > 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 >Priority: Major > Labels: tests > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Commented] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[ https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1600#comment-1600 ] Pavel Kuznetsov commented on IGNITE-11997: -- Bot visa is scheduled. > 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 >Priority: Major > Labels: tests > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Commented] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[ https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888799#comment-16888799 ] Pavel Kuznetsov commented on IGNITE-11997: -- Used "scale factor" tests feature to make dataset smaller in PR check runs. Original data set value will be used in nightly builds. > 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 >Priority: Major > Labels: tests > Time Spent: 10m > Remaining Estimate: 0h > > 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-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] [Comment Edited] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869334#comment-16869334
]
Pavel Kuznetsov edited comment on IGNITE-10690 at 6/21/19 9:33 AM:
---
[~amashenkov] would you please take a look at the patch?
Seems PDS test failures are unrelated (rerun PDS
https://ci.ignite.apache.org/viewQueued.html?itemId=4169272=queuedBuildOverviewTab)
was (Author: pkouznet):
[~amashenkov] would you please take a look at the patch?
Seems PDS test failures are unrelated
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
>
[jira] [Commented] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869334#comment-16869334
]
Pavel Kuznetsov commented on IGNITE-10690:
--
[~amashenkov] would you please take a look at the patch?
Seems PDS test failures are unrelated
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
>
[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] [Comment Edited] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868957#comment-16868957
]
Pavel Kuznetsov edited comment on IGNITE-10690 at 6/20/19 9:54 PM:
---
Deceided to leave "old" (JAVA_OBJECT) behaviour for the AI 2.x and support
java.time.Instant type as native type in the AI 3.0. See IGNITE-11938
was (Author: pkouznet):
Deceided to leave "old" (JAVA_OBJECT) behaviour for the AI 2.x and support
java.time.Instant type as native type in the AI 3.0
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
>
[jira] [Commented] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868957#comment-16868957
]
Pavel Kuznetsov commented on IGNITE-10690:
--
Deceided to leave "old" (JAVA_OBJECT) behaviour for the AI 2.x and support
java.time.Instant type as native type in the AI 3.0
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
>
[jira] [Commented] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868599#comment-16868599
]
Pavel Kuznetsov commented on IGNITE-10690:
--
asked bot for additional visa.
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3782)
> at
>
[jira] [Commented] (IGNITE-11919) Change message format for incompatible fields' types changes
[
https://issues.apache.org/jira/browse/IGNITE-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867541#comment-16867541
]
Pavel Kuznetsov commented on IGNITE-11919:
--
[~amashenkov] I've updated the test. I scheduled PDS Indexing suite run :
https://ci.ignite.apache.org/viewQueued.html?itemId=4155074
> Change message format for incompatible fields' types changes
>
>
> Key: IGNITE-11919
> URL: https://issues.apache.org/jira/browse/IGNITE-11919
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Follow this discussion thread to find out the reason for the change:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
> It's suggested to apply the following format:
> {code}
> ERROR: Type 'ClassName/TypeName' has a different/incorrect type
> for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
> That's an example of how it will look like:
> {code}
> ERROR: Type 'Person' has a different/incorrect type
> for field 'salary'. Expected 'double' but 'string' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11916) reorder fields for GridQueryKillResponse and GridQueryKillRequest
[ https://issues.apache.org/jira/browse/IGNITE-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-11916: - Affects Version/s: 2.8 > reorder fields for GridQueryKillResponse and GridQueryKillRequest > - > > Key: IGNITE-11916 > URL: https://issues.apache.org/jira/browse/IGNITE-11916 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: compatibility > > 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] [Updated] (IGNITE-11916) reorder fields for GridQueryKillResponse and GridQueryKillRequest
[ https://issues.apache.org/jira/browse/IGNITE-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-11916: - Labels: compatibility (was: ) > reorder fields for GridQueryKillResponse and GridQueryKillRequest > - > > Key: IGNITE-11916 > URL: https://issues.apache.org/jira/browse/IGNITE-11916 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: compatibility > > 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] [Updated] (IGNITE-11916) reorder fields for GridQueryKillResponse and GridQueryKillRequest
[ https://issues.apache.org/jira/browse/IGNITE-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-11916: - Component/s: sql > reorder fields for GridQueryKillResponse and GridQueryKillRequest > - > > Key: IGNITE-11916 > URL: https://issues.apache.org/jira/browse/IGNITE-11916 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > 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] [Updated] (IGNITE-11916) reorder fields for GridQueryKillResponse and GridQueryKillRequest
[ https://issues.apache.org/jira/browse/IGNITE-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-11916: - Ignite Flags: (was: Docs Required) > reorder fields for GridQueryKillResponse and GridQueryKillRequest > - > > Key: IGNITE-11916 > URL: https://issues.apache.org/jira/browse/IGNITE-11916 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: compatibility > > 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] [Commented] (IGNITE-11919) Change message format for incompatible fields' types changes
[
https://issues.apache.org/jira/browse/IGNITE-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866670#comment-16866670
]
Pavel Kuznetsov commented on IGNITE-11919:
--
[~sergey-chugunov] would you please take a look at the patch?
> Change message format for incompatible fields' types changes
>
>
> Key: IGNITE-11919
> URL: https://issues.apache.org/jira/browse/IGNITE-11919
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Follow this discussion thread to find out the reason for the change:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
> It's suggested to apply the following format:
> {code}
> ERROR: Type 'ClassName/TypeName' has a different/incorrect type
> for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
> That's an example of how it will look like:
> {code}
> ERROR: Type 'Person' has a different/incorrect type
> for field 'salary'. Expected 'double' but 'string' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11919) Change message format for incompatible fields' types changes
[
https://issues.apache.org/jira/browse/IGNITE-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866626#comment-16866626
]
Pavel Kuznetsov edited comment on IGNITE-11919 at 6/18/19 2:03 PM:
---
As [~sergey-chugunov] added we also need to recommend to delete the
"binary_meta" directory which contains info about binary fields.
We need to add typeId info as well
was (Author: pkouznet):
As [~sergey-chugunov] added we also need to recommend to delete the
"binary_meta" directory which contains info about binary fields.
> Change message format for incompatible fields' types changes
>
>
> Key: IGNITE-11919
> URL: https://issues.apache.org/jira/browse/IGNITE-11919
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
>
> Follow this discussion thread to find out the reason for the change:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
> It's suggested to apply the following format:
> {code}
> ERROR: Type 'ClassName/TypeName' has a different/incorrect type
> for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
> That's an example of how it will look like:
> {code}
> ERROR: Type 'Person' has a different/incorrect type
> for field 'salary'. Expected 'double' but 'string' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11919) Change message format for incompatible fields' types changes
[
https://issues.apache.org/jira/browse/IGNITE-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866626#comment-16866626
]
Pavel Kuznetsov commented on IGNITE-11919:
--
As [~sergey-chugunov] added we also need to recommend to delete the
"binary_meta" directory which contains info about binary fields.
> Change message format for incompatible fields' types changes
>
>
> Key: IGNITE-11919
> URL: https://issues.apache.org/jira/browse/IGNITE-11919
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
>
> Follow this discussion thread to find out the reason for the change:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
> It's suggested to apply the following format:
> {code}
> ERROR: Type 'ClassName/TypeName' has a different/incorrect type
> for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
> That's an example of how it will look like:
> {code}
> ERROR: Type 'Person' has a different/incorrect type
> for field 'salary'. Expected 'double' but 'string' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11919) Change message format for incompatible fields' types changes
[
https://issues.apache.org/jira/browse/IGNITE-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov reassigned IGNITE-11919:
Assignee: Pavel Kuznetsov
> Change message format for incompatible fields' types changes
>
>
> Key: IGNITE-11919
> URL: https://issues.apache.org/jira/browse/IGNITE-11919
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
>
> Follow this discussion thread to find out the reason for the change:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
> It's suggested to apply the following format:
> {code}
> ERROR: Type 'ClassName/TypeName' has a different/incorrect type
> for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
> That's an example of how it will look like:
> {code}
> ERROR: Type 'Person' has a different/incorrect type
> for field 'salary'. Expected 'double' but 'string' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11918) extend test coverage for KILL QUERY
[ https://issues.apache.org/jira/browse/IGNITE-11918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866469#comment-16866469 ] Pavel Kuznetsov commented on IGNITE-11918: -- [~amashenkov] would you please take a look at the patch? > extend test coverage for KILL QUERY > --- > > Key: IGNITE-11918 > URL: https://issues.apache.org/jira/browse/IGNITE-11918 > Project: Ignite > Issue Type: Test > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Commented] (IGNITE-11916) reorder fields for GridQueryKillResponse and GridQueryKillRequest
[ https://issues.apache.org/jira/browse/IGNITE-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866466#comment-16866466 ] Pavel Kuznetsov commented on IGNITE-11916: -- [~amashenkov] Would you please take a look at the patch? > 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 >Priority: Major > > 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] [Updated] (IGNITE-11918) extend test coverage for KILL QUERY
[ https://issues.apache.org/jira/browse/IGNITE-11918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-11918: - Component/s: sql > extend test coverage for KILL QUERY > --- > > Key: IGNITE-11918 > URL: https://issues.apache.org/jira/browse/IGNITE-11918 > Project: Ignite > Issue Type: Test > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Updated] (IGNITE-11918) extend test coverage for KILL QUERY
[ https://issues.apache.org/jira/browse/IGNITE-11918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-11918: - Labels: test (was: ) > extend test coverage for KILL QUERY > --- > > Key: IGNITE-11918 > URL: https://issues.apache.org/jira/browse/IGNITE-11918 > Project: Ignite > Issue Type: Test > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Commented] (IGNITE-11918) extend test coverage for KILL QUERY
[ https://issues.apache.org/jira/browse/IGNITE-11918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865588#comment-16865588 ] Pavel Kuznetsov commented on IGNITE-11918: -- updated code style https://ci.ignite.apache.org/viewLog.html?buildId=4140336; > 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 >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Commented] (IGNITE-11918) extend test coverage for KILL QUERY
[ https://issues.apache.org/jira/browse/IGNITE-11918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864173#comment-16864173 ] Pavel Kuznetsov commented on IGNITE-11918: -- updated, rerun: https://ci.ignite.apache.org/viewQueued.html?itemId=4118730 > 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 >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Commented] (IGNITE-11918) extend test coverage for KILL QUERY
[ https://issues.apache.org/jira/browse/IGNITE-11918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863481#comment-16863481 ] Pavel Kuznetsov commented on IGNITE-11918: -- tests run https://ci.ignite.apache.org/viewQueued.html?itemId=4113648 > 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 >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > 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-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] [Commented] (IGNITE-11916) reorder fields for GridQueryKillResponse and GridQueryKillRequest
[ https://issues.apache.org/jira/browse/IGNITE-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863384#comment-16863384 ] Pavel Kuznetsov commented on IGNITE-11916: -- Test run : https://ci.ignite.apache.org/viewQueued.html?itemId=4112673 > 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 >Priority: Major > > 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-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] [Commented] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840526#comment-16840526
]
Pavel Kuznetsov commented on IGNITE-11837:
--
[~nick_di] Sure. If you have any questions - join us on the user list:
https://ignite.apache.org/community/resources.html#mail-lists
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
> {code}
> but that seems wrong as I get exception:
> {code}
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840426#comment-16840426
]
Pavel Kuznetsov commented on IGNITE-11837:
--
[~nick_di]
>Does the client reconnect to another node if the node which is connected
>initially goes down?
I've asked author: Yes it does. If initial node went down, client reconnects to
other node on the next request (any Client's api call).
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
> {code}
> but that seems wrong as I get exception:
> {code}
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839568#comment-16839568
]
Pavel Kuznetsov edited comment on IGNITE-11837 at 5/14/19 3:45 PM:
---
[~nick_di]
I understood that this issue is about "laziness" thing, e.g. you expect that
Client should fail at first api call, not at the moment of
{{Ignition.startClient(...)}}. Correct me if I'm wrong.
> What is the point specifying many hosts in client configuration as if the
> client hit stopped node it will fail? Isn't there to mechanism to try another
> host if one is down?
There is no point, this is the bug (IGNITE-11599) :) It have already been fixed
and targeted to Ignite 2.8
You're wellcome :)
was (Author: pkouznet):
[~nick_di]
I understood that this issue is about "laziness" thing, e.g. you expect that
Client should fail at first api call, not at the moment of
{{Ignition.startClient(...)}}. Correct me if I'm wrong.
> What is the point specifying many hosts in client configuration as if the
> client hit stopped node it will fail? Isn't there to mechanism to try another
> host if one is down?
There is no point, this is the bug (IGNITE-11599) :) It have already been fixed
and targeted to Ignite 2.8
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
> {code}
> but that seems wrong as I get exception:
> {code}
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839568#comment-16839568
]
Pavel Kuznetsov commented on IGNITE-11837:
--
[~nick_di]
I understood that this issue is about "laziness" thing, e.g. you expect that
Client should fail at first api call, not at the moment of
{{Ignition.startClient(...)}}. Correct me if I'm wrong.
> What is the point specifying many hosts in client configuration as if the
> client hit stopped node it will fail? Isn't there to mechanism to try another
> host if one is down?
There is no point, this is the bug (IGNITE-11599) :) It have already been fixed
and targeted to Ignite 2.8
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
> {code}
> but that seems wrong as I get exception:
> {code}
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-11837:
-
Description:
According to java doc:
in org.apache.ignite.Ignition
{code:java}
/**
* Initializes new instance of \{@link IgniteClient}.
*
* Server connection will be lazily initialized when first required.
*
* @param cfg Thin client configuration.
* @return Successfully opened thin client connection.
*/
public static IgniteClient startClient(ClientConfiguration cfg)
{code}
{code}
but that seems wrong as I get exception:
Exception in thread "main" org.apache.ignite.client.ClientConnectionException:
Ignite cluster is unavailable
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
at
org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.(Socket.java:434)
at java.net.Socket.(Socket.java:211)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
org.apache.ignite.Ignition.startClient(Ignition.java:586)
{code}
was:
According to java doc:
in org.apache.ignite.Ignition
{code:java}
/**
* Initializes new instance of \{@link IgniteClient}.
*
* Server connection will be lazily initialized when first required.
*
* @param cfg Thin client configuration.
* @return Successfully opened thin client connection.
*/
public static IgniteClient startClient(ClientConfiguration cfg)
\{code}
{code}
but that seems wrong as I get exception:
Exception in thread "main" org.apache.ignite.client.ClientConnectionException:
Ignite cluster is unavailable
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
at
org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.(Socket.java:434)
at java.net.Socket.(Socket.java:211)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
org.apache.ignite.Ignition.startClient(Ignition.java:586)
\{code}
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param
[jira] [Updated] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-11837:
-
Description:
According to java doc:
in org.apache.ignite.Ignition
{code:java}
/**
* Initializes new instance of \{@link IgniteClient}.
*
* Server connection will be lazily initialized when first required.
*
* @param cfg Thin client configuration.
* @return Successfully opened thin client connection.
*/
public static IgniteClient startClient(ClientConfiguration cfg)
{code}
but that seems wrong as I get exception:
{code}
Exception in thread "main" org.apache.ignite.client.ClientConnectionException:
Ignite cluster is unavailable
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
at
org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.(Socket.java:434)
at java.net.Socket.(Socket.java:211)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
org.apache.ignite.Ignition.startClient(Ignition.java:586)
{code}
was:
According to java doc:
in org.apache.ignite.Ignition
{code:java}
/**
* Initializes new instance of \{@link IgniteClient}.
*
* Server connection will be lazily initialized when first required.
*
* @param cfg Thin client configuration.
* @return Successfully opened thin client connection.
*/
public static IgniteClient startClient(ClientConfiguration cfg)
{code}
{code}
but that seems wrong as I get exception:
Exception in thread "main" org.apache.ignite.client.ClientConnectionException:
Ignite cluster is unavailable
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
at
org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.(Socket.java:434)
at java.net.Socket.(Socket.java:211)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
org.apache.ignite.Ignition.startClient(Ignition.java:586)
{code}
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin
[jira] [Updated] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-11837:
-
Description:
According to java doc:
in org.apache.ignite.Ignition
{code:java}
/**
* Initializes new instance of \{@link IgniteClient}.
*
* Server connection will be lazily initialized when first required.
*
* @param cfg Thin client configuration.
* @return Successfully opened thin client connection.
*/
public static IgniteClient startClient(ClientConfiguration cfg)
\{code}
{code}
but that seems wrong as I get exception:
Exception in thread "main" org.apache.ignite.client.ClientConnectionException:
Ignite cluster is unavailable
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
at
org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.(Socket.java:434)
at java.net.Socket.(Socket.java:211)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
org.apache.ignite.Ignition.startClient(Ignition.java:586)
\{code}
was:
According to java doc:
in org.apache.ignite.Ignition
/**
* Initializes new instance of \{@link IgniteClient}.
*
* Server connection will be lazily initialized when first required.
*
* @param cfg Thin client configuration.
* @return Successfully opened thin client connection.
*/
public static IgniteClient startClient(ClientConfiguration cfg)
but that seems wrong as I get exception:
Exception in thread "main" org.apache.ignite.client.ClientConnectionException:
Ignite cluster is unavailable
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
at
org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.(Socket.java:434)
at java.net.Socket.(Socket.java:211)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
org.apache.ignite.Ignition.startClient(Ignition.java:586)
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
>
[jira] [Updated] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-11837:
-
Labels: javadoc (was: )
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
>
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
>
> but that seems wrong as I get exception:
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839330#comment-16839330
]
Pavel Kuznetsov commented on IGNITE-11837:
--
Javadoc is outdated. In early dev versions of the thin client connection setup
was lazy, but on the review it changed.
I've made a patch that removes misleading javadoc.
[~nick_di] thanks for the report!
[~jooger], would you please check my patch?
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> According to java doc:
> in org.apache.ignite.Ignition
>
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
>
> but that seems wrong as I get exception:
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838824#comment-16838824
]
Pavel Kuznetsov commented on IGNITE-10690:
--
[~jooger] , [~tledkov-gridgain] would you please take a look at the patch ?
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
>
[jira] [Commented] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838823#comment-16838823
]
Pavel Kuznetsov commented on IGNITE-10690:
--
Deceided only fix for the java.time.Instant type.
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3782)
> at
>
[jira] [Updated] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-10690:
-
Description:
This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
Ignite 2.7 and H2 version 1.4.197, and it is now broken.
I am using spring-data with a repository defined like this:
{{@RepositoryConfig(cacheName = "myObjectCache")}}
{{interface MyObjectRepository extends IgniteRepository {}}
{{ ...}}
{{}}}
If SomeObject has a field of type Instant, I get an IgniteCheckedException when
inserting the object into the repository.
This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
1.4.197, they changed the way Instant fields are mapped to the underlying data
type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT, but
now are mapped to Value.TIMESTAMP_TZ (see
org.h2.value.DataType.getTypeFromClass(Class x)).
When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
TIMESTAMP_TZ, and it throws IgniteCheckedException. See
GridH2RowDescriptor.wrap(Object, int).
Here is the relevant part of the stack trace:
{code}
org.h2.message.DbException: General error: "class
org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
value=2018-12-14T13:07:30.982Z]" [5-197]
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:307)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
at
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3782)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3782)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedContext.commitTxAsync(GridCacheSharedContext.java:1028)
at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.commit(TransactionProxyImpl.java:297)
at
org.apache.ignite.transactions.spring.SpringTransactionManager.doCommit(SpringTransactionManager.java:435)
at
[jira] [Commented] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16830602#comment-16830602
]
Pavel Kuznetsov commented on IGNITE-10690:
--
Issue was in that H2 said type is supported, but Ignite didn't support this
type. Made changes that any unsupported type is treated as java object. Added
smoke test.
[~tledkov-gridgain] would you please do a first review?
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
>
[jira] [Comment Edited] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814801#comment-16814801
]
Pavel Kuznetsov edited comment on IGNITE-11563 at 4/29/19 4:07 PM:
---
bug is that we use {{BPlusTree#findOne}} that has the same issue with
BigDecimal 1 and 1.0
https://github.com/apache/ignite/blob/af041491423cc2c91668de3790a81e3631bcfa5c/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/database/H2TreeIndex.java#L353
UPD: It's a partition pruning issue: partition is based on the hash, but
BigDecimals 1.0 and 1 have different hashes, so partition number is bad and
filter used in the H2TreeIndex is invalid too. For the replicated caches that
filter is not used.
was (Author: pkouznet):
bug is that we use {{BPlusTree#findOne}} that has the same issue with
BigDecimal 1 and 1.0
https://github.com/apache/ignite/blob/af041491423cc2c91668de3790a81e3631bcfa5c/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/database/H2TreeIndex.java#L353
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827050#comment-16827050
]
Pavel Kuznetsov commented on IGNITE-10690:
--
Let's add some debug info. I've modified one of SpringData tests to reproduce
the issue. I see QueryEntity created:
{code}
[keyType=java.lang.Integer,
valType=org.apache.ignite.springdata.misc.Person,
keyFieldName=null,
valueFieldName=null,
fields=LinkedHashMap
{
firstName=java.lang.String,
secondName=java.time.Instant
},
keyFields=HashSet [],
aliases=HashMap {firstName=FIRSTNAME, secondName=SECONDNAME},
idxs=LinkedList
[
QueryIndex [name=PERSON_SECONDNAME_IDX, fields=LinkedHashMap
{secondName=true}, type=SORTED, inlineSize=-1],
QueryIndex [name=PERSON_FIRSTNAME_IDX, fields=LinkedHashMap
{firstName=true}, type=SORTED, inlineSize=-1]
],
tableName=PERSON]
{code}
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
>
[jira] [Assigned] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov reassigned IGNITE-10690:
Assignee: Pavel Kuznetsov
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3782)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
>
[jira] [Commented] (IGNITE-11470) Views don't show in Dbeaver
[
https://issues.apache.org/jira/browse/IGNITE-11470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826061#comment-16826061
]
Pavel Kuznetsov commented on IGNITE-11470:
--
7) I would add {{@Nullable}} annotation to
{{org.apache.ignite.internal.processors.query.TableInformation#affinityKeyColumn()}}.
Doc could be more clear, if we added what "is not applicable" mean: "In case
of affinity key is the same as _KEY"
> Views don't show in Dbeaver
> ---
>
> Key: IGNITE-11470
> URL: https://issues.apache.org/jira/browse/IGNITE-11470
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> At Database navigator tab we can see no a views. As of now we should see at
> least SQL system views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11470) Views don't show in Dbeaver
[
https://issues.apache.org/jira/browse/IGNITE-11470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825444#comment-16825444
]
Pavel Kuznetsov commented on IGNITE-11470:
--
3.1) Discussable: Similar thing for the {{JdbcMetaTablesRequest#readBinary}}:
in case old client + new server we just change behaviour - we start returning
extra "tables" meta for type "VIEW". Users are unable to filter out these
tables. So here we should do the decision, for ald clients what we do 1. Always
return "TABLE"s + "VIEW"s 2. Return only "TABLES" and never "VIEW"s.
3.2) Suggestion: in {{JdbcThinDatabaseMetadata#getTables}} should we throw an
sql exception in case of unsupported type is specified?
4)Minor: {{ColumnInformation}} - would you please add info about special values
for the {{precision}} and {{scale}} (in case column is not a decimal type)?
5)Minor: You've modified return type of the
{{org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler#dispatchBatchOrdered}}
which always returns {{null}}, is it better to move this type to {{void}}
(with {{executeBatchOrdered}})?
6)Question:
{code:java}
CacheGroupDescriptor cacheGrpDesc =
ctx.cache().cacheGroupDescriptors().get(cacheGrpId);
// We should skip table in case in case regarding cache group has been
if (cacheGrpDesc == null)
return null;
{code}
I really didn't know about this, would you please share knowledge, in what
cases we could get this cache group descriptor == {{null}}? Would you point me
to the test case?
> Views don't show in Dbeaver
> ---
>
> Key: IGNITE-11470
> URL: https://issues.apache.org/jira/browse/IGNITE-11470
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> At Database navigator tab we can see no a views. As of now we should see at
> least SQL system views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11470) Views don't show in Dbeaver
[
https://issues.apache.org/jira/browse/IGNITE-11470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825117#comment-16825117
]
Pavel Kuznetsov edited comment on IGNITE-11470 at 4/24/19 6:20 PM:
---
Hello, [~jooger]!
Here is my first part of comments:
1) {{org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata#getTables}} Seems we
need to add {{TYPE_VIEW}} check. If we are fetching only VIEWS, we get empty
result set.
1.1) Optional: we import {{TYPE_TABLE}} and {{TYPE_VIEW}} from Jdbc thin
metadata to jdbc v2 one. Is it better to move these types to common jdbc utils?
2) {{org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata#getTableTypes}} :
We expect one column in the result and two rows, so we should replace this (one
row and two columns)
{code:java}
Collections.singletonList("TABLE_TYPE"),
//...
Collections.singletonList(Arrays.asList(TYPE_TABLE, TYPE_VIEW))
{code}
With this:
{code:java}
asList(singletonList(TYPE_TABLE), singletonList(TYPE_VIEW) )
{code}
Would you please check same case for jdbc thin?
3) I think we should provide default value "TABLE" for the
{{org.apache.ignite.internal.processors.odbc.jdbc.JdbcTableMeta#tblType}}.
Review the case: new driver is connected to the old server. Driver side will
get {{null}} as a TABLE_TYPE
was (Author: pkouznet):
Hello, [~jooger]!
Here is my first part of comments:
1) {{org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata#getTables}} Seems we
need to add {{TYPE_VIEW}} check. If we are fetching only VIEWS, we get empty
result set.
1.1) Optional: we import {{TYPE_TABLE}} and {{TYPE_VIEW}} from Jdbc thin
metadata to jdbc v2 one. Is it better to move these types to common jdbc utils?
2) {{org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata#getTableTypes}} :
We expect one column in the result and two rows, so we should replace this (one
row and two columns)
{code:java}
Collections.singletonList("TABLE_TYPE"),
//...
Collections.singletonList(Arrays.asList(TYPE_TABLE, TYPE_VIEW))
{code}
With this:
{code:java}
asList(singletonList(TYPE_TABLE), singletonList(TYPE_VIEW) )
{code}
Would you please check same case for jdbc thin?
3) I think we should provide default value "TABLE" for the
{{org.apache.ignite.internal.processors.odbc.jdbc.JdbcTableMeta#tblType}}.
Review the case: new driver is connected to the old server.
> Views don't show in Dbeaver
> ---
>
> Key: IGNITE-11470
> URL: https://issues.apache.org/jira/browse/IGNITE-11470
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> At Database navigator tab we can see no a views. As of now we should see at
> least SQL system views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11470) Views don't show in Dbeaver
[
https://issues.apache.org/jira/browse/IGNITE-11470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825117#comment-16825117
]
Pavel Kuznetsov commented on IGNITE-11470:
--
Hello, [~jooger]!
Here is my first part of comments:
1) {{org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata#getTables}} Seems we
need to add {{TYPE_VIEW}} check. If we are fetching only VIEWS, we get empty
result set.
1.1) Optional: we import {{TYPE_TABLE}} and {{TYPE_VIEW}} from Jdbc thin
metadata to jdbc v2 one. Is it better to move these types to common jdbc utils?
2) {{org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata#getTableTypes}} :
We expect one column in the result and two rows, so we should replace this (one
row and two columns)
{code:java}
Collections.singletonList("TABLE_TYPE"),
//...
Collections.singletonList(Arrays.asList(TYPE_TABLE, TYPE_VIEW))
{code}
With this:
{code:java}
asList(singletonList(TYPE_TABLE), singletonList(TYPE_VIEW) )
{code}
Would you please check same case for jdbc thin?
3) I think we should provide default value "TABLE" for the
{{org.apache.ignite.internal.processors.odbc.jdbc.JdbcTableMeta#tblType}}.
Review the case: new driver is connected to the old server.
> Views don't show in Dbeaver
> ---
>
> Key: IGNITE-11470
> URL: https://issues.apache.org/jira/browse/IGNITE-11470
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> At Database navigator tab we can see no a views. As of now we should see at
> least SQL system views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11666) C++ : remove macro usages in the examples
[
https://issues.apache.org/jira/browse/IGNITE-11666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821248#comment-16821248
]
Pavel Kuznetsov commented on IGNITE-11666:
--
[~isapego], In functional point, changes are ok.
Styling :
I see you removed redundant "ignite" namespace specification. Though I
personally prefer to use full namespaces (or typedefs), would you please make
other places "ignite::examples::" unified. Also
{{examples/include/ignite/examples/organization.h}} uses full namespace path as
well.
Where we can find doc, that tells us which functions we must to implement to
define binary format for the new struct?
Since it is an example I would leave comment or reference to the doc. Maybe
binary object example? Other example that explains BinaryType<> convention in
details? (Nice-to-have)
> C++ : remove macro usages in the examples
> -
>
> Key: IGNITE-11666
> URL: https://issues.apache.org/jira/browse/IGNITE-11666
> Project: Ignite
> Issue Type: Improvement
> Components: examples, platforms
>Reporter: Pavel Kuznetsov
>Assignee: Igor Sapego
>Priority: Major
> Labels: c++, examples
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently c++ examples are using internal macros. For example to specify how
> to serialize/deserialize user's c++ structs.
> {code:c++}
> 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] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816194#comment-16816194
]
Pavel Kuznetsov commented on IGNITE-11563:
--
One more point to think:
guess we decided to store internally decimal values with any scale. We have
column with type {{decimal(19,5)}} , but in cache we store decimal with scale =
7. We perform select returning this value - what should we do in this case:
return value with greater scale (7) that specified in the type (5)? Or should
we round it ( to scale = 5)? Jdbc spec says we should return full *precision*
value.
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814819#comment-16814819
]
Pavel Kuznetsov commented on IGNITE-11563:
--
So we cannot find the value in the cache except full scan which is slow for the
PK lookup.
What I think we can do
Let's treat scale of the decimal part of the column type: If user defined
column type as {{DECIMAL(19, 5)}} we should store internally decimal number
with 5 digits after point.
as [1]:
{quote}For decimal and numeric data types, SQL Server considers each
combination of precision and scale as a different data type. For example,
decimal(5,5) and decimal(5,0) are considered different data types.{quote}
If user specified value with more scale digits, let's raise error, as H2 does.
MsSQL uses rounding by default, though. But it rises error if special system
property is set (also see [1])
What to do with the decimal keys, that have been inserted using cache api -
open question. In this case full scans would include some "weird" records.
Could we forbid such puts (with different scale)? Another option - is to add
filter condition in the indexes.
[1]
https://docs.microsoft.com/en-us/sql/t-sql/data-types/decimal-and-numeric-transact-sql?view=sql-server-2017
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814801#comment-16814801
]
Pavel Kuznetsov commented on IGNITE-11563:
--
bug is that we use {{BPlusTree#findOne}} that has the same issue with
BigDecimal 1 and 1.0
https://github.com/apache/ignite/blob/af041491423cc2c91668de3790a81e3631bcfa5c/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/database/H2TreeIndex.java#L353
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813563#comment-16813563
]
Pavel Kuznetsov commented on IGNITE-11563:
--
Fast update conversion is fixed. Got another delete issue: if double (or
string) argument is passed, only in partitioned mode, delete operation could do
nothing.
{code:java}
execute("CREATE TABLE TEST_TABLE (" +
"ID DECIMAL(19,1)," +
"VALUE VARCHAR2(255 CHAR)," +
"PRIMARY KEY (ID))with \"template=partitioned\"");
execute("INSERT INTO TEST_TABLE (id, value) VALUES (1, 'this row should
be deleted'), (2, 'value')");
Object one = 1.0d;
execute("DELETE FROM TEST_TABLE WHERE ID = ? AND VALUE = 'this row
should be deleted'", one);
List> expRows = Collections.singletonList(asList(new
BigDecimal(2), "value"));
assertEqualsCollections("Argument of class " +
one.getClass().getSimpleName() + " is converted incorrectly",
expRows, execute("SELECT * FROM TEST_TABLE ORDER BY ID"));
{code}
research shown that select generated for this delete also doesn't work.
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9650) java.math.BigDecimal / .Net decimal columns shown as OTHER in JDBC Thin metadata
[ https://issues.apache.org/jira/browse/IGNITE-9650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov reassigned IGNITE-9650: --- Assignee: Pavel Kuznetsov > java.math.BigDecimal / .Net decimal columns shown as OTHER in JDBC Thin > metadata > > > Key: IGNITE-9650 > URL: https://issues.apache.org/jira/browse/IGNITE-9650 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Assignee: Pavel Kuznetsov >Priority: Major > Attachments: Screenshot_20180919_200457.png > > > Subj. > According to our docs it should be DECIMAL: > https://apacheignite-sql.readme.io/docs/data-types#section-decimal > DECIMAL > Possible values: Data type with fixed precision and scale. > Mapped to: > Java/JDBC: java.math.BigDecimal > .NET/C#: decimal > C/C++: ignite::Decimal > ODBC: SQL_DECIMAL > But it turns to be mapped to OTHER (see screenshot) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10745) SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
[
https://issues.apache.org/jira/browse/IGNITE-10745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov reassigned IGNITE-10745:
Assignee: Alexander Lapin
> 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, sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexander Lapin
>Priority: Minor
> Labels: jdbc, metadata, sql
>
> 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}
> 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 columns by pattern - 2 or 1 and so on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811995#comment-16811995
]
Pavel Kuznetsov commented on IGNITE-11563:
--
nb: for the query
{code}
DELETE FROM TEST_TABLE WHERE ID = ? AND VALUE = 'this row should be deleted'
{code}
Fast delete is not used, but it should.
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810932#comment-16810932
]
Pavel Kuznetsov commented on IGNITE-11588:
--
[~vozerov] done ^
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809791#comment-16809791
]
Pavel Kuznetsov commented on IGNITE-11588:
--
Reverted unnecessary xml changes.
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11226) SQL: Remove GridQueryIndexing.prepareNativeStatement
[
https://issues.apache.org/jira/browse/IGNITE-11226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809240#comment-16809240
]
Pavel Kuznetsov commented on IGNITE-11226:
--
[~vozerov] Ok I've updated patch according to your comments
p2: Thanks, I forgot to update method signatures in the interface, fixed that.
Actually, in the methods themselves, we don't throw any exceptions, we rely on
the validation performed in the parser, which already sets
{{IgniteQueryErrorCode}} s. Should we catch them in the indexing and re-throw
with some other code?
p3: hm. Ok, I switched to {{IgniteCheckedException}} it means we hide original
reason (which is thrown by h2) from user. Is it ok?
> SQL: Remove GridQueryIndexing.prepareNativeStatement
>
>
> Key: IGNITE-11226
> URL: https://issues.apache.org/jira/browse/IGNITE-11226
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This method is the only leak of H2 internals to the outer code. Close
> analysis of code reveals that the only reason we have it is *JDBC metadata*.
> Need to create a method which will prepare metadata for a statement and
> return it as a detached object. Most probably we already have all necessary
> mechanics. This is more about refactoring.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807543#comment-16807543
]
Pavel Kuznetsov commented on IGNITE-7113:
-
p2 : added tests
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807156#comment-16807156
]
Pavel Kuznetsov commented on IGNITE-7113:
-
Current review points:
1) 2 [~vozerov] : given {{CREATE TABLE ... WITH "wrap_key=true,
key_type=java.lang.Integer"}}, currently we are ignoring user's wrap_key=true
because of sql type Integer. Is it ok, or should we issue parsing error?
2) need to add test for 1 val column, wrap_value=false and non-sql type.
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806952#comment-16806952
]
Pavel Kuznetsov edited comment on IGNITE-11563 at 4/1/19 4:28 PM:
--
This is not client-specific bug, reproducible using native sql. Key point is to
use sql positional parameters inside DELETE query.
Seems to be fast update issue.
was (Author: pkouznet):
This is not client-specific bug, reproducible using native sql. Key point is to
use sql positional parameters inside DELETE query.
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806952#comment-16806952
]
Pavel Kuznetsov commented on IGNITE-11563:
--
This is not client-specific bug, reproducible using native sql. Key point is to
use sql positional parameters inside DELETE query.
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806941#comment-16806941
]
Pavel Kuznetsov commented on IGNITE-11563:
--
Reproduced.
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806795#comment-16806795
]
Pavel Kuznetsov commented on IGNITE-11588:
--
hm, just noticed that Idea removes unused imports on commit - is that ok
https://github.com/apache/ignite/pull/6320/commits/78d63423ec13258205eef1946ece61bd1ddf5d5d
?
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806793#comment-16806793
]
Pavel Kuznetsov commented on IGNITE-11588:
--
> In the current patch we need to remove binary configuration
[~isapego], [~vozerov] done!
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806743#comment-16806743
]
Pavel Kuznetsov edited comment on IGNITE-11588 at 4/1/19 1:17 PM:
--
For history: Discussed patch with [~vozerov] and [~isapego] :
1) binary configuration is not required in c++ only cluster. For the mixed
cluster we need separated example (IGNITE-11665)
2) additionaly, we need to get rid of internal macros usages in the examples
(IGNITE-11666)
In the current patch we need to remove binary configuration
was (Author: pkouznet):
For history: Discussed patch with [~vozerov] and [~isapego] :
1) binary configuration is not required in c++ only cluster. For the mixed
cluster we need separated example (IGNITE-11665)
2) additionaly, we need to get rid of internal macros usages in the examples
(IGNITE-11666)
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11666) C++ : remove internal macro usages in the examples
[
https://issues.apache.org/jira/browse/IGNITE-11666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-11666:
-
Description:
Currently c++ examples are using internal macros. For example to specify how to
serialize/deserialize user's c++ structs.
{code:c++}
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}
was:
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}
> 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
>Priority: Major
> Labels: c++, examples
>
> Currently c++ examples are using internal macros. For example to specify how
> to serialize/deserialize user's c++ structs.
> {code:c++}
> 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] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806743#comment-16806743
]
Pavel Kuznetsov commented on IGNITE-11588:
--
For history: Discussed patch with [~vozerov] and [~isapego] :
1) binary configuration is not required in c++ only cluster. For the mixed
cluster we need separated example (IGNITE-11665)
2) additionaly, we need to get rid of internal macros usages in the examples
(IGNITE-11666)
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
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-11665) ODBC: Create example for query execution on mixed cluster
Pavel Kuznetsov created IGNITE-11665:
Summary: ODBC: Create example for query execution on mixed cluster
Key: IGNITE-11665
URL: https://issues.apache.org/jira/browse/IGNITE-11665
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Kuznetsov
We need to create c++ example that runs query with mixed cluster (contains
both c++ and java nodes).
As investigated in the IGNITE-11588 in this case xml configuration requires
additional setup for the binary configuration:
{code:xml}
...
{code}
Separated example is required because existing c++ query example works fine
without xml code above.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-6440) Flaky failures in DynamicColumnsAbstractConcurrentSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806724#comment-16806724
]
Pavel Kuznetsov edited comment on IGNITE-6440 at 4/1/19 12:56 PM:
--
Investigated. Currently Queries 2 doesn't fail due to DynamicColumns* tests in
master.
Also few random build logs doesn't contain "Found nodes from different
clusters" error message.
history:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Queries2=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
was (Author: pkouznet):
Investigated. Currently Queries 2 doesn't fail due to DynamicColumns* tests in
master.
Also few random build logs doesn't contain "Found nodes from different
clusters" error message.
> Flaky failures in DynamicColumnsAbstractConcurrentSelfTest
> --
>
> Key: IGNITE-6440
> URL: https://issues.apache.org/jira/browse/IGNITE-6440
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, sql-stability
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Multiple failures are observed in concrete implementations of
> {{DynamicColumnsAbstractConcurrentSelfTest}}. Specifically:
> {code}
> testQueryConsistencyMultithreaded
> testClientReconnect
> testConcurrentRebalance
> testCoordinatorChange
> testConcurrentPutRemove
> {code}
> Apparently there are some bugs in the test itself, as the following root
> causes could be observed in logs:
> {code}
> junit.framework.AssertionFailedError: Found nodes from different clusters,
> probable some test does not stop nodes
> [allNodes=[index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest3,
> index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest2,
> index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest1]]
> {code}
> {code}
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest$3.call(DynamicColumnsAbstractConcurrentSelfTest.java:565)
> at
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest$3.call(DynamicColumnsAbstractConcurrentSelfTest.java:560)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> Please see TeamCity, history of "Queries 2" suite in master branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6440) Flaky failures in DynamicColumnsAbstractConcurrentSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov resolved IGNITE-6440.
-
Resolution: Cannot Reproduce
> Flaky failures in DynamicColumnsAbstractConcurrentSelfTest
> --
>
> Key: IGNITE-6440
> URL: https://issues.apache.org/jira/browse/IGNITE-6440
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, sql-stability
>
> Multiple failures are observed in concrete implementations of
> {{DynamicColumnsAbstractConcurrentSelfTest}}. Specifically:
> {code}
> testQueryConsistencyMultithreaded
> testClientReconnect
> testConcurrentRebalance
> testCoordinatorChange
> testConcurrentPutRemove
> {code}
> Apparently there are some bugs in the test itself, as the following root
> causes could be observed in logs:
> {code}
> junit.framework.AssertionFailedError: Found nodes from different clusters,
> probable some test does not stop nodes
> [allNodes=[index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest3,
> index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest2,
> index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest1]]
> {code}
> {code}
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest$3.call(DynamicColumnsAbstractConcurrentSelfTest.java:565)
> at
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest$3.call(DynamicColumnsAbstractConcurrentSelfTest.java:560)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> Please see TeamCity, history of "Queries 2" suite in master branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6440) Flaky failures in DynamicColumnsAbstractConcurrentSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806724#comment-16806724
]
Pavel Kuznetsov commented on IGNITE-6440:
-
Investigated. Currently Queries 2 doesn't fail due to DynamicColumns* tests in
master.
Also few random build logs doesn't contain "Found nodes from different
clusters" error message.
> Flaky failures in DynamicColumnsAbstractConcurrentSelfTest
> --
>
> Key: IGNITE-6440
> URL: https://issues.apache.org/jira/browse/IGNITE-6440
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, sql-stability
>
> Multiple failures are observed in concrete implementations of
> {{DynamicColumnsAbstractConcurrentSelfTest}}. Specifically:
> {code}
> testQueryConsistencyMultithreaded
> testClientReconnect
> testConcurrentRebalance
> testCoordinatorChange
> testConcurrentPutRemove
> {code}
> Apparently there are some bugs in the test itself, as the following root
> causes could be observed in logs:
> {code}
> junit.framework.AssertionFailedError: Found nodes from different clusters,
> probable some test does not stop nodes
> [allNodes=[index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest3,
> index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest2,
> index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest1]]
> {code}
> {code}
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest$3.call(DynamicColumnsAbstractConcurrentSelfTest.java:565)
> at
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest$3.call(DynamicColumnsAbstractConcurrentSelfTest.java:560)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> Please see TeamCity, history of "Queries 2" suite in master branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806579#comment-16806579
]
Pavel Kuznetsov commented on IGNITE-7113:
-
[~tledkov-gridgain] would you please do a prelementary review?
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806258#comment-16806258
]
Pavel Kuznetsov commented on IGNITE-7113:
-
[~vozerov] would you please do first review?
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806257#comment-16806257
]
Pavel Kuznetsov commented on IGNITE-7113:
-
Another note: type "Integer" (without java.lang) is treated as custom type and
is not recommended to use.
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806246#comment-16806246
]
Pavel Kuznetsov commented on IGNITE-7113:
-
Note that validation of GeoSpatial types is not performed in this case
{code:java}
Class c = U.isJdkOrUnboxedPrimitive(res.keyTypeName()) ?
U.classForName(res.keyTypeName(), null, true) : null;
if (c != null && QueryUtils.isSqlType(c))
{code}
because Classes of geo type is neither jdk nor unboxed primitive. {{c == null}}
for all unboxed primitives if condition is always false.
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5962) Increase max length of index name
[ https://issues.apache.org/jira/browse/IGNITE-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804115#comment-16804115 ] Pavel Kuznetsov commented on IGNITE-5962: - [~vozerov] I've fixed typeId in case binary marshaller is not used. Note that in this case at validation we don't have access to the values class, so we expect the worst case: longest possible int. > Increase max length of index name > - > > Key: IGNITE-5962 > URL: https://issues.apache.org/jira/browse/IGNITE-5962 > Project: Ignite > Issue Type: Improvement > Components: general, sql >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Pavel Kuznetsov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > In https://issues.apache.org/jira/browse/IGNITE-5941 max index name length > was reduced from 768 to 256 bytes. If we need to support longer names, we > need to change format of metastore data pages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11226) SQL: Remove GridQueryIndexing.prepareNativeStatement
[ https://issues.apache.org/jira/browse/IGNITE-11226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803186#comment-16803186 ] Pavel Kuznetsov commented on IGNITE-11226: -- 1. Done 2. JDBC spec says nothing about prepared statement metadatas (result set and parameters) that contain multiple sql statements separated by ";" (script). H2 returns metadata of the first sql statement of the script. PostgreSql returns all the meta about all the parameters found in the script. (Thanks for checking) Mysql doesn't support multiple SELECT statements for the PreparedStatement and throws parsing error in this case. DML is allowed, returned meta about all the parameters. As we discussed, final point: - result set metadata for the multistatements and dml is null - parameters metadata about all the parameters of the multistatetment should be returned. added implementation notes to the PreparedStatemet implementations. > SQL: Remove GridQueryIndexing.prepareNativeStatement > > > Key: IGNITE-11226 > URL: https://issues.apache.org/jira/browse/IGNITE-11226 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Pavel Kuznetsov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > This method is the only leak of H2 internals to the outer code. Close > analysis of code reveals that the only reason we have it is *JDBC metadata*. > Need to create a method which will prepare metadata for a statement and > return it as a detached object. Most probably we already have all necessary > mechanics. This is more about refactoring. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov reassigned IGNITE-11588:
Assignee: Pavel Kuznetsov (was: Igor Sapego)
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802594#comment-16802594
]
Pavel Kuznetsov commented on IGNITE-11588:
--
Updated missed types in the example.
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Igor Sapego
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801238#comment-16801238
]
Pavel Kuznetsov commented on IGNITE-7113:
-
Found another problem: sometimes we don't box int -> Integer. Example:
org.apache.ignite.client.FunctionalTest#testCacheConfiguration
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801013#comment-16801013
]
Pavel Kuznetsov commented on IGNITE-11588:
--
Replacing partitioned cache mode with replicated fixes the issue, but in this
case we get example for distributedJoins feature meaningless.
I suggest to replace {{java.lang.Long}} cache key Type with the complex object
PersonKey(id, orgId) and mark orgId field as affinityKeyColumn in the ignite
xml configuration.
[~isapego] Would you please take a look at the branch {{ignite-11588-improved}}
I tried to do so, but had few troubles with de-serialization.
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Igor Sapego
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800865#comment-16800865
]
Pavel Kuznetsov commented on IGNITE-11588:
--
{code}
// Note that in this example we use custom affinity key for Person objects
// to ensure that all persons are collocated with their organizations.
{code}
Is this comment make sense in cpp query example?
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Igor Sapego
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798117#comment-16798117
]
Pavel Kuznetsov edited comment on IGNITE-7113 at 3/21/19 5:55 PM:
--
This fix breaks some existing tests in the dotnet.
{code:c#}
new QueryEntity(typeof(int), typeof(QueryPerson)) // keyType
evaluated to "java.lang.Integer"
{
Fields = new[]
{
new QueryField("age", "int"), // type remains
"int"
new QueryField("FullKey", "int"), // here too
new QueryField("FullVal", "QueryPerson")
},
KeyFieldName = "FullKey",
ValueFieldName = "FullVal"
}
{code}
Since we started to check that keyFieldType and the typeName of the individual
field are the same, this configuration fails to start.
I think It's a bug in .net: we should try to map individual field typename
(string) to java type.
was (Author: pkouznet):
This fix breaks some existing tests in the dotnet.
{code:csharp}
new QueryEntity(typeof(int), typeof(QueryPerson)) // keyType
evaluated to "java.lang.Integer"
{
Fields = new[]
{
new QueryField("age", "int"), // type remains
"int"
new QueryField("FullKey", "int"), // here too
new QueryField("FullVal", "QueryPerson")
},
KeyFieldName = "FullKey",
ValueFieldName = "FullVal"
}
{code}
Since we started to check that keyFieldType and the typeName of the individual
field are the same, this configuration fails to start.
I think It's a bug in .net: we should try to map individual field typename
(string) to java type.
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798117#comment-16798117
]
Pavel Kuznetsov commented on IGNITE-7113:
-
This fix breaks some existing tests in the dotnet.
{code:csharp}
new QueryEntity(typeof(int), typeof(QueryPerson)) // keyType
evaluated to "java.lang.Integer"
{
Fields = new[]
{
new QueryField("age", "int"), // type remains
"int"
new QueryField("FullKey", "int"), // here too
new QueryField("FullVal", "QueryPerson")
},
KeyFieldName = "FullKey",
ValueFieldName = "FullVal"
}
{code}
Since we started to check that keyFieldType and the typeName of the individual
field are the same, this configuration fails to start.
I think It's a bug in .net: we should try to map individual field typename
(string) to java type.
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ...
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797135#comment-16797135
]
Pavel Kuznetsov commented on IGNITE-7113:
-
let's re-run tests: https://ci.ignite.apache.org/viewLog.html?buildId=3362296;
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
