[jira] [Created] (IGNITE-6093) SQL: Add hints support
Vladimir Ozerov created IGNITE-6093:
---
Summary: SQL: Add hints support
Key: IGNITE-6093
URL: https://issues.apache.org/jira/browse/IGNITE-6093
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
We already have a lot of query hints. Unfortunately, none of them are supported
in the query itself, so we have to set them through {{SqlFieldsQuery}} setters
or connection string parameters (for ODBC and JDBC).
We need to learn H2 how to work with hints, and then apply it to our "Apache
Ignite" mode.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-5985) WebConsole: add generation of keyFields for queryEntity for multiple primary key
[
https://issues.apache.org/jira/browse/IGNITE-5985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-5985:
Assignee: Vasiliy Sisko (was: Alexey Kuznetsov)
Please rework new check box "exclude" -> "include".
And resubmit for review.
> WebConsole: add generation of keyFields for queryEntity for multiple primary
> key
>
>
> Key: IGNITE-5985
> URL: https://issues.apache.org/jira/browse/IGNITE-5985
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Vasiliy Sisko
> Fix For: 2.2
>
>
> For example, for table like
> {code:java}
> CREATE TABLE TABLE_NAME (
> KEY1 int NOT NULL,
> KEY2 int NOT NULL,
> VALUE int,
> PRIMARY KEY (KEY1,KEY2));
> {code}
> should be generated queryEntity like:
> {code:java}
>
>
>
> value="org.apache.ignite.examples.TableNameKey"/>
> value="org.apache.ignite.examples.TableName"/>
>
>
> key1
> key2
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5586) Visor CMD: Add possibility to activate/deactivate grid
[ https://issues.apache.org/jira/browse/IGNITE-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129917#comment-16129917 ] Vasiliy Sisko edited comment on IGNITE-5586 at 8/17/17 4:51 AM: Implemented possibility to activate/deactivate grid by Visor CMD *top* command. Implemented test for activation/deactivation of cluster from Visor CMD. was (Author: vsisko): Implemented test for activation/deactivation of cluster from Visor CMD. > Visor CMD: Add possibility to activate/deactivate grid > -- > > Key: IGNITE-5586 > URL: https://issues.apache.org/jira/browse/IGNITE-5586 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 2.1 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > Fix For: 2.2 > > > Extend top command to activate/deactivate grid. Wait fix IGNITE-5584. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5985) WebConsole: add generation of keyFields for queryEntity for multiple primary key
[
https://issues.apache.org/jira/browse/IGNITE-5985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-5985:
-
Fix Version/s: 2.2
> WebConsole: add generation of keyFields for queryEntity for multiple primary
> key
>
>
> Key: IGNITE-5985
> URL: https://issues.apache.org/jira/browse/IGNITE-5985
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>
> For example, for table like
> {code:java}
> CREATE TABLE TABLE_NAME (
> KEY1 int NOT NULL,
> KEY2 int NOT NULL,
> VALUE int,
> PRIMARY KEY (KEY1,KEY2));
> {code}
> should be generated queryEntity like:
> {code:java}
>
>
>
> value="org.apache.ignite.examples.TableNameKey"/>
> value="org.apache.ignite.examples.TableName"/>
>
>
> key1
> key2
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-5586) Visor CMD: Add possibility to activate/deactivate grid
[ https://issues.apache.org/jira/browse/IGNITE-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-5586: - Assignee: Alexey Kuznetsov (was: Vasiliy Sisko) Implemented test for activation/deactivation of cluster from Visor CMD. > Visor CMD: Add possibility to activate/deactivate grid > -- > > Key: IGNITE-5586 > URL: https://issues.apache.org/jira/browse/IGNITE-5586 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 2.1 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > Fix For: 2.2 > > > Extend top command to activate/deactivate grid. Wait fix IGNITE-5584. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null
[
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129813#comment-16129813
]
Zhang Yuan commented on IGNITE-5994:
[~sharpler] I have asked for permission in dev-list and got reply that I have
been add to the list.
> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
> Labels: newbie
> Attachments: IgniteCacheSelfTest.java
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but
> the IgniteInternalCache.invokeAsync().get() can return the null in case when
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-6037) Ignite 2.1 features changes on the website
[ https://issues.apache.org/jira/browse/IGNITE-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg resolved IGNITE-6037. - Resolution: Fixed > Ignite 2.1 features changes on the website > -- > > Key: IGNITE-6037 > URL: https://issues.apache.org/jira/browse/IGNITE-6037 > Project: Ignite > Issue Type: Bug > Components: website >Reporter: Dmitriy Setrakyan >Assignee: Prachi Garg > Labels: site > > Make the following changes to Features: > # add What is Memory Centric > # change Persistence to either "Native Persistence" or "Persistent Store" > # change More to black font and rename to "More..." > # add Beta symbol to Machine Learning -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-6037) Ignite 2.1 features changes on the website
[ https://issues.apache.org/jira/browse/IGNITE-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg closed IGNITE-6037. --- > Ignite 2.1 features changes on the website > -- > > Key: IGNITE-6037 > URL: https://issues.apache.org/jira/browse/IGNITE-6037 > Project: Ignite > Issue Type: Bug > Components: website >Reporter: Dmitriy Setrakyan >Assignee: Prachi Garg > Labels: site > > Make the following changes to Features: > # add What is Memory Centric > # change Persistence to either "Native Persistence" or "Persistent Store" > # change More to black font and rename to "More..." > # add Beta symbol to Machine Learning -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6092) Bulk Inserts are not Supported
Denis Magda created IGNITE-6092:
---
Summary: Bulk Inserts are not Supported
Key: IGNITE-6092
URL: https://issues.apache.org/jira/browse/IGNITE-6092
Project: Ignite
Issue Type: New Feature
Reporter: Denis Magda
Assignee: Vladimir Ozerov
Priority: Critical
Presently the bulk inserts like these are not supported by Ignite's SQL engine:
{code}
INSERT INTO City (id, name)
VALUES (1, 'Forest Hill'),
(2, "Denver"),
(3, "St. Petersburg")
INSERT INTO Person (id, name, city_id)
VALUES (1, 'John Doe', 3),
(2, "Jane Roe", 2),
(3, "Mary Major", 1),
(4, "Richard Miles", 2)
{code}
Let's plan to support them for the nearest release. I've used DBeaver tool to
validate the statements above:
https://apacheignite-tools.readme.io/docs/dbeaver
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6092) Bulk Inserts are not Supported
[
https://issues.apache.org/jira/browse/IGNITE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6092:
Affects Version/s: 2.1
> Bulk Inserts are not Supported
> ---
>
> Key: IGNITE-6092
> URL: https://issues.apache.org/jira/browse/IGNITE-6092
> Project: Ignite
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.2
>
>
> Presently the bulk inserts like these are not supported by Ignite's SQL
> engine:
> {code}
> INSERT INTO City (id, name)
> VALUES (1, 'Forest Hill'),
>(2, "Denver"),
>(3, "St. Petersburg")
> INSERT INTO Person (id, name, city_id)
> VALUES (1, 'John Doe', 3),
>(2, "Jane Roe", 2),
>(3, "Mary Major", 1),
>(4, "Richard Miles", 2)
> {code}
> Let's plan to support them for the nearest release. I've used DBeaver tool to
> validate the statements above:
> https://apacheignite-tools.readme.io/docs/dbeaver
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6092) Bulk Inserts are not Supported
[
https://issues.apache.org/jira/browse/IGNITE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6092:
Fix Version/s: 2.2
> Bulk Inserts are not Supported
> ---
>
> Key: IGNITE-6092
> URL: https://issues.apache.org/jira/browse/IGNITE-6092
> Project: Ignite
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.2
>
>
> Presently the bulk inserts like these are not supported by Ignite's SQL
> engine:
> {code}
> INSERT INTO City (id, name)
> VALUES (1, 'Forest Hill'),
>(2, "Denver"),
>(3, "St. Petersburg")
> INSERT INTO Person (id, name, city_id)
> VALUES (1, 'John Doe', 3),
>(2, "Jane Roe", 2),
>(3, "Mary Major", 1),
>(4, "Richard Miles", 2)
> {code}
> Let's plan to support them for the nearest release. I've used DBeaver tool to
> validate the statements above:
> https://apacheignite-tools.readme.io/docs/dbeaver
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6091) Test fail CacheLateAffinityAssignmentTest.testRandomOperations
[
https://issues.apache.org/jira/browse/IGNITE-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129339#comment-16129339
]
ASF GitHub Bot commented on IGNITE-6091:
GitHub user DmitriyGovorukhin opened a pull request:
https://github.com/apache/ignite/pull/2462
IGNITE-6091 fix flaky test CacheLateAffinityAssignmentTest.testRandom
…Operations
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6091
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2462.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2462
commit 5c45c26493afbad023f5d42117348381ed2b6669
Author: Dmitriy Govorukhin
Date: 2017-08-16T20:09:13Z
ignite-6091 fix flaky test
CacheLateAffinityAssignmentTest.testRandomOperations
> Test fail CacheLateAffinityAssignmentTest.testRandomOperations
> --
>
> Key: IGNITE-6091
> URL: https://issues.apache.org/jira/browse/IGNITE-6091
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Flaky test
> {code}
> junit.framework.AssertionFailedError: Unexpected error:
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to perform cache operation (cache topology is not valid): join-cache-24
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheLateAffinityAssignmentTest.checkCaches(CacheLateAffinityAssignmentTest.java:2176)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheLateAffinityAssignmentTest.afterTest(CacheLateAffinityAssignmentTest.java:225)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6091) Test fail CacheLateAffinityAssignmentTest.testRandomOperations
Dmitriy Govorukhin created IGNITE-6091:
--
Summary: Test fail
CacheLateAffinityAssignmentTest.testRandomOperations
Key: IGNITE-6091
URL: https://issues.apache.org/jira/browse/IGNITE-6091
Project: Ignite
Issue Type: Test
Affects Versions: 2.1
Reporter: Dmitriy Govorukhin
Assignee: Dmitriy Govorukhin
Fix For: 2.2
Flaky test
{code}
junit.framework.AssertionFailedError: Unexpected error:
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to perform cache operation (cache topology is not valid): join-cache-24
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.TestCase.assertTrue(TestCase.java:192)
at
org.apache.ignite.internal.processors.cache.distributed.CacheLateAffinityAssignmentTest.checkCaches(CacheLateAffinityAssignmentTest.java:2176)
at
org.apache.ignite.internal.processors.cache.distributed.CacheLateAffinityAssignmentTest.afterTest(CacheLateAffinityAssignmentTest.java:225)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6091) Test fail CacheLateAffinityAssignmentTest.testRandomOperations
[
https://issues.apache.org/jira/browse/IGNITE-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-6091:
---
Labels: MakeTeamcityGreenAgain (was: )
> Test fail CacheLateAffinityAssignmentTest.testRandomOperations
> --
>
> Key: IGNITE-6091
> URL: https://issues.apache.org/jira/browse/IGNITE-6091
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Flaky test
> {code}
> junit.framework.AssertionFailedError: Unexpected error:
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to perform cache operation (cache topology is not valid): join-cache-24
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheLateAffinityAssignmentTest.checkCaches(CacheLateAffinityAssignmentTest.java:2176)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheLateAffinityAssignmentTest.afterTest(CacheLateAffinityAssignmentTest.java:225)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6090) Update Apache Common codec from 1.6 to 1.10
[ https://issues.apache.org/jira/browse/IGNITE-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-6090: - Description: http://apache-ignite-developers.2346864.n4.nabble.com/Policy-for-update-third-party-dependencies-td20890.html > Update Apache Common codec from 1.6 to 1.10 > --- > > Key: IGNITE-6090 > URL: https://issues.apache.org/jira/browse/IGNITE-6090 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Alexey Kuznetsov > Fix For: 2.2 > > > http://apache-ignite-developers.2346864.n4.nabble.com/Policy-for-update-third-party-dependencies-td20890.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6090) Update Apache Common codec from 1.6 to 1.10
Alexey Kuznetsov created IGNITE-6090: Summary: Update Apache Common codec from 1.6 to 1.10 Key: IGNITE-6090 URL: https://issues.apache.org/jira/browse/IGNITE-6090 Project: Ignite Issue Type: Task Components: general Reporter: Alexey Kuznetsov Fix For: 2.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5790) Xml config can not be used in jdbs and user code simultaneously
[ https://issues.apache.org/jira/browse/IGNITE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129007#comment-16129007 ] ASF GitHub Bot commented on IGNITE-5790: GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/2460 IGNITE-5790 SQL: Append UUID to names of Ignite instances opened by JDBC All Ignite instances created by Jdbc driver should now be either named or appended with ignite-jdbc-driver-UUID to avoid conflicting with instances created in other places. Had to inline parts of IgnitionEx.start() to apply changes to every decision branch. You can merge this pull request into a Git repository by running: $ git pull https://github.com/alamar/ignite ignite-5790 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2460.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2460 commit 05c45747750e10fc094a09a2189f895ffd768520 Author: Ilya Kasnacheev Date: 2017-08-16T15:26:43Z IGNITE-5790 SQL: Append UUID to names of Ignite instances opened by JDBC. > Xml config can not be used in jdbs and user code simultaneously > --- > > Key: IGNITE-5790 > URL: https://issues.apache.org/jira/browse/IGNITE-5790 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Assignee: Ilya Kasnacheev > Fix For: 2.2 > > > when user uses the same xml config for jdbc driver and for his own ignite > instance there can be : > java.sql.SQLException: Failed to start Ignite node. > Caused by: class org.apache.ignite.IgniteCheckedException: Ignite instance > with this name has already been started: CustomeIgniteName > because JDBC creates separate ignite instance, while user already has one > with the same name. > Of course that can be easily workarounded, user can support two configs or > create jdbc connect first and then use Ignition.getOrStart(). > However it's inconvenient for user and should be treated as usability issue. > I see 2 solutions: > 1) jdbc driver should use Ignition.getOrStart() > 2) jdbc driver should connection string as ignite name. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6050) Eternal wait in DataStreamerTest.TestBufferSize()
[ https://issues.apache.org/jira/browse/IGNITE-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128953#comment-16128953 ] Igor Seliverstov commented on IGNITE-6050: -- [~ptupitsyn], could you look at the changes? > Eternal wait in DataStreamerTest.TestBufferSize() > - > > Key: IGNITE-6050 > URL: https://issues.apache.org/jira/browse/IGNITE-6050 > Project: Ignite > Issue Type: Test > Components: platforms >Affects Versions: 2.1 >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov > Labels: MakeTeamcityGreenAgain > Fix For: 2.2 > > > There are several places where Future.Wait() is used without timeout. This > leads tests failures on timeout and makes difficult to determine the cause of > the issue -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6068) We try to add entry to partition which was concurrently evicted
[
https://issues.apache.org/jira/browse/IGNITE-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk resolved IGNITE-6068.
--
Resolution: Fixed
Merged to master
> We try to add entry to partition which was concurrently evicted
> ---
>
> Key: IGNITE-6068
> URL: https://issues.apache.org/jira/browse/IGNITE-6068
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Alexey Goncharuk
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> https://ci.ignite.apache.org/viewLog.html?buildId=768819&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteQueries2
> {code}
> rg.apache.ignite.internal.processors.query.schema.SchemaOperationException:
> Schema change operation failed: Adding entry to partition that is
> concurrently evicted [part=817, shouldBeMoving=false, belongs=false,
> topVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
> curTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0]]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.processIndexOperationLocal(GridQueryProcessor.java:1290)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaOperationWorker.body(SchemaOperationWorker.java:108)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException:
> Adding entry to partition that is concurrently evicted [part=817,
> shouldBeMoving=false, belongs=false, topVer=AffinityTopologyVersion
> [topVer=4, minorTopVer=0], curTopVer=AffinityTopologyVersion [topVer=4,
> minorTopVer=0]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:752)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:644)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:933)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:524)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:924)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processKey(SchemaIndexCacheVisitorImpl.java:141)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartition(SchemaIndexCacheVisitorImpl.java:120)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.visit(SchemaIndexCacheVisitorImpl.java:90)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dynamicIndexCreate(IgniteH2Indexing.java:684)
> at
> org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractConcurrentSelfTest$BlockingIndexing.dynamicIndexCreate(DynamicIndexAbstractConcurrentSelfTest.java:1065)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.processIndexOperationLocal(GridQueryProcessor.java:1276)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaOperationWorker.body(SchemaOperationWorker.java:108)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6088) Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on SSLSocket
[ https://issues.apache.org/jira/browse/IGNITE-6088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-6088: -- Priority: Critical (was: Major) > Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on > SSLSocket > --- > > Key: IGNITE-6088 > URL: https://issues.apache.org/jira/browse/IGNITE-6088 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Critical > Fix For: 2.2 > > > UnsupportedOperationException: The method shutdownOutput() is not supported > in SSLSocket -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6088) Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on SSLSocket
[ https://issues.apache.org/jira/browse/IGNITE-6088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128906#comment-16128906 ] ASF GitHub Bot commented on IGNITE-6088: GitHub user ezhuravl opened a pull request: https://github.com/apache/ignite/pull/2457 IGNITE-6088 Socket#shutdownOutput in ServerImpl leads to UnsupportedO… …perationException on SSLSocket You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6088 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2457.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2457 commit 5658aa9d0c79e216613f94bdc5d459ec949851c8 Author: Evgenii Zhuravlev Date: 2017-08-16T14:56:08Z IGNITE-6088 Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on SSLSocket > Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on > SSLSocket > --- > > Key: IGNITE-6088 > URL: https://issues.apache.org/jira/browse/IGNITE-6088 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev > Fix For: 2.2 > > > UnsupportedOperationException: The method shutdownOutput() is not supported > in SSLSocket -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-2136) Issue with tx entry lock assignment when near cache is used
[ https://issues.apache.org/jira/browse/IGNITE-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-2136: --- Priority: Major (was: Critical) > Issue with tx entry lock assignment when near cache is used > --- > > Key: IGNITE-2136 > URL: https://issues.apache.org/jira/browse/IGNITE-2136 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov > Fix For: 2.2 > > > Adde test reproducing hang on tx putAll when near cache is used: > NearCachePutAllMultinodeTest. > Root cause for this issue is that remote mvcc candidates are marked as owners > during tx finish step. To fix it we can try to move logic from > 'tx.doneRemote' to prepare step. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-2136) Issue with tx entry lock assignment when near cache is used
[ https://issues.apache.org/jira/browse/IGNITE-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-2136: --- Fix Version/s: 2.2 > Issue with tx entry lock assignment when near cache is used > --- > > Key: IGNITE-2136 > URL: https://issues.apache.org/jira/browse/IGNITE-2136 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Critical > Fix For: 2.2 > > > Adde test reproducing hang on tx putAll when near cache is used: > NearCachePutAllMultinodeTest. > Root cause for this issue is that remote mvcc candidates are marked as owners > during tx finish step. To fix it we can try to move logic from > 'tx.doneRemote' to prepare step. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-627) Inconsistent value in near cache
[ https://issues.apache.org/jira/browse/IGNITE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-627: -- Priority: Major (was: Critical) > Inconsistent value in near cache > > > Key: IGNITE-627 > URL: https://issues.apache.org/jira/browse/IGNITE-627 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov > Fix For: 2.2 > > > This scenario is possible in atomic cache with near cache enabled: > - key is updated concurrently from near and primary node > - primary node first executes update request from near node, registers it as > reader and sends GridNearAtomicUpdateResponse to near node > - then primary node executes second update, sees that there is a reader and > sends GridDhtAtomicUpdateRequest to near node > - GridDhtAtomicUpdateRequest is handled first on near node (see > GridNearAtomicCache.processDhtAtomicUpdateRequest), it tries to peek entry, > it is not created yet and it is considered as evicted, updated is skipped and > reader will be removed on primary node > - then near node handles GridNearAtomicUpdateResponse and creates entry with > incorrect value > Tests > GridCacheValueConsistencyAtomicPrimaryWriteOrderNearEnabledSelfTest.testPutRemoveConsistencyMultithreaded > and testPutConsistencyMultithreaded fail from time to time because of this > issue. > Most probably there is similar issue in transactional cache since > GridCacheValueConsistencyTransactionalNearEnabledSelfTest also fails from > time to time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-627) Inconsistent value in near cache
[ https://issues.apache.org/jira/browse/IGNITE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-627: -- Fix Version/s: 2.2 > Inconsistent value in near cache > > > Key: IGNITE-627 > URL: https://issues.apache.org/jira/browse/IGNITE-627 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Critical > Fix For: 2.2 > > > This scenario is possible in atomic cache with near cache enabled: > - key is updated concurrently from near and primary node > - primary node first executes update request from near node, registers it as > reader and sends GridNearAtomicUpdateResponse to near node > - then primary node executes second update, sees that there is a reader and > sends GridDhtAtomicUpdateRequest to near node > - GridDhtAtomicUpdateRequest is handled first on near node (see > GridNearAtomicCache.processDhtAtomicUpdateRequest), it tries to peek entry, > it is not created yet and it is considered as evicted, updated is skipped and > reader will be removed on primary node > - then near node handles GridNearAtomicUpdateResponse and creates entry with > incorrect value > Tests > GridCacheValueConsistencyAtomicPrimaryWriteOrderNearEnabledSelfTest.testPutRemoveConsistencyMultithreaded > and testPutConsistencyMultithreaded fail from time to time because of this > issue. > Most probably there is similar issue in transactional cache since > GridCacheValueConsistencyTransactionalNearEnabledSelfTest also fails from > time to time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6089) SQL: Improve query parallelism architecture
[
https://issues.apache.org/jira/browse/IGNITE-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6089:
Labels: performance (was: )
> SQL: Improve query parallelism architecture
> ---
>
> Key: IGNITE-6089
> URL: https://issues.apache.org/jira/browse/IGNITE-6089
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
> Labels: performance
>
> Currently query parallelism implement with static split of all indexes
> (including PK) for cache. This approach has several major disadvantages:
> 1) It improves scans, but slows down index and range lookups
> 2) Tables with different DOP cannot be used in the same query
> We need to fix that. Proposed plan:
> 1) No more index splits, ever - there is one and only one index always
> 2) Use preliminary execution plan, statistics (IGNITE-6079), CPU cores count
> and CPU load to estimate whether query will benefit from parallelism.
> 3) if yes - split node-s single map query into several independent pieces.
> Splitting can be achieved in one of the following ways:
> 1) Partition-based: e.g. if node owns partitions A, B, C and D, then we can
> split it to two queries - one over (A, B), another over (C, D). This could be
> useful for pure scans (e.g. DWH)
> 2) Histogram-based: e.g. if we have a query {{SELECT ... WHERE salary > 50}},
> and we know salary distribution, we can split it into {{WHERE salary > 50 AND
> salary <= 200}} and {{WHERE salary > 200}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6089) SQL: Improve query parallelism architecture
Vladimir Ozerov created IGNITE-6089:
---
Summary: SQL: Improve query parallelism architecture
Key: IGNITE-6089
URL: https://issues.apache.org/jira/browse/IGNITE-6089
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Currently query parallelism implement with static split of all indexes
(including PK) for cache. This approach has several major disadvantages:
1) It improves scans, but slows down index and range lookups
2) Tables with different DOP cannot be used in the same query
We need to fix that. Proposed plan:
1) No more index splits, ever - there is one and only one index always
2) Use preliminary execution plan, statistics (IGNITE-6079), CPU cores count
and CPU load to estimate whether query will benefit from parallelism.
3) if yes - split node-s single map query into several independent pieces.
Splitting can be achieved in one of the following ways:
1) Partition-based: e.g. if node owns partitions A, B, C and D, then we can
split it to two queries - one over (A, B), another over (C, D). This could be
useful for pure scans (e.g. DWH)
2) Histogram-based: e.g. if we have a query {{SELECT ... WHERE salary > 50}},
and we know salary distribution, we can split it into {{WHERE salary > 50 AND
salary <= 200}} and {{WHERE salary > 200}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6088) Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on SSLSocket
[ https://issues.apache.org/jira/browse/IGNITE-6088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-6088: -- Summary: Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on SSLSocket (was: Socket#shutdownOutput in ServerImpl lead UnsupportedOperationException on SSLSocket) > Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on > SSLSocket > --- > > Key: IGNITE-6088 > URL: https://issues.apache.org/jira/browse/IGNITE-6088 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev > Fix For: 2.2 > > > UnsupportedOperationException: The method shutdownOutput() is not supported > in SSLSocket -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-3935) ClassLoaders are not switched during object deserialization
[
https://issues.apache.org/jira/browse/IGNITE-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128895#comment-16128895
]
ASF GitHub Bot commented on IGNITE-3935:
Github user red-batmen closed the pull request at:
https://github.com/apache/ignite/pull/2456
> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A
> will be used for the deserialization of the whole object's state, i.e.,
> including all its fields that can be custom objects loaded by ClassLoader B.
> In a basic scenario we can have an object of some Ignite class that is
> presented in the classpath. That Ignite class may enclose an object that is
> loaded by peer-class-loading class loader. The deserialization will fail
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite =
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache =
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr =
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg)
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException,
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite =
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache =
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr =
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-3935) ClassLoaders are not switched during object deserialization
[
https://issues.apache.org/jira/browse/IGNITE-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128893#comment-16128893
]
ASF GitHub Bot commented on IGNITE-3935:
GitHub user red-batmen opened a pull request:
https://github.com/apache/ignite/pull/2456
Add test for https://issues.apache.org/jira/browse/IGNITE-3935
Writing test for IGNITE-3935
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/red-batmen/ignite IGNITE-3935
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2456.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2456
commit 216dfb7fada63b983f2816af28ddabd297c0da22
Author: Alex Boroda
Date: 2017-08-16T14:31:59Z
Add test for https://issues.apache.org/jira/browse/IGNITE-3935
> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A
> will be used for the deserialization of the whole object's state, i.e.,
> including all its fields that can be custom objects loaded by ClassLoader B.
> In a basic scenario we can have an object of some Ignite class that is
> presented in the classpath. That Ignite class may enclose an object that is
> loaded by peer-class-loading class loader. The deserialization will fail
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite =
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache =
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr =
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg)
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException,
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite =
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache =
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr =
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6088) Socket#shutdownOutput in ServerImpl lead UnsupportedOperationException on SSLSocket
Evgenii Zhuravlev created IGNITE-6088: - Summary: Socket#shutdownOutput in ServerImpl lead UnsupportedOperationException on SSLSocket Key: IGNITE-6088 URL: https://issues.apache.org/jira/browse/IGNITE-6088 Project: Ignite Issue Type: Bug Affects Versions: 2.1 Reporter: Evgenii Zhuravlev Assignee: Evgenii Zhuravlev Fix For: 2.2 UnsupportedOperationException: The method shutdownOutput() is not supported in SSLSocket -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6081) .NET: Cannot get from cache values which were stored in cache with PutAll.
[
https://issues.apache.org/jira/browse/IGNITE-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128884#comment-16128884
]
Igor Sapego commented on IGNITE-6081:
-
It seems that root cause is usage of the {{Write}} method instead of
{{WriteDetached}} in {{PutAll}}.
> .NET: Cannot get from cache values which were stored in cache with PutAll.
> --
>
> Key: IGNITE-6081
> URL: https://issues.apache.org/jira/browse/IGNITE-6081
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Critical
>
> If you try to put multiple non-primitive values with dictionary property to
> cache using {{PutAll}}, you'd get an exception on attempt to read those
> values. Code example below:
> {code}
> var entries = new Dictionary();
> for (int i = 0; i < 100; i++)
> entries.Add(i, new SomeType { Id = i });
> var cache = Ignition.GetIgnite().GetCache("CacheName");
> cache.PutAll(entries);
> cache.Get(42);
> {code}
> Pay attention, that {{SomeType}} should have dictionary property.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6086) SQL: Create own parser for DDL and control statements
[ https://issues.apache.org/jira/browse/IGNITE-6086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6086: Summary: SQL: Create own parser for DDL and control statements (was: SQL: create own parser for DDL and control statements) > SQL: Create own parser for DDL and control statements > - > > Key: IGNITE-6086 > URL: https://issues.apache.org/jira/browse/IGNITE-6086 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov > Fix For: 2.3 > > > Currently we rely on H2 parser for all queries. But we need to support a lot > of specific commands and options, which are outside of ANSI SQL and outside > of H2. > Let's create our own parser for DDL and control statements. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6081) .NET: Cannot get from cache values which were stored in cache with PutAll.
[
https://issues.apache.org/jira/browse/IGNITE-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-6081:
Description:
If you try to put multiple non-primitive values with dictionary property to
cache using {{PutAll}}, you'd get an exception on attempt to read those values.
Code example below:
{code}
var entries = new Dictionary();
for (int i = 0; i < 100; i++)
entries.Add(i, new SomeType { Id = i });
var cache = Ignition.GetIgnite().GetCache("CacheName");
cache.PutAll(entries);
cache.Get(42);
{code}
Pay attention, that {{SomeType}} should have dictionary property.
was:
If you try to put multiple non-primitive values to cache using {{PutAll}},
you'd get an exception on attempt to read those values. Code example below:
{code}
var entries = new Dictionary();
for (int i = 0; i < 100; i++)
entries.Add(i, new SomeType { Id = i });
var cache = Ignition.GetIgnite().GetCache("CacheName");
cache.PutAll(entries);
cache.Get(42);
{code}
> .NET: Cannot get from cache values which were stored in cache with PutAll.
> --
>
> Key: IGNITE-6081
> URL: https://issues.apache.org/jira/browse/IGNITE-6081
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Critical
>
> If you try to put multiple non-primitive values with dictionary property to
> cache using {{PutAll}}, you'd get an exception on attempt to read those
> values. Code example below:
> {code}
> var entries = new Dictionary();
> for (int i = 0; i < 100; i++)
> entries.Add(i, new SomeType { Id = i });
> var cache = Ignition.GetIgnite().GetCache("CacheName");
> cache.PutAll(entries);
> cache.Get(42);
> {code}
> Pay attention, that {{SomeType}} should have dictionary property.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-1793) [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes
[
https://issues.apache.org/jira/browse/IGNITE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-1793:
---
Priority: Major (was: Critical)
> [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs
> on TC sometimes
> -
>
> Key: IGNITE-1793
> URL: https://issues.apache.org/jira/browse/IGNITE-1793
> Project: Ignite
> Issue Type: Test
>Reporter: Artem Shutak
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.2
>
> Attachments: test.logs
>
>
> IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes.
> Test hangs on IgniteCountDownLatch.count() method.
> {noformat}
> Thread [name="test-runner", id=24157, state=WAITING, blockCnt=0, waitCnt=96]
> Lock [object=o.a.i.i.util.future.GridFutureAdapter$ChainFuture@1e542154,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4525)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1544)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:348)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:342)
> at
> o.a.i.i.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:962)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl.count(GridCacheCountDownLatchImpl.java:143)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkRemovedLatch(IgniteCountDownLatchAbstractSelfTest.java:159)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkCountDown(IgniteCountDownLatchAbstractSelfTest.java:232)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkLatch(IgniteCountDownLatchAbstractSelfTest.java:84)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.testLatch(IgniteCountDownLatchAbstractSelfTest.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6073) Handy APIs to add binary metadata locally
[ https://issues.apache.org/jira/browse/IGNITE-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-6073: - Summary: Handy APIs to add binary metadata locally (was: Handy APIs to add binary metadata locally and to iterate over registered binary types) > Handy APIs to add binary metadata locally > - > > Key: IGNITE-6073 > URL: https://issues.apache.org/jira/browse/IGNITE-6073 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov > Fix For: 2.2 > > > h2. Notes > When each node has some local source of binary metadata and it is guaranteed > that all nodes have the same set of metadata it is possible to optimize > process of adding metadata and allow nodes to skip exchanging phase via > discovery. > h2. Acceptance Criteria > # Method on CacheObjectBinaryProcessor interface to add binary metadata on > local node without exchange with other nodes in cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6073) Handy APIs to add binary metadata locally
[ https://issues.apache.org/jira/browse/IGNITE-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128858#comment-16128858 ] Alexey Goncharuk commented on IGNITE-6073: -- Thanks, Sergey, merged to master. > Handy APIs to add binary metadata locally > - > > Key: IGNITE-6073 > URL: https://issues.apache.org/jira/browse/IGNITE-6073 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov > Fix For: 2.2 > > > h2. Notes > When each node has some local source of binary metadata and it is guaranteed > that all nodes have the same set of metadata it is possible to optimize > process of adding metadata and allow nodes to skip exchanging phase via > discovery. > h2. Acceptance Criteria > # Method on CacheObjectBinaryProcessor interface to add binary metadata on > local node without exchange with other nodes in cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6015) Test fail in Ignite Cache 2: GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform
[
https://issues.apache.org/jira/browse/IGNITE-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-6015:
---
Description:
{code}
java.util.concurrent.TimeoutException: Test has been timed out
[test=testGetAndTransform, timeout=30]
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1949)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:156)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:82)
at
org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:82)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:951)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:831)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:3
{code}
was:
java.util.concurrent.TimeoutException: Test has been timed out
[test=testGetAndTransform, timeout=30]
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1949)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner
[jira] [Created] (IGNITE-6087) SQL: Ability to pass one column to multiple object fields
Vladimir Ozerov created IGNITE-6087:
---
Summary: SQL: Ability to pass one column to multiple object fields
Key: IGNITE-6087
URL: https://issues.apache.org/jira/browse/IGNITE-6087
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
Fix For: 2.2
Consider the following case:
{code}
class PersonKey {
long id;
}
class Person {
long id;
String name;
}
{code}This is frequent and convenient pattern as it allows to derive a key from
a value.
We do not support it in DML at the moment, as column can be mapped only to a
single object fields. Let's fix it, introducing some new option to
{{QueryEntity}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6086) SQL: create own parser for DDL and control statements
Vladimir Ozerov created IGNITE-6086: --- Summary: SQL: create own parser for DDL and control statements Key: IGNITE-6086 URL: https://issues.apache.org/jira/browse/IGNITE-6086 Project: Ignite Issue Type: Task Components: sql Affects Versions: 2.1 Reporter: Vladimir Ozerov Fix For: 2.3 Currently we rely on H2 parser for all queries. But we need to support a lot of specific commands and options, which are outside of ANSI SQL and outside of H2. Let's create our own parser for DDL and control statements. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5879) .NET: Move TestPlatformPlugin to a separate module
[ https://issues.apache.org/jira/browse/IGNITE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128840#comment-16128840 ] ASF GitHub Bot commented on IGNITE-5879: GitHub user daradurvs opened a pull request: https://github.com/apache/ignite/pull/2455 IGNITE-5879 .NET: Move TestPlatformPlugin to a separate module You can merge this pull request into a Git repository by running: $ git pull https://github.com/daradurvs/ignite ignite-5879 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2455.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2455 commit 1368802499338138386a6009454e28638b078aca Author: Vyacheslav Daradur Date: 2017-08-16T14:03:23Z ignite-5879: moved .NET TestPlatformPlugin to a separate module > .NET: Move TestPlatformPlugin to a separate module > -- > > Key: IGNITE-5879 > URL: https://issues.apache.org/jira/browse/IGNITE-5879 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Vyacheslav Daradur > Labels: .NET > > Move test plugin to a separate module and load it only for .NET tests so we > don't interfere with other tests. > Dev list discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Plugins-in-tests-td20167.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-4843) SQL: add support caches with different parallelizm degree within same query.
[ https://issues.apache.org/jira/browse/IGNITE-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-4843. --- > SQL: add support caches with different parallelizm degree within same query. > > > Key: IGNITE-4843 > URL: https://issues.apache.org/jira/browse/IGNITE-4843 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 1.9 >Reporter: Andrew Mashenkov > > For now, we have a limitation "If a query contains JOINs, then all the > participating caches must have the same degree of parallelism.". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-4843) SQL: add support caches with different parallelizm degree within same query.
[ https://issues.apache.org/jira/browse/IGNITE-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4843. - Resolution: Won't Fix Will be fixed along with query parallelism itself - we will not split indexes in future. > SQL: add support caches with different parallelizm degree within same query. > > > Key: IGNITE-4843 > URL: https://issues.apache.org/jira/browse/IGNITE-4843 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 1.9 >Reporter: Andrew Mashenkov > > For now, we have a limitation "If a query contains JOINs, then all the > participating caches must have the same degree of parallelism.". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5014) Do not use partition exchange worker for CREATE/DROP INDEX
[ https://issues.apache.org/jira/browse/IGNITE-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5014: Summary: Do not use partition exchange worker for CREATE/DROP INDEX (was: Do not used partition exchange worker for CREATE/DROP INDEX) > Do not use partition exchange worker for CREATE/DROP INDEX > -- > > Key: IGNITE-5014 > URL: https://issues.apache.org/jira/browse/IGNITE-5014 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Minor > Fix For: 2.2 > > > It was used for historical reasons. But looks like it is not needed anymore. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4613) Allow to create text index without sql table
[ https://issues.apache.org/jira/browse/IGNITE-4613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128836#comment-16128836 ] Vladimir Ozerov commented on IGNITE-4613: - Not relevant at the moment. > Allow to create text index without sql table > > > Key: IGNITE-4613 > URL: https://issues.apache.org/jira/browse/IGNITE-4613 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-4613) Allow to create text index without sql table
[ https://issues.apache.org/jira/browse/IGNITE-4613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-4613. --- > Allow to create text index without sql table > > > Key: IGNITE-4613 > URL: https://issues.apache.org/jira/browse/IGNITE-4613 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4510) SQL: co-located query may calculate target partition in advance in some cases
[
https://issues.apache.org/jira/browse/IGNITE-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4510:
Labels: performance (was: important performance sql)
> SQL: co-located query may calculate target partition in advance in some cases
> -
>
> Key: IGNITE-4510
> URL: https://issues.apache.org/jira/browse/IGNITE-4510
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
> Labels: performance
> Fix For: 2.2
>
>
> Consider the following SQL query with {{distributedJoins=false}}:
> {code}
> SELECT ...
> FROM Employee e
> INNER JOIN Department d on d.id = e.dept_id
> WHERE e.dept_id = ?
> {code}
> If {{dept_id}} is affinity key, and this should be certainly so in case of
> non-colocated joins (otherwise query will return incorrect result), then we
> can do the following:
> 1) Determine partition for this affinity key.
> 2) Send query execution request to this partition only.
> Same technique can be applied to {{WHERE e.dept_id IN (?, ...)}} case.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-3911) Unable to add user defined aggregate to H2
[ https://issues.apache.org/jira/browse/IGNITE-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3911: Fix Version/s: (was: 2.2) > Unable to add user defined aggregate to H2 > -- > > Key: IGNITE-3911 > URL: https://issues.apache.org/jira/browse/IGNITE-3911 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Tolstokulakov Nikolay >Assignee: Vladimir Ozerov > > It is possible to add user defined function (@QuerySqlFunction annotation) > for H2 SQL, but it is not possible to add user defined aggregate. For > consistency I suggest create new annotation @QuerySqlAggregateClass -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-4613) Allow to create text index without sql table
[ https://issues.apache.org/jira/browse/IGNITE-4613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4613. - Resolution: Won't Fix > Allow to create text index without sql table > > > Key: IGNITE-4613 > URL: https://issues.apache.org/jira/browse/IGNITE-4613 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-3911) Unable to add user defined aggregate to H2
[ https://issues.apache.org/jira/browse/IGNITE-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3911. --- > Unable to add user defined aggregate to H2 > -- > > Key: IGNITE-3911 > URL: https://issues.apache.org/jira/browse/IGNITE-3911 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Tolstokulakov Nikolay >Assignee: Vladimir Ozerov > > It is possible to add user defined function (@QuerySqlFunction annotation) > for H2 SQL, but it is not possible to add user defined aggregate. For > consistency I suggest create new annotation @QuerySqlAggregateClass -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-3911) Unable to add user defined aggregate to H2
[ https://issues.apache.org/jira/browse/IGNITE-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-3911: --- Assignee: Vladimir Ozerov (was: Tolstokulakov Nikolay) > Unable to add user defined aggregate to H2 > -- > > Key: IGNITE-3911 > URL: https://issues.apache.org/jira/browse/IGNITE-3911 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Tolstokulakov Nikolay >Assignee: Vladimir Ozerov > > It is possible to add user defined function (@QuerySqlFunction annotation) > for H2 SQL, but it is not possible to add user defined aggregate. For > consistency I suggest create new annotation @QuerySqlAggregateClass -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-3911) Unable to add user defined aggregate to H2
[ https://issues.apache.org/jira/browse/IGNITE-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-3911: --- Assignee: (was: Vladimir Ozerov) > Unable to add user defined aggregate to H2 > -- > > Key: IGNITE-3911 > URL: https://issues.apache.org/jira/browse/IGNITE-3911 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Tolstokulakov Nikolay > > It is possible to add user defined function (@QuerySqlFunction annotation) > for H2 SQL, but it is not possible to add user defined aggregate. For > consistency I suggest create new annotation @QuerySqlAggregateClass -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-3911) Unable to add user defined aggregate to H2
[ https://issues.apache.org/jira/browse/IGNITE-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-3911. - Resolution: Duplicate > Unable to add user defined aggregate to H2 > -- > > Key: IGNITE-3911 > URL: https://issues.apache.org/jira/browse/IGNITE-3911 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Tolstokulakov Nikolay >Assignee: Vladimir Ozerov > Fix For: 2.2 > > > It is possible to add user defined function (@QuerySqlFunction annotation) > for H2 SQL, but it is not possible to add user defined aggregate. For > consistency I suggest create new annotation @QuerySqlAggregateClass -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-3768) SQL: implement collecting query metrics from map step to reduce step
[ https://issues.apache.org/jira/browse/IGNITE-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128830#comment-16128830 ] Vladimir Ozerov commented on IGNITE-3768: - Added reference to dev-list discussion. > SQL: implement collecting query metrics from map step to reduce step > > > Key: IGNITE-3768 > URL: https://issues.apache.org/jira/browse/IGNITE-3768 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov > > Ignite SQL engine use a mapreduce to execute query on cluster. > Some node map queries over cluster and after they are completed and reduced > on initial node. > In current implementation we measure duration on initial node and on all > nodes where two-step queries are executed, but only overall duration is > returned. > We also need to return duration from all two-step queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5879) .NET: Move TestPlatformPlugin to a separate module
[ https://issues.apache.org/jira/browse/IGNITE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-5879: -- Assignee: Vyacheslav Daradur > .NET: Move TestPlatformPlugin to a separate module > -- > > Key: IGNITE-5879 > URL: https://issues.apache.org/jira/browse/IGNITE-5879 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Vyacheslav Daradur > Labels: .NET > > Move test plugin to a separate module and load it only for .NET tests so we > don't interfere with other tests. > Dev list discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Plugins-in-tests-td20167.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-3453) Query engine picks incorrect index in certain configurations.
[ https://issues.apache.org/jira/browse/IGNITE-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3453: Labels: performance (was: ) > Query engine picks incorrect index in certain configurations. > - > > Key: IGNITE-3453 > URL: https://issues.apache.org/jira/browse/IGNITE-3453 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Alexei Scherbakov > Labels: performance > Attachments: Example.java > > > Index selection depends on index name ordering, not the argument type. > Index 1 (name idx_1): > countryId:Integer, regionId:Integer, cityId:Integer > Index 2 (name idx_0): > countryId:Integer, regionId:Integer, nation:String > For query: > select id, countryId, cityId from Person where countryId=? and regionId=? and > cityId=? params 1,1,1 > the index 2 is picked incorrectly and only two first fields are used. > See full reproducer in the attachment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4188) Savepoints support inside of Ignite Transactions
[
https://issues.apache.org/jira/browse/IGNITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur reassigned IGNITE-4188:
--
Assignee: Ryabov Dmitrii (was: Vyacheslav Daradur)
> Savepoints support inside of Ignite Transactions
>
>
> Key: IGNITE-4188
> URL: https://issues.apache.org/jira/browse/IGNITE-4188
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Ryabov Dmitrii
> Fix For: 2.2
>
>
> A savepoint is a special mark inside a transaction that allows all commands
> that are executed after it was established to be rolled back, restoring the
> transaction state to what it was at the time of the savepoint.
> Here is a reference to the similar functionality implemented by some of RDBMs
> vendors.
> https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
> http://dev.mysql.com/doc/refman/5.7/en/savepoint.html
> Consider the following example.
> {code}
> BEGIN;
> INSERT INTO table1 VALUES (1);
> SAVEPOINT my_savepoint;
> INSERT INTO table1 VALUES (2);
> ROLLBACK TO SAVEPOINT my_savepoint;
> INSERT INTO table1 VALUES (3);
> COMMIT;
> {code}
> The execution result must guarantee that only values 1 and 3 are inserted
> into table1.
> In Ignite, it should be supported this way (preserving the same behavior as
> above).
> {code}
> Ignite ignite = ;
> IgniteCache c = ;
> try (Transaction tx = ignite.transactions().txStart()) {
> c.put(1, 1);
>
> tx.savepoint("mysavepoint");
>
> c.put(2, 2);
>
> tx.rollbackToSavepoint("mysavepoint");
>
> c.put(3, 3);
>
> tx.commit();
> }
> {code}
> As a summary the following has to be supported on Ignite side:
> - The {{savepoint}} method which will set a named transaction savepoint with
> a name of an identifier.
> - Multiple savepoints defined within a transaction. The names of the
> savepoints have to differ from each other. If the current transaction has a
> savepoint with the same name, the old savepoint is deleted and a new one is
> set.
> - The {{rollbackToSavepoint}} method that will roll back all the changes done
> after a specific checkpoint establishment.
> - The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the
> effects of commands executed after it was established.
> - Full support of the behavior listed above at the level of ODBC and JDBC
> drivers and DML (will be handled under separate tickets).
> - The behavior has to be support for all transactional modes.
> Original proposal on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/TX-savepoints-td12041.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur reassigned IGNITE-2313:
--
Assignee: Ryabov Dmitrii (was: Vyacheslav Daradur)
> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
> Fix For: 2.2
>
>
> Currently atomic operations within a transaction succeed without alarming a
> user that no transaction really occurs. We should add a mode to fail such
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following
> error message: {{Transaction spans operations on atomic cache (consider
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to
> true)}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[ https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-602: - Assignee: Ryabov Dmitrii (was: Vyacheslav Daradur) > [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by > infinite recursion > > > Key: IGNITE-602 > URL: https://issues.apache.org/jira/browse/IGNITE-602 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Artem Shutak >Assignee: Ryabov Dmitrii > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.2 > > > See test > org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention > and related TODO in same source file. > Also take a look at > http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring > Test should be unmuted on TC after fix. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[ https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-602: - Assignee: Vyacheslav Daradur (was: Ryabov Dmitrii) > [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by > infinite recursion > > > Key: IGNITE-602 > URL: https://issues.apache.org/jira/browse/IGNITE-602 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Artem Shutak >Assignee: Vyacheslav Daradur > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.2 > > > See test > org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention > and related TODO in same source file. > Also take a look at > http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring > Test should be unmuted on TC after fix. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur reassigned IGNITE-2313:
--
Assignee: Vyacheslav Daradur (was: Ryabov Dmitrii)
> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> Currently atomic operations within a transaction succeed without alarming a
> user that no transaction really occurs. We should add a mode to fail such
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following
> error message: {{Transaction spans operations on atomic cache (consider
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to
> true)}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-4188) Savepoints support inside of Ignite Transactions
[
https://issues.apache.org/jira/browse/IGNITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur reassigned IGNITE-4188:
--
Assignee: Vyacheslav Daradur (was: Ryabov Dmitrii)
> Savepoints support inside of Ignite Transactions
>
>
> Key: IGNITE-4188
> URL: https://issues.apache.org/jira/browse/IGNITE-4188
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> A savepoint is a special mark inside a transaction that allows all commands
> that are executed after it was established to be rolled back, restoring the
> transaction state to what it was at the time of the savepoint.
> Here is a reference to the similar functionality implemented by some of RDBMs
> vendors.
> https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
> http://dev.mysql.com/doc/refman/5.7/en/savepoint.html
> Consider the following example.
> {code}
> BEGIN;
> INSERT INTO table1 VALUES (1);
> SAVEPOINT my_savepoint;
> INSERT INTO table1 VALUES (2);
> ROLLBACK TO SAVEPOINT my_savepoint;
> INSERT INTO table1 VALUES (3);
> COMMIT;
> {code}
> The execution result must guarantee that only values 1 and 3 are inserted
> into table1.
> In Ignite, it should be supported this way (preserving the same behavior as
> above).
> {code}
> Ignite ignite = ;
> IgniteCache c = ;
> try (Transaction tx = ignite.transactions().txStart()) {
> c.put(1, 1);
>
> tx.savepoint("mysavepoint");
>
> c.put(2, 2);
>
> tx.rollbackToSavepoint("mysavepoint");
>
> c.put(3, 3);
>
> tx.commit();
> }
> {code}
> As a summary the following has to be supported on Ignite side:
> - The {{savepoint}} method which will set a named transaction savepoint with
> a name of an identifier.
> - Multiple savepoints defined within a transaction. The names of the
> savepoints have to differ from each other. If the current transaction has a
> savepoint with the same name, the old savepoint is deleted and a new one is
> set.
> - The {{rollbackToSavepoint}} method that will roll back all the changes done
> after a specific checkpoint establishment.
> - The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the
> effects of commands executed after it was established.
> - Full support of the behavior listed above at the level of ODBC and JDBC
> drivers and DML (will be handled under separate tickets).
> - The behavior has to be support for all transactional modes.
> Original proposal on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/TX-savepoints-td12041.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away
[ https://issues.apache.org/jira/browse/IGNITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-6044: --- Assignee: Alexander Paschenko > SQL insert waits for transaction commit, but it must be executed right away > --- > > Key: IGNITE-6044 > URL: https://issues.apache.org/jira/browse/IGNITE-6044 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Assignee: Alexander Paschenko >Priority: Critical > Fix For: 2.2 > > > Doc says: > ""Presently, DML supports the atomic mode only meaning that if there is a DML > query that is executed as a part of an Ignite transaction then it will not be > enlisted in the transaction's writing queue and will be executed right away."" > https://apacheignite.readme.io/docs/dml#section-transactional-support > However the data will be added to cache only after transaction commit. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away
[ https://issues.apache.org/jira/browse/IGNITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128820#comment-16128820 ] Vladimir Ozerov commented on IGNITE-6044: - I think we should not allow DML inside ongoing TX and vice versa. This can be controlled with help of thread-locals. Otherwise user is at high risk of getting deadlocks. We will allow this stuff once MVCC and transactional SQL are ready. > SQL insert waits for transaction commit, but it must be executed right away > --- > > Key: IGNITE-6044 > URL: https://issues.apache.org/jira/browse/IGNITE-6044 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Priority: Critical > Fix For: 2.2 > > > Doc says: > ""Presently, DML supports the atomic mode only meaning that if there is a DML > query that is executed as a part of an Ignite transaction then it will not be > enlisted in the transaction's writing queue and will be executed right away."" > https://apacheignite.readme.io/docs/dml#section-transactional-support > However the data will be added to cache only after transaction commit. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6083) Null value have appear in the entry processor, but the entry is existing
[
https://issues.apache.org/jira/browse/IGNITE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128819#comment-16128819
]
Vladislav Pyatkov commented on IGNITE-6083:
---
I have prepare the test ([^EntryProcessorInOptimisticTxTest.java]).
> Null value have appear in the entry processor, but the entry is existing
>
>
> Key: IGNITE-6083
> URL: https://issues.apache.org/jira/browse/IGNITE-6083
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
> Attachments: EntryProcessorInOptimisticTxTest.java
>
>
> In one thread load some data in a cache, after that I have execute
> OPTIMISTIC, SERIALIZABLE transaction with two {{IgniteCache.invoke()}}
> methods.
> The value had been corrected at first {{EntryProcessor}}, but it is NULL at
> second.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away
[ https://issues.apache.org/jira/browse/IGNITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6044: Priority: Critical (was: Major) > SQL insert waits for transaction commit, but it must be executed right away > --- > > Key: IGNITE-6044 > URL: https://issues.apache.org/jira/browse/IGNITE-6044 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Priority: Critical > Fix For: 2.2 > > > Doc says: > ""Presently, DML supports the atomic mode only meaning that if there is a DML > query that is executed as a part of an Ignite transaction then it will not be > enlisted in the transaction's writing queue and will be executed right away."" > https://apacheignite.readme.io/docs/dml#section-transactional-support > However the data will be added to cache only after transaction commit. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6085) SQL: JOIN with multiple conditions is extremely slow
Vladimir Ozerov created IGNITE-6085:
---
Summary: SQL: JOIN with multiple conditions is extremely slow
Key: IGNITE-6085
URL: https://issues.apache.org/jira/browse/IGNITE-6085
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Fix For: 2.2
Consider the following query:
{code}
SELECT ... FROM A a
INNER JOIN B b ON b.id = a.foreign_id1 OR b.id = a.foreign_id2
{code}
In this case H2 cannot use indexes on {{foreign_id1}} or {{foreign_id2}}
columns and query execution takes extraordinary time. Known workaround for a
problem is to apply multiple JOINs, e.g.:
{code}
SELECT ... FROM A a
LEFT OUTER JOIN B b1 ON b1.id = a.foreign_id1
LEFT OUTER JOIN B b2 ON b2.id = a.foreign_id2
WHERE b1.id IS NOT NULL AND b2.id IS NOT NULL
{code}
On a single real-world scenario it improved exeution time by a factor of 500
(from 4s to 80ms).
Something is terribly wrong here. Probably, H2 cannot perform necessary query
re-write, or cannot understand how to use index. Let's find a way to fix that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away
[ https://issues.apache.org/jira/browse/IGNITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6044: Fix Version/s: 2.2 > SQL insert waits for transaction commit, but it must be executed right away > --- > > Key: IGNITE-6044 > URL: https://issues.apache.org/jira/browse/IGNITE-6044 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov > Fix For: 2.2 > > > Doc says: > ""Presently, DML supports the atomic mode only meaning that if there is a DML > query that is executed as a part of an Ignite transaction then it will not be > enlisted in the transaction's writing queue and will be executed right away."" > https://apacheignite.readme.io/docs/dml#section-transactional-support > However the data will be added to cache only after transaction commit. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6083) Null value have appear in the entry processor, but the entry is existing
[
https://issues.apache.org/jira/browse/IGNITE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-6083:
--
Attachment: EntryProcessorInOptimisticTxTest.java
> Null value have appear in the entry processor, but the entry is existing
>
>
> Key: IGNITE-6083
> URL: https://issues.apache.org/jira/browse/IGNITE-6083
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
> Attachments: EntryProcessorInOptimisticTxTest.java
>
>
> In one thread load some data in a cache, after that I have execute
> OPTIMISTIC, SERIALIZABLE transaction with two {{IgniteCache.invoke()}}
> methods.
> The value had been corrected at first {{EntryProcessor}}, but it is NULL at
> second.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away
[ https://issues.apache.org/jira/browse/IGNITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-6044: -- Environment: (was: Doc says: ""Presently, DML supports the atomic mode only meaning that if there is a DML query that is executed as a part of an Ignite transaction then it will not be enlisted in the transaction's writing queue and will be executed right away."" https://apacheignite.readme.io/docs/dml#section-transactional-support However the data will be added to cache only after transaction commit.) > SQL insert waits for transaction commit, but it must be executed right away > --- > > Key: IGNITE-6044 > URL: https://issues.apache.org/jira/browse/IGNITE-6044 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6084) SQL: improve lazy execution threading model
Vladimir Ozerov created IGNITE-6084:
---
Summary: SQL: improve lazy execution threading model
Key: IGNITE-6084
URL: https://issues.apache.org/jira/browse/IGNITE-6084
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Fix For: 2.2
Currently "lazy" mode creates new thread for every query. Moreover, messages
are queued to query pool first and then re-submitted to target thread. This
makes execution of small queries inefficient.
We need to do the following:
1) Define separate pool for lazy execution
2) It's size should be about 4 x cores, due to blocking nature of lazy execution
3) Set thread timeouts
4) Submit new query execute request to pool's shared queue from
{{GridIoManager}} directly
5) Submit "next page" requests to directly to proper thread, using [nodeId,
queryId, segment] triplet
6) Cancel request can be submitted to query pool and re-submitted to
appropriate threads afterwards.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6084) SQL: improve lazy execution threading model
[
https://issues.apache.org/jira/browse/IGNITE-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6084:
Labels: performance (was: )
> SQL: improve lazy execution threading model
> ---
>
> Key: IGNITE-6084
> URL: https://issues.apache.org/jira/browse/IGNITE-6084
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
> Labels: performance
> Fix For: 2.2
>
>
> Currently "lazy" mode creates new thread for every query. Moreover, messages
> are queued to query pool first and then re-submitted to target thread. This
> makes execution of small queries inefficient.
> We need to do the following:
> 1) Define separate pool for lazy execution
> 2) It's size should be about 4 x cores, due to blocking nature of lazy
> execution
> 3) Set thread timeouts
> 4) Submit new query execute request to pool's shared queue from
> {{GridIoManager}} directly
> 5) Submit "next page" requests to directly to proper thread, using [nodeId,
> queryId, segment] triplet
> 6) Cancel request can be submitted to query pool and re-submitted to
> appropriate threads afterwards.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away
[ https://issues.apache.org/jira/browse/IGNITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-6044: -- Description: Doc says: ""Presently, DML supports the atomic mode only meaning that if there is a DML query that is executed as a part of an Ignite transaction then it will not be enlisted in the transaction's writing queue and will be executed right away."" https://apacheignite.readme.io/docs/dml#section-transactional-support However the data will be added to cache only after transaction commit. > SQL insert waits for transaction commit, but it must be executed right away > --- > > Key: IGNITE-6044 > URL: https://issues.apache.org/jira/browse/IGNITE-6044 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov > > Doc says: > ""Presently, DML supports the atomic mode only meaning that if there is a DML > query that is executed as a part of an Ignite transaction then it will not be > enlisted in the transaction's writing queue and will be executed right away."" > https://apacheignite.readme.io/docs/dml#section-transactional-support > However the data will be added to cache only after transaction commit. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6081) .NET: Cannot get from cache values which were stored in cache with PutAll.
[
https://issues.apache.org/jira/browse/IGNITE-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-6081:
Description:
If you try to put multiple non-primitive values to cache using {{PutAll}},
you'd get an exception on attempt to read those values. Code example below:
{code}
var entries = new Dictionary();
for (int i = 0; i < 100; i++)
entries.Add(i, new SomeType { Id = i });
var cache = Ignition.GetIgnite().GetCache("CacheName");
cache.PutAll(entries);
cache.Get(42);
{code}
was:
If you try to put multiple non-primitive values to cache using {{PutAll}},
you'd get an exception on attempt to read those values. Code example below:
{code}
var entries = new Dictionary();
for (int i = 0; i < 100; i++)
entries.Add(i, new SomeType { Id = i });
var cache = Ignition.GetIgnite().GetCache("CacheName");
cache .PutAll(entries);
cache.Get(42);
{code}
> .NET: Cannot get from cache values which were stored in cache with PutAll.
> --
>
> Key: IGNITE-6081
> URL: https://issues.apache.org/jira/browse/IGNITE-6081
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Critical
>
> If you try to put multiple non-primitive values to cache using {{PutAll}},
> you'd get an exception on attempt to read those values. Code example below:
> {code}
> var entries = new Dictionary();
> for (int i = 0; i < 100; i++)
> entries.Add(i, new SomeType { Id = i });
> var cache = Ignition.GetIgnite().GetCache("CacheName");
> cache.PutAll(entries);
> cache.Get(42);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5756) Ignite with spark fails with class not found
[ https://issues.apache.org/jira/browse/IGNITE-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-5756: -- Fix Version/s: 2.2 > Ignite with spark fails with class not found > > > Key: IGNITE-5756 > URL: https://issues.apache.org/jira/browse/IGNITE-5756 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 1.9 > Environment: Apache ignite 1.9 with CDH 5.9 and spark 1.6 >Reporter: Rajesh >Assignee: Mikhail Cherkasov >Priority: Minor > Labels: starter > Fix For: 2.2 > > > I’m using ignite1.9 with CDH5.9. I’m unable to run sampe spark jobs with > below exception. I have followed the steps mentioned in documentation. > Type :help for more information. > Spark context available as sc (master = yarn-client, app id = > application_1499940258814_0024). > SQL context available as sqlContext. > scala> import org.apache.ignite.spark._ > import org.apache.ignite.spark._ > scala> import org.apache.ignite.configuration._ > import org.apache.ignite.configuration._ > scala> import javax.cache.configuration.MutableConfiguration > import javax.cache.configuration.MutableConfiguration > scala> val ic = new IgniteContext(sc, "config/default-config.xml") > class org.apache.ignite.IgniteCheckedException: Failed to create Ignite > component (consider adding ignite-spring module to classpath) > [component=SPRING, > cls=org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl] > at > org.apache.ignite.internal.IgniteComponentType.componentException(IgniteComponentType.java:320) > at > org.apache.ignite.internal.IgniteComponentType.create0(IgniteComponentType.java:296) > at > org.apache.ignite.internal.IgniteComponentType.create(IgniteComponentType.java:207) > at > org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:637) > at > org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:678) > at > org.apache.ignite.internal.IgnitionEx.loadConfiguration(IgnitionEx.java:717) > at > org.apache.ignite.spark.IgniteContext$$anonfun$$lessinit$greater$2.apply(IgniteContext.scala:84) > at > org.apache.ignite.spark.IgniteContext$$anonfun$$lessinit$greater$2.apply(IgniteContext.scala:84) > at org.apache.ignite.spark.Once.apply(IgniteContext.scala:197) > at > org.apache.ignite.spark.IgniteContext.ignite(IgniteContext.scala:137) > at > org.apache.ignite.spark.IgniteContext.(IgniteContext.scala:58) > at > org.apache.ignite.spark.IgniteContext.(IgniteContext.scala:84) > at > $iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC.(:34) > at > $iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC.(:39) > at > $iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC.(:41) > at $iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC.(:43) > at $iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC.(:45) > at $iwC$$iwC$$iwC$$iwC$$iwC$$iwC$$iwC.(:47) > at $iwC$$iwC$$iwC$$iwC$$iwC$$iwC.(:49) > at $iwC$$iwC$$iwC$$iwC$$iwC.(:51) > at $iwC$$iwC$$iwC$$iwC.(:53) > at $iwC$$iwC$$iwC.(:55) > at $iwC$$iwC.(:57) > at $iwC.(:59) > at (:61) > at .(:65) > at .() > at .(:7) > at .() > at $print() > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.apache.spark.repl.SparkIMain$ReadEvalPrint.call(SparkIMain.scala:1045) > at > org.apache.spark.repl.SparkIMain$Request.loadAndRun(SparkIMain.scala:1326) > at > org.apache.spark.repl.SparkIMain.loadAndRunReq$1(SparkIMain.scala:821) > at org.apache.spark.repl.SparkIMain.interpret(SparkIMain.scala:852) > at org.apache.spark.repl.SparkIMain.interpret(SparkIMain.scala:800) > at > org.apache.spark.repl.SparkILoop.reallyInterpret$1(SparkILoop.scala:857) > at > org.apache.spark.repl.SparkILoop.interpretStartingWith(SparkILoop.scala:902) > at org.apache.spark.repl.SparkILoop.command(SparkILoop.scala:814) > at > org.apache.spark.repl.SparkILoop.processLine$1(SparkILoop.scala:657) > at org.apache.spark.repl.SparkILoop.innerLoop$1(SparkILoop.scala:665) > at > org.apache.spark.repl.SparkILoop.org$apache$spark$repl$SparkILoop$$loop(SparkILoop.scala:670) > at > org.apache.spark.repl.SparkILoop$$anonfun$org$apache$spark$repl$SparkILoop$$process$1.apply$mcZ$sp(SparkILoop.scala:997) >
[jira] [Created] (IGNITE-6083) Null value have appear in the entry processor, but the entry is existing
Vladislav Pyatkov created IGNITE-6083:
-
Summary: Null value have appear in the entry processor, but the
entry is existing
Key: IGNITE-6083
URL: https://issues.apache.org/jira/browse/IGNITE-6083
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.1
Reporter: Vladislav Pyatkov
In one thread load some data in a cache, after that I have execute OPTIMISTIC,
SERIALIZABLE transaction with two {{IgniteCache.invoke()}} methods.
The value had been corrected at first {{EntryProcessor}}, but it is NULL at
second.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6082) Test fail DynamicIndexPartitionedTransactionalConcurrentSelfTest.testConcurrentPutRemove
[
https://issues.apache.org/jira/browse/IGNITE-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-6082:
---
Labels: MakeTeamcityGreenAgain (was: )
> Test fail
> DynamicIndexPartitionedTransactionalConcurrentSelfTest.testConcurrentPutRemove
>
> -
>
> Key: IGNITE-6082
> URL: https://issues.apache.org/jira/browse/IGNITE-6082
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.0
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> It is because test use multicast ip finder.
> {code}
> junit.framework.AssertionFailedError: Found nodes from different clusters,
> probable some test does not stop nodes
> [allNodes=[index.DynamicIndexPartitionedTransactionalConcurrentSelfTest2,
> index.DynamicIndexPartitionedTransactionalConcurrentSelfTest4]]
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:599)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:537)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:521)
> at
> org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractConcurrentSelfTest.testConcurrentPutRemove(DynamicIndexAbstractConcurrentSelfTest.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6082) Test fail DynamicIndexPartitionedTransactionalConcurrentSelfTest.testConcurrentPutRemove
[
https://issues.apache.org/jira/browse/IGNITE-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-6082:
---
Description:
{code}
junit.framework.AssertionFailedError: Found nodes from different clusters,
probable some test does not stop nodes
[allNodes=[index.DynamicIndexPartitionedTransactionalConcurrentSelfTest2,
index.DynamicIndexPartitionedTransactionalConcurrentSelfTest4]]
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:599)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:537)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:521)
at
org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractConcurrentSelfTest.testConcurrentPutRemove(DynamicIndexAbstractConcurrentSelfTest.java:292)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{code}
> Test fail
> DynamicIndexPartitionedTransactionalConcurrentSelfTest.testConcurrentPutRemove
>
> -
>
> Key: IGNITE-6082
> URL: https://issues.apache.org/jira/browse/IGNITE-6082
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.0
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> {code}
> junit.framework.AssertionFailedError: Found nodes from different clusters,
> probable some test does not stop nodes
> [allNodes=[index.DynamicIndexPartitionedTransactionalConcurrentSelfTest2,
> index.DynamicIndexPartitionedTransactionalConcurrentSelfTest4]]
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:599)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:537)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:521)
> at
> org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractConcurrentSelfTest.testConcurrentPutRemove(DynamicIndexAbstractConcurrentSelfTest.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6082) Test fail DynamicIndexPartitionedTransactionalConcurrentSelfTest.testConcurrentPutRemove
[
https://issues.apache.org/jira/browse/IGNITE-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-6082:
---
Description:
It is because test use multicast ip finder.
{code}
junit.framework.AssertionFailedError: Found nodes from different clusters,
probable some test does not stop nodes
[allNodes=[index.DynamicIndexPartitionedTransactionalConcurrentSelfTest2,
index.DynamicIndexPartitionedTransactionalConcurrentSelfTest4]]
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:599)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:537)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:521)
at
org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractConcurrentSelfTest.testConcurrentPutRemove(DynamicIndexAbstractConcurrentSelfTest.java:292)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{code}
was:
{code}
junit.framework.AssertionFailedError: Found nodes from different clusters,
probable some test does not stop nodes
[allNodes=[index.DynamicIndexPartitionedTransactionalConcurrentSelfTest2,
index.DynamicIndexPartitionedTransactionalConcurrentSelfTest4]]
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:599)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:537)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:521)
at
org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractConcurrentSelfTest.testConcurrentPutRemove(DynamicIndexAbstractConcurrentSelfTest.java:292)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{code}
> Test fail
> DynamicIndexPartitionedTransactionalConcurrentSelfTest.testConcurrentPutRemove
>
> -
>
> Key: IGNITE-6082
> URL: https://issues.apache.org/jira/browse/IGNITE-6082
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.0
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> It is because test use multicast ip finder.
> {code}
> junit.framework.AssertionFailedError: Found nodes from different clusters,
> probable some test does not stop nodes
> [allNodes=[index.DynamicIndexPartitionedTransactionalConcurrentSelfTest2,
> index.DynamicIndexPartitionedTransactionalConcurrentSelfTest4]]
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:599)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:537)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:521)
> at
> org.apache.ignite.i
[jira] [Created] (IGNITE-6082) Test fail DynamicIndexPartitionedTransactionalConcurrentSelfTest.testConcurrentPutRemove
Dmitriy Govorukhin created IGNITE-6082: -- Summary: Test fail DynamicIndexPartitionedTransactionalConcurrentSelfTest.testConcurrentPutRemove Key: IGNITE-6082 URL: https://issues.apache.org/jira/browse/IGNITE-6082 Project: Ignite Issue Type: Test Affects Versions: 2.0 Reporter: Dmitriy Govorukhin Assignee: Dmitriy Govorukhin Fix For: 2.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes
[
https://issues.apache.org/jira/browse/IGNITE-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128768#comment-16128768
]
Roman Shtykh commented on IGNITE-6053:
--
[~ntikhonov] You are right. Please see the changes.
Is it correct that all parameters of {{clearLocally}} have to be _true_?
> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.2
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all
> nodes, that have local caches with same names.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6081) .NET: Cannot get from cache values which were stored in cache with PutAll.
[
https://issues.apache.org/jira/browse/IGNITE-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-6081:
Priority: Critical (was: Major)
> .NET: Cannot get from cache values which were stored in cache with PutAll.
> --
>
> Key: IGNITE-6081
> URL: https://issues.apache.org/jira/browse/IGNITE-6081
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Critical
>
> If you try to put multiple non-primitive values to cache using {{PutAll}},
> you'd get an exception on attempt to read those values. Code example below:
> {code}
> var entries = new Dictionary();
> for (int i = 0; i < 100; i++)
> entries.Add(i, new SomeType { Id = i });
> var cache = Ignition.GetIgnite().GetCache("CacheName");
> cache .PutAll(entries);
> cache.Get(42);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6080) SQL: Batch DML updates on per-node basis
[
https://issues.apache.org/jira/browse/IGNITE-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128764#comment-16128764
]
Vladimir Ozerov commented on IGNITE-6080:
-
Done. Waiting for tests.
> SQL: Batch DML updates on per-node basis
>
>
> Key: IGNITE-6080
> URL: https://issues.apache.org/jira/browse/IGNITE-6080
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Labels: performance
> Fix For: 2.2
>
>
> Currently DML updates are batched and then applied using
> {{IgniteCache.invokeAll}}. See
> {{org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor#processPage}}.
> This is not efficient, because typical update will hit a lot of data nodes.
> Instead, we should create separate batches for every primary node. This way
> we can significantly improve update performance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6080) SQL: Batch DML updates on per-node basis
[
https://issues.apache.org/jira/browse/IGNITE-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128762#comment-16128762
]
ASF GitHub Bot commented on IGNITE-6080:
GitHub user devozerov opened a pull request:
https://github.com/apache/ignite/pull/2454
IGNITE-6080
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6080
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2454.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2454
commit b562886d8e73a08667115c69b0bf78bd397452d0
Author: devozerov
Date: 2017-08-16T12:22:41Z
Minors.
> SQL: Batch DML updates on per-node basis
>
>
> Key: IGNITE-6080
> URL: https://issues.apache.org/jira/browse/IGNITE-6080
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Labels: performance
> Fix For: 2.2
>
>
> Currently DML updates are batched and then applied using
> {{IgniteCache.invokeAll}}. See
> {{org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor#processPage}}.
> This is not efficient, because typical update will hit a lot of data nodes.
> Instead, we should create separate batches for every primary node. This way
> we can significantly improve update performance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6081) .NET: Cannot get from cache values which were stored in cache with PutAll.
Igor Sapego created IGNITE-6081:
---
Summary: .NET: Cannot get from cache values which were stored in
cache with PutAll.
Key: IGNITE-6081
URL: https://issues.apache.org/jira/browse/IGNITE-6081
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.1
Reporter: Igor Sapego
Assignee: Pavel Tupitsyn
If you try to put multiple non-primitive values to cache using {{PutAll}},
you'd get an exception on attempt to read those values. Code example below:
{code}
var entries = new Dictionary();
for (int i = 0; i < 100; i++)
entries.Add(i, new SomeType { Id = i });
var cache = Ignition.GetIgnite().GetCache("CacheName");
cache .PutAll(entries);
cache.Get(42);
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-5842) ODBC: Make sure ODBC driver works correctly with RazorSQL.
[
https://issues.apache.org/jira/browse/IGNITE-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego resolved IGNITE-5842.
-
Resolution: Fixed
All found issues resolved. Works now.
> ODBC: Make sure ODBC driver works correctly with RazorSQL.
> --
>
> Key: IGNITE-5842
> URL: https://issues.apache.org/jira/browse/IGNITE-5842
> Project: Ignite
> Issue Type: Improvement
> Components: odbc
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: odbc
> Fix For: 2.2
>
>
> Users often try to use ODBC driver to connect to Ignite with RazorSQL.
> However, it can't be used with our driver, as it tries to configure driver to
> act according to unsupported ODBC version. Here is the log:
> {noformat}
> razorsql12d8-1374 ENTER SQLAllocEnv
> HENV * 0x2FBEECB0
> razorsql12d8-1374 EXIT SQLAllocEnv with return code 0
> (SQL_SUCCESS)
> HENV * 0x2FBEECB0 ( 0x003DE650)
> razorsql12d8-1374 ENTER SQLAllocConnect
> HENV0x003DE650
> HDBC * 0x2FBEEC10
> razorsql12d8-1374 EXIT SQLAllocConnect with return code 0
> (SQL_SUCCESS)
> HENV0x003DE650
> HDBC * 0x2FBEEC10 ( 0x003DE6D0)
> razorsql12d8-1374 ENTER SQLSetConnectOption
> HDBC0x003DE6D0
> SQLINTEGER 103
> SQLPOINTER35
> razorsql12d8-1374 EXIT SQLSetConnectOption with return code 0
> (SQL_SUCCESS)
> HDBC0x003DE6D0
> SQLINTEGER 103
> SQLPOINTER35
> razorsql12d8-1374 ENTER SQLDriverConnectW
> HDBC0x003DE6D0
> HWND0x
> WCHAR * 0x6F861F7C [ -3] "**\ 0"
> SWORD -3
> WCHAR * 0x6F861F7C
> SWORD -3
> SWORD * 0x
> UWORD0
> razorsql12d8-1374 EXIT SQLDriverConnectW with return code -1
> (SQL_ERROR)
> HDBC0x003DE6D0
> HWND0x
> WCHAR * 0x6F861F7C [ -3] "**\ 0"
> SWORD -3
> WCHAR * 0x6F861F7C
> SWORD -3
> SWORD * 0x
> UWORD0
> DIAG [S1000] ODBC version is not supported. (0)
> DIAG [08001] Failed to establish connection with the host. (0)
> razorsql12d8-1374 ENTER SQLErrorW
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4
> SDWORD *0x2FBEEB3C
> WCHAR * 0x2FBEE6F4
> SWORD 300
> SWORD * 0x2FBEEB38
> razorsql12d8-1374 EXIT SQLErrorW with return code 0
> (SQL_SUCCESS)
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4 [ 5] "S1000"
> SDWORD *0x2FBEEB3C (0)
> WCHAR * 0x2FBEE6F4 [ 30] "ODBC version is not
> supported."
> SWORD 300
> SWORD * 0x2FBEEB38 (30)
> razorsql12d8-1374 ENTER SQLErrorW
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4
> SDWORD *0x2FBEEB3C
> WCHAR * 0x2FBEE6F4
> SWORD 300
> SWORD * 0x2FBEEB38
> razorsql12d8-1374 EXIT SQLErrorW with return code 0
> (SQL_SUCCESS)
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4 [ 5] "08001"
> SDWORD *0x2FBEEB3C (0)
> WCHAR * 0x2FBEE6F4 [ 45] "Failed to establish
> connection with the host."
> SWORD 300
>
[jira] [Updated] (IGNITE-6032) ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
[
https://issues.apache.org/jira/browse/IGNITE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-6032:
Issue Type: Improvement (was: Bug)
> ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
>
>
> Key: IGNITE-6032
> URL: https://issues.apache.org/jira/browse/IGNITE-6032
> Project: Ignite
> Issue Type: Improvement
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently {{SQLGetInfo}} does not support {{SQL_SCROLL_OPTIONS}}. Need to add
> support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6080) SQL: Batch DML updates on per-node basis
Vladimir Ozerov created IGNITE-6080:
---
Summary: SQL: Batch DML updates on per-node basis
Key: IGNITE-6080
URL: https://issues.apache.org/jira/browse/IGNITE-6080
Project: Ignite
Issue Type: Task
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 2.2
Currently DML updates are batched and then applied using
{{IgniteCache.invokeAll}}. See
{{org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor#processPage}}.
This is not efficient, because typical update will hit a lot of data nodes.
Instead, we should create separate batches for every primary node. This way we
can significantly improve update performance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6026) init cluster for Ignite Persistence by xml
[ https://issues.apache.org/jira/browse/IGNITE-6026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128676#comment-16128676 ] Alex Negashev commented on IGNITE-6026: --- Hello Alexey, there is no free time to check the setting, I will try in the next two weeks > init cluster for Ignite Persistence by xml > --- > > Key: IGNITE-6026 > URL: https://issues.apache.org/jira/browse/IGNITE-6026 > Project: Ignite > Issue Type: Wish > Components: cache, examples, persistence >Affects Versions: 2.1 > Environment: ignite in docker with zk >Reporter: Alex Negashev >Assignee: Alexey Kukushkin > Labels: documentation > > Hello! We use Ignite 2.1 and would like to use Ignite Persistence, how i can > do this without java code? xml only. > Example attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6079) SQL: implement base table statistics
[
https://issues.apache.org/jira/browse/IGNITE-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6079:
Labels: performance (was: )
> SQL: implement base table statistics
>
>
> Key: IGNITE-6079
> URL: https://issues.apache.org/jira/browse/IGNITE-6079
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
> Labels: performance
> Fix For: 2.2
>
>
> Ignite lacks cost-based optimizer what doesn't allow us to build efficient
> execution plans. Let's start moving in this direction.
> The ticket is about creating local statistics for tables. In the first phase
> they will not be shared between nodes, neither they will participate in query
> optimization. The ultimate goal of this ticket is to start gathering some
> info in the background and provide necessary internal infrastructure and APIs
> for that.
> *1. API*
> Let's start with a single method {{GridQueryProcessor.rebuildStatistics()}},
> which will build stats for all existing tables.
> *2. Infrastructure*
> - Statistics are transient, not persisted
> - We need a background worker which will re-build them on regular basis and
> replace old with new using copy-on-write approach
> - Statistics are created for indexed (i.e. sorted) columns
> - Sampling should be used to avoid full table scan
> *3. Statistics types*
> - Height-based: the whole range is split into N pieces, so that exactly M/N
> entries are located between X and X+1 piece, where M is number of records
> One statistics type should be enough in the first iteration.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6079) SQL: implement base table statistics
Vladimir Ozerov created IGNITE-6079:
---
Summary: SQL: implement base table statistics
Key: IGNITE-6079
URL: https://issues.apache.org/jira/browse/IGNITE-6079
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Fix For: 2.2
Ignite lacks cost-based optimizer what doesn't allow us to build efficient
execution plans. Let's start moving in this direction.
The ticket is about creating local statistics for tables. In the first phase
they will not be shared between nodes, neither they will participate in query
optimization. The ultimate goal of this ticket is to start gathering some info
in the background and provide necessary internal infrastructure and APIs for
that.
*1. API*
Let's start with a single method {{GridQueryProcessor.rebuildStatistics()}},
which will build stats for all existing tables.
*2. Infrastructure*
- Statistics are transient, not persisted
- We need a background worker which will re-build them on regular basis and
replace old with new using copy-on-write approach
- Statistics are created for indexed (i.e. sorted) columns
- Sampling should be used to avoid full table scan
*3. Statistics types*
- Height-based: the whole range is split into N pieces, so that exactly M/N
entries are located between X and X+1 piece, where M is number of records
One statistics type should be enough in the first iteration.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5586) Visor CMD: Add possibility to activate/deactivate grid
[ https://issues.apache.org/jira/browse/IGNITE-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-5586: --- Fix Version/s: 2.2 > Visor CMD: Add possibility to activate/deactivate grid > -- > > Key: IGNITE-5586 > URL: https://issues.apache.org/jira/browse/IGNITE-5586 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 2.1 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko > Fix For: 2.2 > > > Extend top command to activate/deactivate grid. Wait fix IGNITE-5584. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6078) Possible deadlock on concurrent grid stop
[ https://issues.apache.org/jira/browse/IGNITE-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-6078: - Description: Look at Thread-6 which holds lock on IgnitionEx and trying to acquire DataStreamProcessor's busyLock and thread main, which is trying to acquire lock on IgnitionEx and at data-streamer-stripe-6 which holds DataStreamProcessor's busyLock and trying to acquire checkpointLock, which is locked because Thread-6 cannot finish the checkpoint was: Look at Thread-6 which holds lock on IgnitionEx and trying to acquire DataStreamProcessor's busyLock and thread main, which is trying to acquire lock on IgnitionEx and at data-streamer-stripe-6 which holds readWrite DataStreamProcessor's busyLock and trying to acquire checkpointLock, which is locked because Thread-6 cannot finish the checkpoint > Possible deadlock on concurrent grid stop > - > > Key: IGNITE-6078 > URL: https://issues.apache.org/jira/browse/IGNITE-6078 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.1 >Reporter: Igor Seliverstov > Fix For: 2.2 > > Attachments: tread_dump.txt > > > Look at Thread-6 which holds lock on IgnitionEx and trying to acquire > DataStreamProcessor's busyLock > and thread main, which is trying to acquire lock on IgnitionEx > and at data-streamer-stripe-6 which holds DataStreamProcessor's busyLock and > trying to acquire checkpointLock, which is locked because Thread-6 cannot > finish the checkpoint -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6075) CacheLoadingConcurrentGridStartSelfTest sometimes fails
[
https://issues.apache.org/jira/browse/IGNITE-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-6075:
-
Labels: MakeTeamcityGreenAgain (was: )
> CacheLoadingConcurrentGridStartSelfTest sometimes fails
> ---
>
> Key: IGNITE-6075
> URL: https://issues.apache.org/jira/browse/IGNITE-6075
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Seems that not all keys are in a cache after loading via DataStreamer
> {{CacheLoadingConcurrentGridStartSelfTest.testLoadCacheWithDataStreamerSequential}}
> {noformat}
> [2017-08-15 13:25:38,435][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Streaming 30'th entry.
> [2017-08-15 13:25:39,277][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Streaming 40'th entry.
> [2017-08-15 13:25:40,100][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Streaming 50'th entry.
> [2017-08-15 13:25:40,866][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Streaming 60'th entry.
> [2017-08-15 13:25:41,666][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Streaming 70'th entry.
> [2017-08-15 13:25:42,453][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Streaming 80'th entry.
> [2017-08-15 13:25:43,211][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Streaming 90'th entry.
> [2017-08-15 13:25:43,944][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Data loaded.
> [2017-08-15 13:26:06,518][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Actual cache size: 98
> [2017-08-15 13:26:06,519][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Missed key info:8fe76132-b563-4b7e-b611-386f5de4 primary=true
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Missed key info:b774fe8f-849a-4b1f-abf6-26acd5f2 primary=false
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Missed key info:d4f4a4ae-a1e3-4c6b-90b8-823898c3 primary=false
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Missed key info:17a2d999-045e-4e58-8be6-55930a30 primary=false
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
> Missed key info:e18c8fb1-c972-4a75-901c-818bbf91 primary=false
> backup=true local peek=null
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6026) init cluster for Ignite Persistence by xml
[ https://issues.apache.org/jira/browse/IGNITE-6026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128653#comment-16128653 ] Alexey Kukushkin commented on IGNITE-6026: -- Hi Alex, Please let me know if something is still not working for you. Otherwise I will resolve the ticket. Thanks! > init cluster for Ignite Persistence by xml > --- > > Key: IGNITE-6026 > URL: https://issues.apache.org/jira/browse/IGNITE-6026 > Project: Ignite > Issue Type: Wish > Components: cache, examples, persistence >Affects Versions: 2.1 > Environment: ignite in docker with zk >Reporter: Alex Negashev >Assignee: Alexey Kukushkin > Labels: documentation > > Hello! We use Ignite 2.1 and would like to use Ignite Persistence, how i can > do this without java code? xml only. > Example attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6078) Possible deadlock on concurrent grid stop
[ https://issues.apache.org/jira/browse/IGNITE-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-6078: - Attachment: tread_dump.txt > Possible deadlock on concurrent grid stop > - > > Key: IGNITE-6078 > URL: https://issues.apache.org/jira/browse/IGNITE-6078 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.1 >Reporter: Igor Seliverstov > Fix For: 2.2 > > Attachments: tread_dump.txt > > > Look at Thread-6 which holds lock on IgnitionEx and trying to acquire > DataStreamProcessor's busyLock > and thread main, which is trying to acquire lock on IgnitionEx > and at data-streamer-stripe-6 which holds readWrite DataStreamProcessor's > busyLock and trying to acquire checkpointLock, which is locked because > Thread-6 cannot finish the checkpoint -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6078) Possible deadlock on concurrent grid stop
Igor Seliverstov created IGNITE-6078: Summary: Possible deadlock on concurrent grid stop Key: IGNITE-6078 URL: https://issues.apache.org/jira/browse/IGNITE-6078 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.1 Reporter: Igor Seliverstov Fix For: 2.2 Look at Thread-6 which holds lock on IgnitionEx and trying to acquire DataStreamProcessor's busyLock and thread main, which is trying to acquire lock on IgnitionEx and at data-streamer-stripe-6 which holds readWrite DataStreamProcessor's busyLock and trying to acquire checkpointLock, which is locked because Thread-6 cannot finish the checkpoint -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6077) IgniteWalRecoveryTest.testWalRolloverMultithreadedDefault fails
Sergey Chugunov created IGNITE-6077:
---
Summary: IgniteWalRecoveryTest.testWalRolloverMultithreadedDefault
fails
Key: IGNITE-6077
URL: https://issues.apache.org/jira/browse/IGNITE-6077
Project: Ignite
Issue Type: Bug
Affects Versions: 2.1
Reporter: Sergey Chugunov
Fix For: 2.2
Test fails with the following stack trace in logs:
{noformat}
Suppressed: class org.apache.ignite.internal.pagemem.wal.StorageException: null
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2037)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$1700(FileWriteAheadLogManager.java:1636)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.fsync(FileWriteAheadLogManager.java:538)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1825)
... 14 more
Caused by: java.nio.channels.AsynchronousCloseException
at
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:205)
at sun.nio.ch.FileChannelImpl.force(FileChannelImpl.java:380)
at
org.apache.ignite.internal.processors.cache.persistence.file.RandomAccessFileIO.force(RandomAccessFileIO.java:92)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2034)
... 17 more
{noformat}
Test history on TC is available
[here|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=2317518850927682700&tab=testDetails].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6076) SQL: Local query should not go through map-reduce phase
Vladimir Ozerov created IGNITE-6076:
---
Summary: SQL: Local query should not go through map-reduce phase
Key: IGNITE-6076
URL: https://issues.apache.org/jira/browse/IGNITE-6076
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Fix For: 2.2
Typical query execution consists of map and reduce phases. But if {{local}}
flag is set, there is no need for splitting. Instead, we should execute the
request in a single map phase, without involving reducer at all.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6074) Test fail IgniteWalRecoveryTest#testWalBigObjectNodeCancel
[
https://issues.apache.org/jira/browse/IGNITE-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128645#comment-16128645
]
ASF GitHub Bot commented on IGNITE-6074:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2452
> Test fail IgniteWalRecoveryTest#testWalBigObjectNodeCancel
> --
>
> Key: IGNITE-6074
> URL: https://issues.apache.org/jira/browse/IGNITE-6074
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.2
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> {code}
> Exception in thread "exchange-worker-#79%wal.IgniteWalRecoveryTest1%"
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:110)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput$Crc32CheckingFileInput.ensure(FileInput.java:303)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput$Crc32CheckingFileInput.readFully(FileInput.java:351)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readDataEntry(RecordV1Serializer.java:1550)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readRecord(RecordV1Serializer.java:799)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readRecord(RecordV1Serializer.java:673)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advanceRecord(AbstractWalRecordsIterator.java:208)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advance(AbstractWalRecordsIterator.java:153)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.onNext(AbstractWalRecordsIterator.java:120)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.onNext(AbstractWalRecordsIterator.java:43)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:41)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1321)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:534)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:463)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1954)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: class
> org.apache.ignite.internal.processors.cache.persistence.wal.crc.IgniteDataIntegrityViolationException:
> val: 78139338 writtenCrc: 262144
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput$Crc32CheckingFileInput.close(FileInput.java:320)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readRecord(RecordV1Serializer.java:680)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
