[jira] [Commented] (IGNITE-9558) Avoid changing AffinityTopologyVersion on client connect when possible
[
https://issues.apache.org/jira/browse/IGNITE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681867#comment-16681867
]
Ignite TC Bot commented on IGNITE-9558:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2281388buildTypeId=IgniteTests24Java8_RunAll]
> Avoid changing AffinityTopologyVersion on client connect when possible
> --
>
> Key: IGNITE-9558
> URL: https://issues.apache.org/jira/browse/IGNITE-9558
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.8
>
>
> Currently a client join event changes discovery topology version which, in
> turn, changes AffinityTopologyVersion.
> When a client maps transaction on new AffinityTopologyVersion, corresponding
> message is not processed on remote node until remote node receives the
> corresponding discovery event. If discovery event delivery is delayed for
> some reason, this will result in transaction stalls on client joins.
> Since the client node does not change partition affinity, we can safely map
> transactions on the previous topology version and do not change the affinity
> topology version at all.
> Some cases need special care and probably do not qualify for this
> optimization, such as when client has near cache or client hosts partition
> for REPLICATED cache.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-6111) SQL: Add ability to do INSERT without specifying the column names
[
https://issues.apache.org/jira/browse/IGNITE-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681752#comment-16681752
]
Ilya Suntsov edited comment on IGNITE-6111 at 11/9/18 6:10 PM:
---
I've found the problem that relates with this feature in ignite-2.7.
Step 1
{noformat}
19/23 CREATE TABLE CUSTOMER ( C_CUSTKEY INTEGER NOT NULL PRIMARY KEY,
C_NAME VARCHAR(25) NOT NULL,
C_ADDRESS VARCHAR(40) NOT NULL,
C_NATIONKEY INTEGER NOT NULL,
C_PHONE CHAR(15) NOT NULL,
C_ACCTBAL DECIMAL(15,2) NOT NULL,
C_MKTSEGMENT CHAR(10) NOT NULL,
C_COMMENT VARCHAR(117) NOT NULL)
WITH "atomicity=ATOMIC";
{noformat}
Step 2
{noformat}
Error: Failed to parse query. Column "1" not found; SQL statement:
INSERT INTO customer VALUES ("1","Customer#1","IVhzIApeRb
ot,c,E","15","25-989-741-2988","711.56","BUILDING","to the even, regular
platelets. regular, ironic epitaphs nag e") [42122-197] (state=42000,code=1001)
java.sql.SQLException: Failed to parse query. Column "1" not found; SQL
statement:
INSERT INTO customer VALUES ("1","Customer#1","IVhzIApeRb
ot,c,E","15","25-989-741-2988","711.56","BUILDING","to the even, regular
platelets. regular, ironic epitaphs nag e") [42122-197]
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:814)
at sqlline.Commands.sql(Commands.java:754)
at sqlline.SqlLine.dispatch(SqlLine.java:646)
at sqlline.SqlLine.runCommands(SqlLine.java:1681)
at sqlline.Commands.run(Commands.java:1393)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:643)
at sqlline.SqlLine.initArgs(SqlLine.java:427)
at sqlline.SqlLine.begin(SqlLine.java:485)
at sqlline.SqlLine.start(SqlLine.java:233)
at sqlline.SqlLine.main(SqlLine.java:175)
Aborting command set because "force" is false and command failed: "INSERT INTO
customer VALUES ("1","Customer#1","IVhzIApeRb
ot,c,E","15","25-989-741-2988","711.56","BUILDING","to the even, regular
platelets. regular, ironic epitaphs nag e");"
Closing: org.apache.ignite.internal.jdbc.thin.JdbcThinConnection
{noformat}
was (Author: ustas):
I've found the problem that relates with this feature.
Step 1
{noformat}
19/23 CREATE TABLE CUSTOMER ( C_CUSTKEY INTEGER NOT NULL PRIMARY KEY,
C_NAME VARCHAR(25) NOT NULL,
C_ADDRESS VARCHAR(40) NOT NULL,
C_NATIONKEY INTEGER NOT NULL,
C_PHONE CHAR(15) NOT NULL,
C_ACCTBAL DECIMAL(15,2) NOT NULL,
C_MKTSEGMENT CHAR(10) NOT NULL,
C_COMMENT VARCHAR(117) NOT NULL)
WITH "atomicity=ATOMIC";
{noformat}
Step 2
{noformat}
Error: Failed to parse query. Column "1" not found; SQL statement:
INSERT INTO customer VALUES ("1","Customer#1","IVhzIApeRb
ot,c,E","15","25-989-741-2988","711.56","BUILDING","to the even, regular
platelets. regular, ironic epitaphs nag e") [42122-197] (state=42000,code=1001)
java.sql.SQLException: Failed to parse query. Column "1" not found; SQL
statement:
INSERT INTO customer VALUES ("1","Customer#1","IVhzIApeRb
ot,c,E","15","25-989-741-2988","711.56","BUILDING","to the even, regular
platelets. regular, ironic epitaphs nag e") [42122-197]
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:814)
at sqlline.Commands.sql(Commands.java:754)
at sqlline.SqlLine.dispatch(SqlLine.java:646)
at sqlline.SqlLine.runCommands(SqlLine.java:1681)
at sqlline.Commands.run(Commands.java:1393)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:643)
at sqlline.SqlLine.initArgs(SqlLine.java:427)
at sqlline.SqlLine.begin(SqlLine.java:485)
at sqlline.SqlLine.start(SqlLine.java:233)
at sqlline.SqlLine.main(SqlLine.java:175)
Aborting command set because "force" is false and command failed: "INSERT INTO
customer VALUES
[jira] [Commented] (IGNITE-9843) IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta without losing data
[ https://issues.apache.org/jira/browse/IGNITE-9843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681768#comment-16681768 ] ASF GitHub Bot commented on IGNITE-9843: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5027 > IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta > without losing data > -- > > Key: IGNITE-9843 > URL: https://issues.apache.org/jira/browse/IGNITE-9843 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > >
[jira] [Comment Edited] (IGNITE-10018) Documentation: manage SQL (ODBC\JDBC\Thin) clients via JMX.
[ https://issues.apache.org/jira/browse/IGNITE-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681754#comment-16681754 ] Prachi Garg edited comment on IGNITE-10018 at 11/9/18 5:54 PM: --- [~Artem Budnikov], looks good. [~dmagda], please review. was (Author: pgarg): [~Artem Budnikov], look good. [~dmagda], please review. > Documentation: manage SQL (ODBC\JDBC\Thin) clients via JMX. > --- > > Key: IGNITE-10018 > URL: https://issues.apache.org/jira/browse/IGNITE-10018 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Andrew Mashenkov >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > > We have to add IGNITE-8628 changes to documantation. > > org.apache.ignite.mxbean.ClientProcessorMXBean interface for MBean was added. > MBean can be accessed from any JMX management console with name containing > "igniteInstanceName= name>,group=Clients,name=ClientListenerProcessor". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10018) Documentation: manage SQL (ODBC\JDBC\Thin) clients via JMX.
[ https://issues.apache.org/jira/browse/IGNITE-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-10018: Assignee: Denis Magda (was: Prachi Garg) > Documentation: manage SQL (ODBC\JDBC\Thin) clients via JMX. > --- > > Key: IGNITE-10018 > URL: https://issues.apache.org/jira/browse/IGNITE-10018 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Andrew Mashenkov >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > We have to add IGNITE-8628 changes to documantation. > > org.apache.ignite.mxbean.ClientProcessorMXBean interface for MBean was added. > MBean can be accessed from any JMX management console with name containing > "igniteInstanceName= name>,group=Clients,name=ClientListenerProcessor". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10018) Documentation: manage SQL (ODBC\JDBC\Thin) clients via JMX.
[ https://issues.apache.org/jira/browse/IGNITE-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681754#comment-16681754 ] Prachi Garg commented on IGNITE-10018: -- [~Artem Budnikov], look good. [~dmagda], please review. > Documentation: manage SQL (ODBC\JDBC\Thin) clients via JMX. > --- > > Key: IGNITE-10018 > URL: https://issues.apache.org/jira/browse/IGNITE-10018 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Andrew Mashenkov >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > > We have to add IGNITE-8628 changes to documantation. > > org.apache.ignite.mxbean.ClientProcessorMXBean interface for MBean was added. > MBean can be accessed from any JMX management console with name containing > "igniteInstanceName= name>,group=Clients,name=ClientListenerProcessor". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6111) SQL: Add ability to do INSERT without specifying the column names
[
https://issues.apache.org/jira/browse/IGNITE-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681752#comment-16681752
]
Ilya Suntsov commented on IGNITE-6111:
--
I've found the problem that relates with this feature.
Step 1
{noformat}
19/23 CREATE TABLE CUSTOMER ( C_CUSTKEY INTEGER NOT NULL PRIMARY KEY,
C_NAME VARCHAR(25) NOT NULL,
C_ADDRESS VARCHAR(40) NOT NULL,
C_NATIONKEY INTEGER NOT NULL,
C_PHONE CHAR(15) NOT NULL,
C_ACCTBAL DECIMAL(15,2) NOT NULL,
C_MKTSEGMENT CHAR(10) NOT NULL,
C_COMMENT VARCHAR(117) NOT NULL)
WITH "atomicity=ATOMIC";
{noformat}
Step 2
{noformat}
Error: Failed to parse query. Column "1" not found; SQL statement:
INSERT INTO customer VALUES ("1","Customer#1","IVhzIApeRb
ot,c,E","15","25-989-741-2988","711.56","BUILDING","to the even, regular
platelets. regular, ironic epitaphs nag e") [42122-197] (state=42000,code=1001)
java.sql.SQLException: Failed to parse query. Column "1" not found; SQL
statement:
INSERT INTO customer VALUES ("1","Customer#1","IVhzIApeRb
ot,c,E","15","25-989-741-2988","711.56","BUILDING","to the even, regular
platelets. regular, ironic epitaphs nag e") [42122-197]
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:814)
at sqlline.Commands.sql(Commands.java:754)
at sqlline.SqlLine.dispatch(SqlLine.java:646)
at sqlline.SqlLine.runCommands(SqlLine.java:1681)
at sqlline.Commands.run(Commands.java:1393)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:643)
at sqlline.SqlLine.initArgs(SqlLine.java:427)
at sqlline.SqlLine.begin(SqlLine.java:485)
at sqlline.SqlLine.start(SqlLine.java:233)
at sqlline.SqlLine.main(SqlLine.java:175)
Aborting command set because "force" is false and command failed: "INSERT INTO
customer VALUES ("1","Customer#1","IVhzIApeRb
ot,c,E","15","25-989-741-2988","711.56","BUILDING","to the even, regular
platelets. regular, ironic epitaphs nag e");"
Closing: org.apache.ignite.internal.jdbc.thin.JdbcThinConnection
{noformat}
> SQL: Add ability to do INSERT without specifying the column names
> -
>
> Key: IGNITE-6111
> URL: https://issues.apache.org/jira/browse/IGNITE-6111
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: usability
> Fix For: 2.4
>
>
> Having the following classes
> {code:java}
> class PersonKey {
> private Long id;
> }
> class Person {
> private Long id;
> private String name;
> }
> {code}
> with proper configuration it should be possible to execute queries
> of the following type passing {{id}} and {{name}} as the arguments
> {code:sql}"insert into Person values(?,?)"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10158) Some tests in IgniteCacheAbstractQuerySelfTest are incorrectly muted
[
https://issues.apache.org/jira/browse/IGNITE-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681737#comment-16681737
]
Ignite TC Bot commented on IGNITE-10158:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2279715buildTypeId=IgniteTests24Java8_RunAll]
> Some tests in IgniteCacheAbstractQuerySelfTest are incorrectly muted
>
>
> Key: IGNITE-10158
> URL: https://issues.apache.org/jira/browse/IGNITE-10158
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Some tests in
> [IgniteCacheAbstractQuerySelfTest|https://github.com/apache/ignite/blob/master/modules/indexing/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCacheAbstractQuerySelfTest.java]
> are muted by renaming (prefixing with underscore, {{_test...}} and refer
> invalid JIRA URL in fail parameter
> ("http://atlassian.gridgain.com/jira/browse/GG-11216;).
> - _testDifferentKeyTypes
> this test should change expectation to opposite and after that recovered
> - _testObjectQueryWithSwap and _testTwoObjectsTextSearch
> Need to be properly muted and further investigated, per separate tickets.
> Per my preliminary checks tests fail because
> of wrong cache configuration, although there is also a chance that test
> design is wrong and these should be deleted.
> There is also a dead code there, a private class {{EmptyObject}} - it needs
> to be deleted. Code that was using this class was removed per
> [IGNITE-1232|https://issues.apache.org/jira/browse/IGNITE-1232] ([commit
> 79b8b08|https://github.com/gridgain/apache-ignite/commit/68891e89dd0e0f19321d6a4d45ae7372279b8b08#diff-a2f35b3aa70a70b98ce0cd6a1381d1f7])
> but this private class was forgotten.
> I also searched project code for other occurrences of mentioned troublesome
> fail parameter "GG-11216" and found yet another incorrectly muted test:
> {{IgniteCacheQueryMultiThreadedSelfTest#_testMultiThreadedSwapUnswapLongString}}
> This test should be recovered. It passed on my machine and per my comparison
> with similar test cases {{testMultiThreadedSwapUnswapLong}} and
> {{testMultiThreadedSwapUnswapString}} its design looks fairly reasonable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9843) IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta without losing data
[ https://issues.apache.org/jira/browse/IGNITE-9843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681706#comment-16681706 ] Ilya Kasnacheev commented on IGNITE-9843: - No blocking failures, ready to merge! [~sergey-chugunov] > IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta > without losing data > -- > > Key: IGNITE-9843 > URL: https://issues.apache.org/jira/browse/IGNITE-9843 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > >
[jira] [Commented] (IGNITE-9558) Avoid changing AffinityTopologyVersion on client connect when possible
[
https://issues.apache.org/jira/browse/IGNITE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681717#comment-16681717
]
Ignite TC Bot commented on IGNITE-9558:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2281326]]
* IgniteBasicTestSuite: IgniteFutureImplTest.testChainAsync - 0,0% fails in
last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2281320]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_KillRandom - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2281388buildTypeId=IgniteTests24Java8_RunAll]
> Avoid changing AffinityTopologyVersion on client connect when possible
> --
>
> Key: IGNITE-9558
> URL: https://issues.apache.org/jira/browse/IGNITE-9558
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.8
>
>
> Currently a client join event changes discovery topology version which, in
> turn, changes AffinityTopologyVersion.
> When a client maps transaction on new AffinityTopologyVersion, corresponding
> message is not processed on remote node until remote node receives the
> corresponding discovery event. If discovery event delivery is delayed for
> some reason, this will result in transaction stalls on client joins.
> Since the client node does not change partition affinity, we can safely map
> transactions on the previous topology version and do not change the affinity
> topology version at all.
> Some cases need special care and probably do not qualify for this
> optimization, such as when client has near cache or client hosts partition
> for REPLICATED cache.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9843) IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta without losing data
[
https://issues.apache.org/jira/browse/IGNITE-9843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681690#comment-16681690
]
Ignite TC Bot commented on IGNITE-9843:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 5{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2278991]]
* IgniteCacheTestSuite5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 -
0,0% fails in last 100 master runs.
* IgniteCacheWithIndexingTestSuite:
CacheTtlTransactionalPartitionedSelfTest.testTimeToLiveTtl - 0,0% fails in last
100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2203608buildTypeId=IgniteTests24Java8_RunAll]
> IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta
> without losing data
> --
>
> Key: IGNITE-9843
> URL: https://issues.apache.org/jira/browse/IGNITE-9843
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
>
[jira] [Commented] (IGNITE-10209) some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException at SandboxMLCache#fillCacheWith(MLSandboxDatasets)
[ https://issues.apache.org/jira/browse/IGNITE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681620#comment-16681620 ] ASF GitHub Bot commented on IGNITE-10209: - GitHub user oignatenko opened a pull request: https://github.com/apache/ignite/pull/5359 IGNITE-10209 some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10209 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5359.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 #5359 commit 1eeca908a8076a8317947dac8a46845964d1d7ea Author: Oleg Ignatenko Date: 2018-08-23T13:13:28Z IGNITE-9348 ML examples improvements - wip (logging improved) -- verified with diffs overview, executing the examples and studying execution logs commit e50b89c392568ba9b93935c4fa6c7f7f93f5ec6f Author: Oleg Ignatenko Date: 2018-08-23T14:45:57Z Revert "IGNITE-9348 ML examples improvements" This reverts commit 1eeca908a8076a8317947dac8a46845964d1d7ea. commit 474024b4c5bbdb3c0a4ed2f0a66238c8054c6674 Author: Oleg Ignatenko Date: 2018-08-23T14:57:34Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 9642b233b5701bdad47ebea163079160227c582a Author: Oleg Ignatenko Date: 2018-08-28T14:01:11Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 7fc16d013ab725d2ff2e1a1b042c983f11d0c4d4 Author: Oleg Ignatenko Date: 2018-08-28T15:13:02Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit d2caba67b156674f051f50faebeafe0871bf0914 Author: Oleg Ignatenko Date: 2018-08-29T13:14:07Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 16775dff51d71ea68b4a3dea98be552130c493ed Author: Oleg Ignatenko Date: 2018-08-30T09:00:56Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit aedb59929974fe205b949225c1a338c68c60cfc8 Author: Oleg Ignatenko Date: 2018-08-30T09:42:38Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 39c6482fcdca506aa33011ed21c98060b4a8c68b Author: Oleg Ignatenko Date: 2018-08-30T11:28:05Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 33b32a2760a6559c78283b927e3191180d8ed9e1 Author: Oleg Ignatenko Date: 2018-08-30T12:31:16Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 9531028ddd1aef9e95f7e8c8b528086739bbb1b0 Author: Oleg Ignatenko Date: 2018-08-30T14:06:34Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 28f22c6e2fffcb82717ba5da7be2cfd39715c4e3 Author: Oleg Ignatenko Date: 2018-08-30T16:41:51Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit aacac88db519187413b0fc5ff9d0e55b8f8cff22 Author: Oleg Ignatenko Date: 2018-08-31T10:12:32Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 897f920dde46022849b13f9fb86dba8e54119a56 Author: Oleg Ignatenko Date: 2018-08-31T13:57:14Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 114c79e54c1b316006ccc3ff22d20d902f9313df Author: Oleg Ignatenko Date: 2018-08-31T17:39:16Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit fd6b659bb8be1992618ce4ce91f568a0988b3afa Author: Oleg Ignatenko Date: 2018-09-02T06:11:42Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 6ae6d1d3cf9743d8d466be0330511ddc8589e944 Author: Oleg Ignatenko Date: 2018-09-03T10:27:35Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit e8b27dbd3d0c1cbdb7a7659175f5c7bb447482bf Author: Oleg Ignatenko Date: 2018-09-04T09:49:44Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 622c82efdd0aa182fadea6b7ffa5d4615521a3f5 Author: Oleg Ignatenko Date: 2018-09-05T10:50:28Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit fb844fe3751e2e8ae87e6b8030b0e4bd659df9c2 Author: Oleg Ignatenko Date: 2018-09-05T11:45:58Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 480ed78869277d7e32f725ab71bec9621f1ac03a Author: Oleg Ignatenko Date: 2018-09-06T07:52:55Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit c99762498f617c0e98ea3062a43c0b30092166ef Author: Oleg Ignatenko Date: 2018-09-06T14:45:04Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 2e17175225c72f747d370b5fee96f8be69d6d2cb Author:
[jira] [Comment Edited] (IGNITE-8386) SQL: Make sure PK index do not use wrapped object
[
https://issues.apache.org/jira/browse/IGNITE-8386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676419#comment-16676419
]
Yury Gerzhedovich edited comment on IGNITE-8386 at 11/9/18 3:36 PM:
[~vozerov],
# Merge with recent master and resolve conflicts.
# Added compatibility.
# Additional tests have been added including compatibility one.
Started new TS Run all suit -
https://ci.ignite.apache.org/viewLog.html?buildId=2280678
was (Author: jooger):
[~vozerov],
# Merge with recent master and resolve conflicts.
# Added compatibility.
# Additional tests have been added including compatibility one.
Started new TS Run all suit -
[https://ci.ignite.apache.org/viewQueued.html?itemId=2256556]
> SQL: Make sure PK index do not use wrapped object
> -
>
> Key: IGNITE-8386
> URL: https://issues.apache.org/jira/browse/IGNITE-8386
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-19, performance
> Fix For: 2.8
>
>
> Currently PK may be built over the whole {{_KEY}} column, i.e. the whole
> binary object. This could happen in two cases:
> 1) Composite PK
> 2) Plain PK but with {{WRAP_KEY}} option.
> This is critical performance issue for two reasons:
> 1) This index is effectively useless and cannot be used in any sensible
> queries; it just wastes space and makes updates slower
> 2) Binary object typically has common header bytes what may lead to excessive
> number of comparisons during index update.
> To mitigate the problem we need to ensure that index is *never* built over
> {{_KEY}}, Instead, we must always extract target columns and build normal
> index over them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10159) IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap fails non-null assertion at localPeek
[
https://issues.apache.org/jira/browse/IGNITE-10159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681582#comment-16681582
]
Ignite TC Bot commented on IGNITE-10159:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2278945buildTypeId=IgniteTests24Java8_RunAll]
> IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap fails non-null
> assertion at localPeek
> --
>
> Key: IGNITE-10159
> URL: https://issues.apache.org/jira/browse/IGNITE-10159
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap (in current codebase
> muted by renaming to {{_testObjectQueryWithSwap}}) fails with the following
> error:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertNotNull(Assert.java:256)
> at junit.framework.Assert.assertNotNull(Assert.java:248)
> at junit.framework.TestCase.assertNotNull(TestCase.java:417)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap(IgniteCacheAbstractQuerySelfTest.java:960)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ...{noformat}
> Code referred to above is:
> {code}assertNotNull(c.localPeek(i, CachePeekMode.ONHEAP));{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10085) Make compressed wal archives user friendly.
[
https://issues.apache.org/jira/browse/IGNITE-10085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681560#comment-16681560
]
Ignite TC Bot commented on IGNITE-10085:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2278478buildTypeId=IgniteTests24Java8_RunAll]
> Make compressed wal archives user friendly.
> ---
>
> Key: IGNITE-10085
> URL: https://issues.apache.org/jira/browse/IGNITE-10085
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Sergey Antonov
>Priority: Minor
>
> Compressed wal archives are created with ZipEntry(""). In some ZIP GUIs those
> archives are shown empty which can really confuse users.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9970) Add ability to set nodeId for VisorIdleVerifyDumpTask executed from ./control.sh --host HOST --cache idle_verify
[
https://issues.apache.org/jira/browse/IGNITE-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9970:
-
Ignite Flags: (was: Docs Required)
> Add ability to set nodeId for VisorIdleVerifyDumpTask executed from
> ./control.sh --host HOST --cache idle_verify
>
>
> Key: IGNITE-9970
> URL: https://issues.apache.org/jira/browse/IGNITE-9970
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.8
>
>
> --cache idle_verify sets null nodeId on invocation of
> private R executeTaskByNameOnNode(GridClient client, String taskClsName,
> Object taskArgs, UUID nodeId
> ) throws GridClientException {
>
> Which causes reduce phase to be assigned on random node, we want to dump
> results on particular node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9970) Add ability to set nodeId for VisorIdleVerifyDumpTask executed from ./control.sh --host HOST --cache idle_verify
[
https://issues.apache.org/jira/browse/IGNITE-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9970:
-
Fix Version/s: 2.8
> Add ability to set nodeId for VisorIdleVerifyDumpTask executed from
> ./control.sh --host HOST --cache idle_verify
>
>
> Key: IGNITE-9970
> URL: https://issues.apache.org/jira/browse/IGNITE-9970
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.8
>
>
> --cache idle_verify sets null nodeId on invocation of
> private R executeTaskByNameOnNode(GridClient client, String taskClsName,
> Object taskArgs, UUID nodeId
> ) throws GridClientException {
>
> Which causes reduce phase to be assigned on random node, we want to dump
> results on particular node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10188) Move tests with persistence to the convenient suite
[
https://issues.apache.org/jira/browse/IGNITE-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681549#comment-16681549
]
Eduard Shangareev commented on IGNITE-10188:
[~SomeFire], looks good.
[~agoncharuk], could you please help with merge?
> Move tests with persistence to the convenient suite
> ---
>
> Key: IGNITE-10188
> URL: https://issues.apache.org/jira/browse/IGNITE-10188
> Project: Ignite
> Issue Type: Test
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Major
>
> Tests with persistence from {{IgniteCachePartitionLossPolicySelfTest}} must
> be moved to another class and suite.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10209) some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException at SandboxMLCache#fillCacheWith(MLSandboxDatasets)
[
https://issues.apache.org/jira/browse/IGNITE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10209:
Description:
Tests for examples that use {{SandboxMLCache#fillCacheWith(MLSandboxDatasets)}}
fail with FNFE:
{noformat}
[ERROR] Tests run: 34, Failures: 0, Errors: 13, Skipped: 0, Time elapsed:
638.752 s <<< FAILURE! - in
org.apache.ignite.testsuites.IgniteExamplesMLTestSuite
[ERROR]
testExample(org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName)
Time elapsed: 21.701 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName.testExample(KMeansClusterizationExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.KNNClassificationExampleSelfName)
Time elapsed: 13.81 s <<< ERROR!
java.io.FileNotFoundException: examples\src\main\resources\datasets\iris.txt
(Системе не удается найти указанный путь)
at
org.apache.ignite.examples.ml.KNNClassificationExampleSelfName.testExample(KNNClassificationExampleSelfName.java)
[ERROR] testExample(org.apache.ignite.examples.ml.KNNRegressionExampleSelfName)
Time elapsed: 13.633 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\cleared_machines.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.KNNRegressionExampleSelfName.testExample(KNNRegressionExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName)
Time elapsed: 13.71 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName.testExample(LinearRegressionLSQRTrainerExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName)
Time elapsed: 13.728 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.testExample(LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName)
Time elapsed: 13.874 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName.testExample(LinearRegressionSGDTrainerExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName)
Time elapsed: 13.694 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName.testExample(LogisticRegressionSGDTrainerExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName)
Time elapsed: 13.823 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\glass_identification.csv (Системе не
удается найти указанный путь)
at
org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName.testExample(LogRegressionMultiClassClassificationExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName)
Time elapsed: 12.875 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName.testExample(TrainTestDatasetSplitterExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.SVMBinaryClassificationExampleSelfName)
Time elapsed: 12.795 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.SVMBinaryClassificationExampleSelfName.testExample(SVMBinaryClassificationExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.SVMMultiClassClassificationExampleSelfName)
Time elapsed: 12.948 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\glass_identification.csv (Системе не
удается найти указанный путь)
at
org.apache.ignite.examples.ml.SVMMultiClassClassificationExampleSelfName.testExample(SVMMultiClassClassificationExampleSelfName.java)
[ERROR]
[jira] [Created] (IGNITE-10210) SQL: jdbc thin connected to newly started client, misses "old" tables
Pavel Kuznetsov created IGNITE-10210:
Summary: SQL: jdbc thin connected to newly started client, misses
"old" tables
Key: IGNITE-10210
URL: https://issues.apache.org/jira/browse/IGNITE-10210
Project: Ignite
Issue Type: Bug
Components: jdbc, sql
Affects Versions: 2.6
Reporter: Pavel Kuznetsov
Given cluster.
We are creating table using thin driver.
After that we are starting new client node and connecting to it.
Metadata of this new connection doesn't contain information about this table.
Affected all methods that use
{{org.apache.ignite.internal.processors.query.GridQueryProcessor#types}} under
the hood.
Such as:
1) getPrimaryKeys()
2) getColumns()
3) getSchemas() (if no tables are created getSchemas() returns empty list.)
4) getTables()
5) getIndexes()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10209) some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException at SandboxMLCache#fillCacheWith(MLSandboxDatasets)
[
https://issues.apache.org/jira/browse/IGNITE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10209:
Ignite Flags: (was: Docs Required)
> some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException at
> SandboxMLCache#fillCacheWith(MLSandboxDatasets)
> --
>
> Key: IGNITE-10209
> URL: https://issues.apache.org/jira/browse/IGNITE-10209
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
>
> Tests for examples that use
> {{SandboxMLCache#fillCacheWith(MLSandboxDatasets)}} fail with FNFE:
> {noformat}
> [ERROR] Tests run: 34, Failures: 0, Errors: 13, Skipped: 0, Time elapsed:
> 638.752 s <<< FAILURE! - in
> org.apache.ignite.testsuites.IgniteExamplesMLTestSuite
> [ERROR]
> testExample(org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName)
> Time elapsed: 21.701 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName.testExample(KMeansClusterizationExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.KNNClassificationExampleSelfName)
> Time elapsed: 13.81 s <<< ERROR!
> java.io.FileNotFoundException: examples\src\main\resources\datasets\iris.txt
> (Системе не удается найти указанный путь)
> at
> org.apache.ignite.examples.ml.KNNClassificationExampleSelfName.testExample(KNNClassificationExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.KNNRegressionExampleSelfName) Time
> elapsed: 13.633 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\cleared_machines.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.KNNRegressionExampleSelfName.testExample(KNNRegressionExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName)
> Time elapsed: 13.71 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName.testExample(LinearRegressionLSQRTrainerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName)
> Time elapsed: 13.728 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.testExample(LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName)
> Time elapsed: 13.874 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName.testExample(LinearRegressionSGDTrainerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName)
> Time elapsed: 13.694 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName.testExample(LogisticRegressionSGDTrainerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName)
> Time elapsed: 13.823 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\glass_identification.csv (Системе не
> удается найти указанный путь)
> at
> org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName.testExample(LogRegressionMultiClassClassificationExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName)
> Time elapsed: 12.875 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName.testExample(TrainTestDatasetSplitterExampleSelfName.java)
> [ERROR]
>
[jira] [Updated] (IGNITE-10209) some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException at SandboxMLCache#fillCacheWith(MLSandboxDatasets)
[
https://issues.apache.org/jira/browse/IGNITE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10209:
Fix Version/s: 2.8
> some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException at
> SandboxMLCache#fillCacheWith(MLSandboxDatasets)
> --
>
> Key: IGNITE-10209
> URL: https://issues.apache.org/jira/browse/IGNITE-10209
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
>
> Tests for examples that use
> {{SandboxMLCache#fillCacheWith(MLSandboxDatasets)}} fail with FNFE:
> {noformat}
> [ERROR] Tests run: 34, Failures: 0, Errors: 13, Skipped: 0, Time elapsed:
> 638.752 s <<< FAILURE! - in
> org.apache.ignite.testsuites.IgniteExamplesMLTestSuite
> [ERROR]
> testExample(org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName)
> Time elapsed: 21.701 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName.testExample(KMeansClusterizationExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.KNNClassificationExampleSelfName)
> Time elapsed: 13.81 s <<< ERROR!
> java.io.FileNotFoundException: examples\src\main\resources\datasets\iris.txt
> (Системе не удается найти указанный путь)
> at
> org.apache.ignite.examples.ml.KNNClassificationExampleSelfName.testExample(KNNClassificationExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.KNNRegressionExampleSelfName) Time
> elapsed: 13.633 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\cleared_machines.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.KNNRegressionExampleSelfName.testExample(KNNRegressionExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName)
> Time elapsed: 13.71 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName.testExample(LinearRegressionLSQRTrainerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName)
> Time elapsed: 13.728 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.testExample(LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName)
> Time elapsed: 13.874 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName.testExample(LinearRegressionSGDTrainerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName)
> Time elapsed: 13.694 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName.testExample(LogisticRegressionSGDTrainerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName)
> Time elapsed: 13.823 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\glass_identification.csv (Системе не
> удается найти указанный путь)
> at
> org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName.testExample(LogRegressionMultiClassClassificationExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName)
> Time elapsed: 12.875 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName.testExample(TrainTestDatasetSplitterExampleSelfName.java)
> [ERROR]
>
[jira] [Assigned] (IGNITE-10209) some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException at SandboxMLCache#fillCacheWith(MLSandboxDatasets)
[
https://issues.apache.org/jira/browse/IGNITE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko reassigned IGNITE-10209:
---
Assignee: Oleg Ignatenko
> some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException at
> SandboxMLCache#fillCacheWith(MLSandboxDatasets)
> --
>
> Key: IGNITE-10209
> URL: https://issues.apache.org/jira/browse/IGNITE-10209
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
>
> Tests for examples that use
> {{SandboxMLCache#fillCacheWith(MLSandboxDatasets)}} fail with FNFE:
> {noformat}
> [ERROR] Tests run: 34, Failures: 0, Errors: 13, Skipped: 0, Time elapsed:
> 638.752 s <<< FAILURE! - in
> org.apache.ignite.testsuites.IgniteExamplesMLTestSuite
> [ERROR]
> testExample(org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName)
> Time elapsed: 21.701 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName.testExample(KMeansClusterizationExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.KNNClassificationExampleSelfName)
> Time elapsed: 13.81 s <<< ERROR!
> java.io.FileNotFoundException: examples\src\main\resources\datasets\iris.txt
> (Системе не удается найти указанный путь)
> at
> org.apache.ignite.examples.ml.KNNClassificationExampleSelfName.testExample(KNNClassificationExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.KNNRegressionExampleSelfName) Time
> elapsed: 13.633 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\cleared_machines.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.KNNRegressionExampleSelfName.testExample(KNNRegressionExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName)
> Time elapsed: 13.71 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName.testExample(LinearRegressionLSQRTrainerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName)
> Time elapsed: 13.728 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.testExample(LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName)
> Time elapsed: 13.874 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName.testExample(LinearRegressionSGDTrainerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName)
> Time elapsed: 13.694 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName.testExample(LogisticRegressionSGDTrainerExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName)
> Time elapsed: 13.823 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\glass_identification.csv (Системе не
> удается найти указанный путь)
> at
> org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName.testExample(LogRegressionMultiClassClassificationExampleSelfName.java)
> [ERROR]
> testExample(org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName)
> Time elapsed: 12.875 s <<< ERROR!
> java.io.FileNotFoundException:
> examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
> найти указанный путь)
> at
> org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName.testExample(TrainTestDatasetSplitterExampleSelfName.java)
> [ERROR]
>
[jira] [Created] (IGNITE-10209) some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException at SandboxMLCache#fillCacheWith(MLSandboxDatasets)
Oleg Ignatenko created IGNITE-10209:
---
Summary: some tests in IgniteExamplesMLTestSuite fail with
FileNotFoundException at SandboxMLCache#fillCacheWith(MLSandboxDatasets)
Key: IGNITE-10209
URL: https://issues.apache.org/jira/browse/IGNITE-10209
Project: Ignite
Issue Type: Bug
Components: ml
Affects Versions: 2.8
Reporter: Oleg Ignatenko
Tests for examples that use {{SandboxMLCache#fillCacheWith(MLSandboxDatasets)}}
fail with FNFE:
{noformat}
[ERROR] Tests run: 34, Failures: 0, Errors: 13, Skipped: 0, Time elapsed:
638.752 s <<< FAILURE! - in
org.apache.ignite.testsuites.IgniteExamplesMLTestSuite
[ERROR]
testExample(org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName)
Time elapsed: 21.701 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName.testExample(KMeansClusterizationExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.KNNClassificationExampleSelfName)
Time elapsed: 13.81 s <<< ERROR!
java.io.FileNotFoundException: examples\src\main\resources\datasets\iris.txt
(Системе не удается найти указанный путь)
at
org.apache.ignite.examples.ml.KNNClassificationExampleSelfName.testExample(KNNClassificationExampleSelfName.java)
[ERROR] testExample(org.apache.ignite.examples.ml.KNNRegressionExampleSelfName)
Time elapsed: 13.633 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\cleared_machines.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.KNNRegressionExampleSelfName.testExample(KNNRegressionExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName)
Time elapsed: 13.71 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName.testExample(LinearRegressionLSQRTrainerExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName)
Time elapsed: 13.728 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.testExample(LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName)
Time elapsed: 13.874 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName.testExample(LinearRegressionSGDTrainerExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName)
Time elapsed: 13.694 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName.testExample(LogisticRegressionSGDTrainerExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName)
Time elapsed: 13.823 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\glass_identification.csv (Системе не
удается найти указанный путь)
at
org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName.testExample(LogRegressionMultiClassClassificationExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName)
Time elapsed: 12.875 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName.testExample(TrainTestDatasetSplitterExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.SVMBinaryClassificationExampleSelfName)
Time elapsed: 12.795 s <<< ERROR!
java.io.FileNotFoundException:
examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается
найти указанный путь)
at
org.apache.ignite.examples.ml.SVMBinaryClassificationExampleSelfName.testExample(SVMBinaryClassificationExampleSelfName.java)
[ERROR]
testExample(org.apache.ignite.examples.ml.SVMMultiClassClassificationExampleSelfName)
Time elapsed: 12.948 s <<< ERROR!
java.io.FileNotFoundException:
[jira] [Updated] (IGNITE-10072) Install-Package Apache.Ignite disables existing conditional post-build events
[ https://issues.apache.org/jira/browse/IGNITE-10072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-10072: -- Description: Setup: # A *.csproj file targeting .NET Framework with any one ore more conditional post-build events specified opened in Visual Studio Steps to reproduce: # In Visual Studio -> Package Manager Console run "Install-Package Apache.Ignite" # Open the csproj file in a test editor and check the post-build events Expected: # Package Apache.Ignite installed OK # The command to copy Ignite libs from the NuGet package into target directory is appended to all the existing post-build events Actual: # As expected # A new unconditional post-build event to copy Ignite libs from the NuGet package into target directory is created and added after all the initial post-build events. This effectively disables all the initial post-build events since MSBuild executes only the last post-build event. was: Setup: # A *.csproj file targeting .NET Framework with any one ore more conditional post-build actions specified opened in Visual Studio Steps to reproduce: # In Visual Studio -> Package Manager Console run "Install-Package Apache.Ignite" # Open the csproj file in a test editor and check the post-build actions Expected: # Package Apache.Ignite installed OK # The initial post-build actions Actual: # As expected # The initial post-build actions are gone > Install-Package Apache.Ignite disables existing conditional post-build events > - > > Key: IGNITE-10072 > URL: https://issues.apache.org/jira/browse/IGNITE-10072 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > Setup: > # A *.csproj file targeting .NET Framework with any one ore more conditional > post-build events specified opened in Visual Studio > Steps to reproduce: > # In Visual Studio -> Package Manager Console run "Install-Package > Apache.Ignite" > # Open the csproj file in a test editor and check the post-build events > Expected: > # Package Apache.Ignite installed OK > # The command to copy Ignite libs from the NuGet package into target > directory is appended to all the existing post-build events > Actual: > # As expected > # A new unconditional post-build event to copy Ignite libs from the NuGet > package into target directory is created and added after all the initial > post-build events. This effectively disables all the initial post-build > events since MSBuild executes only the last post-build event. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10072) Install-Package Apache.Ignite disables existing conditional post-build actions
[ https://issues.apache.org/jira/browse/IGNITE-10072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-10072: -- Description: Setup: # A *.csproj file targeting .NET Framework with any one ore more conditional post-build actions specified opened in Visual Studio Steps to reproduce: # In Visual Studio -> Package Manager Console run "Install-Package Apache.Ignite" # Open the csproj file in a test editor and check the post-build actions Expected: # Package Apache.Ignite installed OK # The initial post-build actions Actual: # As expected # The initial post-build actions are gone was: Setup: # A *.csproj file targeting .NET Framework with any one ore more conditional post-build actions specified opened in Visual Studio Steps to reproduce: # In Visual Studio -> Package Manager Console run "Install-Package Apache.Ignite" # Open the csproj file in a test editor and check the post-build actions Expected: # Package Apache.Ignite installed OK # The initial post-build actions are still in the csproj file Actual: # As expected # The initial post-build actions are gone > Install-Package Apache.Ignite disables existing conditional post-build actions > -- > > Key: IGNITE-10072 > URL: https://issues.apache.org/jira/browse/IGNITE-10072 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > Setup: > # A *.csproj file targeting .NET Framework with any one ore more conditional > post-build actions specified opened in Visual Studio > Steps to reproduce: > # In Visual Studio -> Package Manager Console run "Install-Package > Apache.Ignite" > # Open the csproj file in a test editor and check the post-build actions > Expected: > # Package Apache.Ignite installed OK > # The initial post-build actions > Actual: > # As expected > # The initial post-build actions are gone -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10072) Install-Package Apache.Ignite disables existing conditional post-build events
[ https://issues.apache.org/jira/browse/IGNITE-10072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-10072: -- Summary: Install-Package Apache.Ignite disables existing conditional post-build events (was: Install-Package Apache.Ignite disables existing conditional post-build actions) > Install-Package Apache.Ignite disables existing conditional post-build events > - > > Key: IGNITE-10072 > URL: https://issues.apache.org/jira/browse/IGNITE-10072 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > Setup: > # A *.csproj file targeting .NET Framework with any one ore more conditional > post-build actions specified opened in Visual Studio > Steps to reproduce: > # In Visual Studio -> Package Manager Console run "Install-Package > Apache.Ignite" > # Open the csproj file in a test editor and check the post-build actions > Expected: > # Package Apache.Ignite installed OK > # The initial post-build actions > Actual: > # As expected > # The initial post-build actions are gone -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8871) TDE - Phase-1. Documentation
[ https://issues.apache.org/jira/browse/IGNITE-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-8871: -- Assignee: Nikolay Izhikov (was: Artem Budnikov) > TDE - Phase-1. Documentation > > > Key: IGNITE-8871 > URL: https://issues.apache.org/jira/browse/IGNITE-8871 > Project: Ignite > Issue Type: Sub-task > Components: documentation >Affects Versions: 2.5 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: documentation > Fix For: 2.7 > > > TDE feature should be documented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10072) Install-Package Apache.Ignite disables existing conditional post-build actions
[ https://issues.apache.org/jira/browse/IGNITE-10072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-10072: -- Description: Setup: # A *.csproj file targeting .NET Framework with any one ore more conditional post-build actions specified opened in Visual Studio Steps to reproduce: # In Visual Studio -> Package Manager Console run "Install-Package Apache.Ignite" # Open the csproj file in a test editor and check the post-build actions Expected: # Package Apache.Ignite installed OK # The initial post-build actions are still in the csproj file Actual: # As expected # The initial post-build actions are gone was: Setup: # A *.csproj file with any one ore more conditional post-build actions specified opened in Visual Studio Steps to reproduce: # In Visual Studio -> Package Manager Console run "Install-Package Apache.Ignite" # Open the csproj file in a test editor and check the post-build actions Expected: # Package Apache.Ignite installed OK # The initial post-build actions are still in the csproj file Actual: # As expected # The initial post-build actions are gone > Install-Package Apache.Ignite disables existing conditional post-build actions > -- > > Key: IGNITE-10072 > URL: https://issues.apache.org/jira/browse/IGNITE-10072 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > Setup: > # A *.csproj file targeting .NET Framework with any one ore more conditional > post-build actions specified opened in Visual Studio > Steps to reproduce: > # In Visual Studio -> Package Manager Console run "Install-Package > Apache.Ignite" > # Open the csproj file in a test editor and check the post-build actions > Expected: > # Package Apache.Ignite installed OK > # The initial post-build actions are still in the csproj file > Actual: > # As expected > # The initial post-build actions are gone -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10072) Install-Package Apache.Ignite disables existing conditional post-build actions
[ https://issues.apache.org/jira/browse/IGNITE-10072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-10072: -- Summary: Install-Package Apache.Ignite disables existing conditional post-build actions (was: Apache.Ignite NuGet package disables existing conditional post-build actions) > Install-Package Apache.Ignite disables existing conditional post-build actions > -- > > Key: IGNITE-10072 > URL: https://issues.apache.org/jira/browse/IGNITE-10072 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > Setup: > # A *.csproj file with any one ore more conditional post-build actions > specified opened in Visual Studio > Steps to reproduce: > # In Visual Studio -> Package Manager Console run "Install-Package > Apache.Ignite" > # Open the csproj file in a test editor and check the post-build actions > Expected: > # Package Apache.Ignite installed OK > # The initial post-build actions are still in the csproj file > Actual: > # As expected > # The initial post-build actions are gone -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10168) SQL security monitoring
[ https://issues.apache.org/jira/browse/IGNITE-10168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-10168: --- Labels: (was: iep-29) > SQL security monitoring > --- > > Key: IGNITE-10168 > URL: https://issues.apache.org/jira/browse/IGNITE-10168 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > > Security monitoring: For each query we should track who started query: > subject id, application name/module/label -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-10168) SQL security monitoring
[ https://issues.apache.org/jira/browse/IGNITE-10168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich closed IGNITE-10168. -- > SQL security monitoring > --- > > Key: IGNITE-10168 > URL: https://issues.apache.org/jira/browse/IGNITE-10168 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > > Security monitoring: For each query we should track who started query: > subject id, application name/module/label -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10208) Verify list of tests after migration to Junit 4 against some prior reference (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10208:
Labels: MakeTeamcityGreenAgain (was: )
> Verify list of tests after migration to Junit 4 against some prior reference
> (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10208
> URL: https://issues.apache.org/jira/browse/IGNITE-10208
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Migration from Junit 3 to 4 involves manually adding {{@Test}} annotation to
> existing test cases. Since Ignite contains many thousands test cases there is
> a substantial risk that we may miss some of these in such a transition.
> In order to mitigate the risk, suggest to do a check after completion of
> IGNITE-10177 - somehow generate list of tests in the project and compare it
> against similar list of tests of some "known good" prior project version (at
> this point, 2.7 release branch looks like a good candidate for such a
> reference).
> If comparison shows that some test cases from older version are missed in
> newer one, open a ticket to investigate that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10208) Verify list of tests after migration to Junit 4 against some prior reference (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10208:
Ignite Flags: (was: Docs Required)
> Verify list of tests after migration to Junit 4 against some prior reference
> (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10208
> URL: https://issues.apache.org/jira/browse/IGNITE-10208
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Priority: Major
>
> Migration from Junit 3 to 4 involves manually adding {{@Test}} annotation to
> existing test cases. Since Ignite contains many thousands test cases there is
> a substantial risk that we may miss some of these in such a transition.
> In order to mitigate the risk, suggest to do a check after completion of
> IGNITE-10177 - somehow generate list of tests in the project and compare it
> against similar list of tests of some "known good" prior project version (at
> this point, 2.7 release branch looks like a good candidate for such a
> reference).
> If comparison shows that some test cases from older version are missed in
> newer one, open a ticket to investigate that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10208) Verify list of tests after migration to Junit 4 against some prior reference (follow-up to IGNITE-10177)
Oleg Ignatenko created IGNITE-10208:
---
Summary: Verify list of tests after migration to Junit 4 against
some prior reference (follow-up to IGNITE-10177)
Key: IGNITE-10208
URL: https://issues.apache.org/jira/browse/IGNITE-10208
Project: Ignite
Issue Type: Sub-task
Reporter: Oleg Ignatenko
Migration from Junit 3 to 4 involves manually adding {{@Test}} annotation to
existing test cases. Since Ignite contains many thousands test cases there is a
substantial risk that we may miss some of these in such a transition.
In order to mitigate the risk, suggest to do a check after completion of
IGNITE-10177 - somehow generate list of tests in the project and compare it
against similar list of tests of some "known good" prior project version (at
this point, 2.7 release branch looks like a good candidate for such a
reference).
If comparison shows that some test cases from older version are missed in newer
one, open a ticket to investigate that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-10168) SQL security monitoring
[ https://issues.apache.org/jira/browse/IGNITE-10168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich resolved IGNITE-10168. Resolution: Won't Fix > SQL security monitoring > --- > > Key: IGNITE-10168 > URL: https://issues.apache.org/jira/browse/IGNITE-10168 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > > Security monitoring: For each query we should track who started query: > subject id, application name/module/label -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6145) JDBC thin: support connection pooling
[
https://issues.apache.org/jira/browse/IGNITE-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681461#comment-16681461
]
Taras Ledkov commented on IGNITE-6145:
--
[~kcheng.mvp] Now the JDBC interfaces {{PooledConnection,
ConnectionPooledDataSource, ConnectionEventListener}} are not implemented by
Ignite thin JDBC driver. But you can try to use an external pooling provider,
e.g. DBCP or c3p0.
> JDBC thin: support connection pooling
> -
>
> Key: IGNITE-6145
> URL: https://issues.apache.org/jira/browse/IGNITE-6145
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Priority: Major
>
> W have to support connection pool to JDBC compliance.
> At the very least we must test ourselves with well-known pooling providers
> (DBCP, c3p0).
> This is blocked by IGNITE-6140
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10207) Missed loss policy checks
[ https://issues.apache.org/jira/browse/IGNITE-10207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-10207: Description: In some cases (client reconnect, new client join, etc) PartitionLossPolicy may incorrectly validate operation. Return null for READ_ONLY_SAFE for loss partition. To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times) with random node stop. was: In some cases (client reconnect, new client join, etc) PartitionLossPolicy may incorrectly validate operation. Return null for READ_ONLY_SAFE for loss partition. To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times ) with random node stop. > Missed loss policy checks > - > > Key: IGNITE-10207 > URL: https://issues.apache.org/jira/browse/IGNITE-10207 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > > In some cases (client reconnect, new client join, etc) PartitionLossPolicy > may incorrectly validate operation. Return null for READ_ONLY_SAFE for loss > partition. > To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times) with > random node stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9858) [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
[
https://issues.apache.org/jira/browse/IGNITE-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681408#comment-16681408
]
Pavel Pereslegin commented on IGNITE-9858:
--
[~DmitriyGovorukhin], I found that
TcpClientDiscoverySpiMulticastTest.testJoinWithMulticast hangs with the fix you
suggested.
> [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
>
>
> Key: IGNITE-9858
> URL: https://issues.apache.org/jira/browse/IGNITE-9858
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> SystemCacheNotConfiguredTest hangs sometimes on TeamCity (timeout).
> Example of such failures on master branch:
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-2762467041583095183=TEST_STATUS_DESC=50_IgniteTests24Java8=%3Cdefault%3E]
> When we using ip finder in shared mode each node should register self address
> (except clients, obviously).
> Check that the node is a client uses installed (via DI
> @IgniteInstanceResource) Ignite instance (see
> {{TcpDiscoveryIpFinderAdapter#initializeLocalAddresses}}).
> So when client and server starts simultaneously, the following scenario is
> possible - Ignite server injected at first, then the Ignite client injected
> when the SPI is initialized ({{spiStart}}) both nodes assume that the local
> node is a client and don't register local address.
> {noformat}
> [2018-10-11 18:03:49,794][WARN
> ][tcp-client-disco-msg-worker-#57%client%][TcpDiscoverySpi] IP finder
> returned empty addresses list. Please check IP finder configuration. Will
> retry every 2000 ms. Change 'reconnectDelay' to configure the frequency of
> retries.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9886) Split Continuous Query 1 onto several configs
[
https://issues.apache.org/jira/browse/IGNITE-9886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681402#comment-16681402
]
Roman Kondakov commented on IGNITE-9886:
The same name is used for all suites:
{code:java}
TestSuite suite = new TestSuite("Ignite Cache Queries Test Suite 3");
{code}
IMO names should be unique for each suite.
> Split Continuous Query 1 onto several configs
> -
>
> Key: IGNITE-9886
> URL: https://issues.apache.org/jira/browse/IGNITE-9886
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> At the current state this config require a lot of time for one test-run
> (>100min). We need to split this onto several configs with running time <=
> 60min.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10207) Missed loss policy checks
[ https://issues.apache.org/jira/browse/IGNITE-10207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-10207: --- Assignee: Dmitriy Govorukhin > Missed loss policy checks > - > > Key: IGNITE-10207 > URL: https://issues.apache.org/jira/browse/IGNITE-10207 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > > In some cases (client reconnect, new client join, etc) PartitionLossPolicy > may incorrectly validate operation. Return null for READ_ONLY_SAFE for loss > partition. > To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times > ) with random node stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10207) Missed loss policy checks
[ https://issues.apache.org/jira/browse/IGNITE-10207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-10207: Component/s: cache > Missed loss policy checks > - > > Key: IGNITE-10207 > URL: https://issues.apache.org/jira/browse/IGNITE-10207 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > > In some cases (client reconnect, new client join, etc) PartitionLossPolicy > may incorrectly validate operation. Return null for READ_ONLY_SAFE for loss > partition. > To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times > ) with random node stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10206) Allow specifying query parallelism in CREATE TABLE's WITH "" clause
Ilya Kasnacheev created IGNITE-10206:
Summary: Allow specifying query parallelism in CREATE TABLE's WITH
"" clause
Key: IGNITE-10206
URL: https://issues.apache.org/jira/browse/IGNITE-10206
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 2.6
Reporter: Ilya Kasnacheev
As in
{code}
CREATE TABLE foo (id long primary key, val varchar) WITH "backups=1,
query_parallelism=4";
{code}
Currently it is possible to specify e.g. backups but not query_parallelism.
This leads to necessity to specify cache template for such tables, which is
cumbersome.
Moreover, people may ignore this option outright and get worse performance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10207) Missed loss policy checks
Dmitriy Govorukhin created IGNITE-10207: --- Summary: Missed loss policy checks Key: IGNITE-10207 URL: https://issues.apache.org/jira/browse/IGNITE-10207 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin In some cases (client reconnect, new client join, etc) PartitionLossPolicy may incorrectly validate operation. Return null for READ_ONLY_SAFE for loss partition. To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times ) with random node stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10207) Missed loss policy checks
[ https://issues.apache.org/jira/browse/IGNITE-10207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-10207: Fix Version/s: 2.8 > Missed loss policy checks > - > > Key: IGNITE-10207 > URL: https://issues.apache.org/jira/browse/IGNITE-10207 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > > In some cases (client reconnect, new client join, etc) PartitionLossPolicy > may incorrectly validate operation. Return null for READ_ONLY_SAFE for loss > partition. > To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times > ) with random node stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10072) Apache.Ignite NuGet package disables existing conditional post-build actions
[ https://issues.apache.org/jira/browse/IGNITE-10072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-10072: -- Description: Setup: # A *.csproj file with any one ore more conditional post-build actions specified opened in Visual Studio Steps to reproduce: # In Visual Studio -> Package Manager Console run "Install-Package Apache.Ignite" # Open the csproj file in a test editor and check the post-build actions Expected: # Package Apache.Ignite installed OK # The initial post-build actions are still in the csproj file Actual: # As expected # The initial post-build actions are gone was: Setup: # A *.csproj file with any one ore more post-build actions specified opened in Visual Studio Steps to reproduce: # In Visual Studio -> Package Manager Console run "Install-Package Apache.Ignite" # Open the csproj file in a test editor and check the post-build actions Expected: # Package Apache.Ignite installed OK # The initial post-build actions are still in the csproj file Actual: # As expected # The initial post-build actions are gone > Apache.Ignite NuGet package disables existing conditional post-build actions > > > Key: IGNITE-10072 > URL: https://issues.apache.org/jira/browse/IGNITE-10072 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > Setup: > # A *.csproj file with any one ore more conditional post-build actions > specified opened in Visual Studio > Steps to reproduce: > # In Visual Studio -> Package Manager Console run "Install-Package > Apache.Ignite" > # Open the csproj file in a test editor and check the post-build actions > Expected: > # Package Apache.Ignite installed OK > # The initial post-build actions are still in the csproj file > Actual: > # As expected > # The initial post-build actions are gone -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9858) [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
[
https://issues.apache.org/jira/browse/IGNITE-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681394#comment-16681394
]
Pavel Pereslegin edited comment on IGNITE-9858 at 11/9/18 12:48 PM:
[~DmitriyGovorukhin], thank you for the review. Unfortunately suggested fix
affects {{TcpDiscoveryMulticastIpFinder#initializeLocalAddresses}}, as I can
see we collecting interfaces to send requests even for client discovery. I can
investigate deeper effects of such change for multicast ip finder.
was (Author: xtern):
[~DmitriyGovorukhin], thank you for the review. Unfortunately suggested fix
affects {{TcpDiscoveryMulticastIpFinder#initializeLocalAddresses}}, as I can
see we collecting interfaces to send requests even for client discovery. I can
investigate deeper effects of such change.
> [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
>
>
> Key: IGNITE-9858
> URL: https://issues.apache.org/jira/browse/IGNITE-9858
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> SystemCacheNotConfiguredTest hangs sometimes on TeamCity (timeout).
> Example of such failures on master branch:
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-2762467041583095183=TEST_STATUS_DESC=50_IgniteTests24Java8=%3Cdefault%3E]
> When we using ip finder in shared mode each node should register self address
> (except clients, obviously).
> Check that the node is a client uses installed (via DI
> @IgniteInstanceResource) Ignite instance (see
> {{TcpDiscoveryIpFinderAdapter#initializeLocalAddresses}}).
> So when client and server starts simultaneously, the following scenario is
> possible - Ignite server injected at first, then the Ignite client injected
> when the SPI is initialized ({{spiStart}}) both nodes assume that the local
> node is a client and don't register local address.
> {noformat}
> [2018-10-11 18:03:49,794][WARN
> ][tcp-client-disco-msg-worker-#57%client%][TcpDiscoverySpi] IP finder
> returned empty addresses list. Please check IP finder configuration. Will
> retry every 2000 ms. Change 'reconnectDelay' to configure the frequency of
> retries.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9858) [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
[
https://issues.apache.org/jira/browse/IGNITE-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681394#comment-16681394
]
Pavel Pereslegin edited comment on IGNITE-9858 at 11/9/18 12:48 PM:
[~DmitriyGovorukhin], thank you for the review. Unfortunately suggested fix
affects {{TcpDiscoveryMulticastIpFinder#initializeLocalAddresses}}, as I can
see we collecting interfaces to send requests even for client discovery. I can
investigate deeper effects of such change.
was (Author: xtern):
[~DmitriyGovorukhin], thank you for the review. Unfortunately suggested fix
affects {{TcpDiscoveryMulticastIpFinder#initializeLocalAddresses}}, as I can
see we collecting interfaces to send request even for client discovery. I can
investigate deeper effects of this change.
> [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
>
>
> Key: IGNITE-9858
> URL: https://issues.apache.org/jira/browse/IGNITE-9858
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> SystemCacheNotConfiguredTest hangs sometimes on TeamCity (timeout).
> Example of such failures on master branch:
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-2762467041583095183=TEST_STATUS_DESC=50_IgniteTests24Java8=%3Cdefault%3E]
> When we using ip finder in shared mode each node should register self address
> (except clients, obviously).
> Check that the node is a client uses installed (via DI
> @IgniteInstanceResource) Ignite instance (see
> {{TcpDiscoveryIpFinderAdapter#initializeLocalAddresses}}).
> So when client and server starts simultaneously, the following scenario is
> possible - Ignite server injected at first, then the Ignite client injected
> when the SPI is initialized ({{spiStart}}) both nodes assume that the local
> node is a client and don't register local address.
> {noformat}
> [2018-10-11 18:03:49,794][WARN
> ][tcp-client-disco-msg-worker-#57%client%][TcpDiscoverySpi] IP finder
> returned empty addresses list. Please check IP finder configuration. Will
> retry every 2000 ms. Change 'reconnectDelay' to configure the frequency of
> retries.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10073) Ignite NuGet package without embedded Ignite JARs
[ https://issues.apache.org/jira/browse/IGNITE-10073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681396#comment-16681396 ] Alexey Kukushkin commented on IGNITE-10073: --- +*SOLUTION*+ Create a separate Apache.Ignite.Core-NoRuntime.nuspec similar to Apache.Ignite.Core.nuspec but not including the Ignite runtime. The new NuGet package will have same version and different id "Apache.Ignite-NoRuntime" > Ignite NuGet package without embedded Ignite JARs > - > > Key: IGNITE-10073 > URL: https://issues.apache.org/jira/browse/IGNITE-10073 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > The existing Apache.Ignite NuGet package includes Ignite JARs deployed into > the "libs" directory in the .NET project output directory upon the package > installation. > We prefer using external Ignite JARs from $IGNITE_HOME/libs instead of the > JARs in the local libs directory. > Right now we have to manually remove local "libs" directory after every > Apache.Ignite package installation or upgrade. > It would help us having another Ignite NuGet package without the embedded > Ignite JARs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9858) [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
[
https://issues.apache.org/jira/browse/IGNITE-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681394#comment-16681394
]
Pavel Pereslegin commented on IGNITE-9858:
--
[~DmitriyGovorukhin], thank you for the review. Unfortunately suggested fix
affects {{TcpDiscoveryMulticastIpFinder#initializeLocalAddresses}}, as I can
see we collecting interfaces to send request even for client discovery. I can
investigate deeper effects of this change.
> [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
>
>
> Key: IGNITE-9858
> URL: https://issues.apache.org/jira/browse/IGNITE-9858
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> SystemCacheNotConfiguredTest hangs sometimes on TeamCity (timeout).
> Example of such failures on master branch:
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-2762467041583095183=TEST_STATUS_DESC=50_IgniteTests24Java8=%3Cdefault%3E]
> When we using ip finder in shared mode each node should register self address
> (except clients, obviously).
> Check that the node is a client uses installed (via DI
> @IgniteInstanceResource) Ignite instance (see
> {{TcpDiscoveryIpFinderAdapter#initializeLocalAddresses}}).
> So when client and server starts simultaneously, the following scenario is
> possible - Ignite server injected at first, then the Ignite client injected
> when the SPI is initialized ({{spiStart}}) both nodes assume that the local
> node is a client and don't register local address.
> {noformat}
> [2018-10-11 18:03:49,794][WARN
> ][tcp-client-disco-msg-worker-#57%client%][TcpDiscoverySpi] IP finder
> returned empty addresses list. Please check IP finder configuration. Will
> retry every 2000 ms. Change 'reconnectDelay' to configure the frequency of
> retries.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9930) Split Zookeeper Discovery 2 onto several configs
[ https://issues.apache.org/jira/browse/IGNITE-9930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9930: - Ignite Flags: (was: Docs Required) > Split Zookeeper Discovery 2 onto several configs > > > Key: IGNITE-9930 > URL: https://issues.apache.org/jira/browse/IGNITE-9930 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > At the current state this config require a lot of time for one test-run > (>100min). We need to split this onto several configs with running time <= > 60min. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9886) Split Continuous Query 1 onto several configs
[ https://issues.apache.org/jira/browse/IGNITE-9886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9886: - Ignite Flags: (was: Docs Required) > Split Continuous Query 1 onto several configs > - > > Key: IGNITE-9886 > URL: https://issues.apache.org/jira/browse/IGNITE-9886 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > At the current state this config require a lot of time for one test-run > (>100min). We need to split this onto several configs with running time <= > 60min. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9930) Split Zookeeper Discovery 2 onto several configs
[ https://issues.apache.org/jira/browse/IGNITE-9930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681392#comment-16681392 ] ASF GitHub Bot commented on IGNITE-9930: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5021 > Split Zookeeper Discovery 2 onto several configs > > > Key: IGNITE-9930 > URL: https://issues.apache.org/jira/browse/IGNITE-9930 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > At the current state this config require a lot of time for one test-run > (>100min). We need to split this onto several configs with running time <= > 60min. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10072) Apache.Ignite NuGet package disables existing conditional post-build actions
[ https://issues.apache.org/jira/browse/IGNITE-10072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-10072: -- Summary: Apache.Ignite NuGet package disables existing conditional post-build actions (was: Apache.Ignite NuGet package removes existing post-build actions) > Apache.Ignite NuGet package disables existing conditional post-build actions > > > Key: IGNITE-10072 > URL: https://issues.apache.org/jira/browse/IGNITE-10072 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > Setup: > # A *.csproj file with any one ore more post-build actions specified opened > in Visual Studio > Steps to reproduce: > # In Visual Studio -> Package Manager Console run "Install-Package > Apache.Ignite" > # Open the csproj file in a test editor and check the post-build actions > Expected: > # Package Apache.Ignite installed OK > # The initial post-build actions are still in the csproj file > Actual: > # As expected > # The initial post-build actions are gone -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9930) Split Zookeeper Discovery 2 onto several configs
[ https://issues.apache.org/jira/browse/IGNITE-9930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9930: - Fix Version/s: 2.8 > Split Zookeeper Discovery 2 onto several configs > > > Key: IGNITE-9930 > URL: https://issues.apache.org/jira/browse/IGNITE-9930 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > At the current state this config require a lot of time for one test-run > (>100min). We need to split this onto several configs with running time <= > 60min. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9909) Merge FsyncWalManager and WalManager
[ https://issues.apache.org/jira/browse/IGNITE-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681377#comment-16681377 ] Dmitriy Govorukhin commented on IGNITE-9909: [~akalashnikov] Merged to master. > Merge FsyncWalManager and WalManager > > > Key: IGNITE-9909 > URL: https://issues.apache.org/jira/browse/IGNITE-9909 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > Now we have two similar WAL managers FileWriteAheadLogManager and > FsyncModeFileWriteAheadLogManager and because of similarity it is too > difficult to support them. It is need to extract unique part from them and > leave only one manager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9858) [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
[
https://issues.apache.org/jira/browse/IGNITE-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681386#comment-16681386
]
Dmitriy Govorukhin commented on IGNITE-9858:
[~xtern] I reviewed your changes and I guess we can do code better, If I
understand correctly, the main problem is in shared mode for IP finder we can
get a race between injection and registration address? If it true, we can do
not call spi.ipFinder.initializeLocalAddresses for client.
What about my fix example? Sure, we should remove isClient check inside
TcpDiscoveryIpFinderAdapter too.
{code}
boolean clientDiscovery = locNode.isClient() && !spi.isForceServerMode();
while (true) {
try {
if (!clientDiscovery){
spi.ipFinder.initializeLocalAddresses(
U.resolveAddresses(spi.getAddressResolver(),
locNode.socketAddresses()));
}
// Success.
break;
}
{code}
> [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
>
>
> Key: IGNITE-9858
> URL: https://issues.apache.org/jira/browse/IGNITE-9858
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> SystemCacheNotConfiguredTest hangs sometimes on TeamCity (timeout).
> Example of such failures on master branch:
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-2762467041583095183=TEST_STATUS_DESC=50_IgniteTests24Java8=%3Cdefault%3E]
> When we using ip finder in shared mode each node should register self address
> (except clients, obviously).
> Check that the node is a client uses installed (via DI
> @IgniteInstanceResource) Ignite instance (see
> {{TcpDiscoveryIpFinderAdapter#initializeLocalAddresses}}).
> So when client and server starts simultaneously, the following scenario is
> possible - Ignite server injected at first, then the Ignite client injected
> when the SPI is initialized ({{spiStart}}) both nodes assume that the local
> node is a client and don't register local address.
> {noformat}
> [2018-10-11 18:03:49,794][WARN
> ][tcp-client-disco-msg-worker-#57%client%][TcpDiscoverySpi] IP finder
> returned empty addresses list. Please check IP finder configuration. Will
> retry every 2000 ms. Change 'reconnectDelay' to configure the frequency of
> retries.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10073) Ignite NuGet package without embedded Ignite JARs
[ https://issues.apache.org/jira/browse/IGNITE-10073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681378#comment-16681378 ] ASF GitHub Bot commented on IGNITE-10073: - GitHub user kukushal opened a pull request: https://github.com/apache/ignite/pull/5358 IGNITE-10073 Ignite NuGet package without embedded Ignite JARs You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10073 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5358.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 #5358 commit a9897350f415567caab29ef7514d74b2a5cd8e92 Author: Alexey Kukushkin Date: 2018-11-05T23:18:22Z IGNITE-10073 Ignite NuGet package without embedded Ignite JARs > Ignite NuGet package without embedded Ignite JARs > - > > Key: IGNITE-10073 > URL: https://issues.apache.org/jira/browse/IGNITE-10073 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > The existing Apache.Ignite NuGet package includes Ignite JARs deployed into > the "libs" directory in the .NET project output directory upon the package > installation. > We prefer using external Ignite JARs from $IGNITE_HOME/libs instead of the > JARs in the local libs directory. > Right now we have to manually remove local "libs" directory after every > Apache.Ignite package installation or upgrade. > It would help us having another Ignite NuGet package without the embedded > Ignite JARs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9909) Merge FsyncWalManager and WalManager
[ https://issues.apache.org/jira/browse/IGNITE-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9909: --- Component/s: persistence > Merge FsyncWalManager and WalManager > > > Key: IGNITE-9909 > URL: https://issues.apache.org/jira/browse/IGNITE-9909 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > Now we have two similar WAL managers FileWriteAheadLogManager and > FsyncModeFileWriteAheadLogManager and because of similarity it is too > difficult to support them. It is need to extract unique part from them and > leave only one manager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9870) GridDhtPartitionsFullMessage#prepareMarshal compression parallelization.
[ https://issues.apache.org/jira/browse/IGNITE-9870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681376#comment-16681376 ] ASF GitHub Bot commented on IGNITE-9870: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5330 > GridDhtPartitionsFullMessage#prepareMarshal compression parallelization. > > > Key: IGNITE-9870 > URL: https://issues.apache.org/jira/browse/IGNITE-9870 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.6 >Reporter: Stanilovsky Evgeny >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > > In huge topologies ~ 200 cluster nodes , 100 caches , 32k partitions per > cache, full map generation takes about 3 sec, seems correct approach here in > parallelization. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10173) Gradually move unit tests from Junit 3 to newer version
[
https://issues.apache.org/jira/browse/IGNITE-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10173:
Description:
(i) Related dev list discussion: [Is it time to move forward to JUnit4
(5)?|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-td29608.html]
Currently unit tests in the project are mix of two versions Junit 3 and 4. This
makes it hard to develop and maintain. Making all tests use the same version
Junit is intended to address this problem.
Another reason why migration to newer version is desirable is Junit 4 provides
developer an option to conveniently mute tests by Ignore annotation while with
Junit 3 this could only be done by adding fail and manually muting the test in
Teamcity (the latter turned out to be extremely painful when I had to do some
things per IGNITE-9884).
This task is to migrate all tests to single uniform version Junit 4 (with
further option to migrate to Junit 5, see also note below).
The difficulty of migration is that too many tests depend on Junit3-based
[GridAbstractTest|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java]
and its subclasses so that making them all change in a single move would be
very tedious and risky. A way to work around this is to create a parallel
Junit-4 based "twin" of GridAbstractTest (tentative name
{{IgniteAbstractTest}}) and using is move to Junit 4 gradually, smoothly and
safely.
Step by step plan of changes is below (made to sub-tasks under this "umbrella"
ticket):
# migrate examples tests from Junit 3 to 4
This is first task because examples are most publicly visible, relativelly
small and least risky part of unit tests in the project.
Steps: 1) create Junit-4 based twin of GridAbstractTest (and all needed
subclasses), 2) declare GridAbstractTest deprecated with reference to use newer
API instead 3) change unit tests in examples to use new API
# migrate core module tests from Junit 3 to 4
using new API introduced and tested at prior step
# migrate non-core modules tests from Junit 3 to 4
using new API introduced and tested at prior step
# cleanup Junit 3 from the project
1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
steps, if there are any
# change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
ticket URL")
Note this step would better be coordinated with Teamcity and TC bot
maintainers because it may substantially impact them
# Change new tests root to use @BeforeClass and @AfterClass instead of
isFirstTest() and isLastTest()
these homebrew methods seem to be in GridAbstractTest only because Junit 3
lacked necessary functionality; after migration to Junit 4 these would better
changed to use standard API of this framework.
# Investigate migration from Junit 4 to 5
Find out if Junit 5 is mature enough - specifically why maven still uses Junit
4 as default, are there serious reasons for that or not. If it looks okay,
create a new JIRA task to migrate.
Note on migrating to Junit 5. While preparing this task I considered an option
to migrate from Junit 3 to 5 instead of 4.
I dropped that primarily because migration from Junit 3 requires quite a lot of
manual changes in the code (changing imports and adding annotations), as
opposed to migration from Junit 4 to 5 for which there seem to be options to
make most changes automatically (eg IntelliJ seem to provide such an option).
Because of that it looks more convenient to split it to separate steps, so that
after all tests in the project get to Junit 4 we could do an automated
migration to newer version.
Another thing that made me prefer this way is that I wanted to avoid having
three different versions Junit in the project (3, 4, 5), even if that would be
temporarily (note that migration from Junit 3 is expected to be manual and
quite lengthy, so "temporarily" may mean quite a lot of time really).
Also note that as pointed in above list of steps we better make some
preliminary assessment on whether time has really come to migrate to Junit 5.
was:
(i) Related dev list discussion: [Is it time to move forward to JUnit4
(5)?|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-td29608.html]
Currently unit tests in the project are mix of two versions Junit 3 and 4. This
makes it hard to develop and maintain.
Another reason why migration to newer version is desirable is Junit 4 provides
developer an option to conveniently mute tests by Ignore annotation while with
Junit 3 this could only be done by adding fail and manually muting the test in
Teamcity (the latter turned out to be extremely painful when I had to do some
things per
[jira] [Commented] (IGNITE-9171) Use lazy mode with results pre-fetch
[
https://issues.apache.org/jira/browse/IGNITE-9171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681373#comment-16681373
]
Ignite TC Bot commented on IGNITE-9171:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2264662buildTypeId=IgniteTests24Java8_RunAll]
> Use lazy mode with results pre-fetch
>
>
> Key: IGNITE-9171
> URL: https://issues.apache.org/jira/browse/IGNITE-9171
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Blocker
> Labels: sql-stability
> Fix For: 2.8
>
>
> Current implementation of the {{lazy}} mode always starts separate thread for
> {{MapQueryLazyWorker}}. It causes excessive overhead for requests that
> produces small results set.
> We have to begin execute query at the {{QUERY_POOL}} thread pool and fetch
> first page of the results. In case results set is bigger than one page
> {{MapQueryLazyWorker}} is started and link with {{MapNodeResults}} to handle
> next pages lazy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9171) Use lazy mode with results pre-fetch
[
https://issues.apache.org/jira/browse/IGNITE-9171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681375#comment-16681375
]
Taras Ledkov commented on IGNITE-9171:
--
[~vozerov], please review the patch.
> Use lazy mode with results pre-fetch
>
>
> Key: IGNITE-9171
> URL: https://issues.apache.org/jira/browse/IGNITE-9171
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Blocker
> Labels: sql-stability
> Fix For: 2.8
>
>
> Current implementation of the {{lazy}} mode always starts separate thread for
> {{MapQueryLazyWorker}}. It causes excessive overhead for requests that
> produces small results set.
> We have to begin execute query at the {{QUERY_POOL}} thread pool and fetch
> first page of the results. In case results set is bigger than one page
> {{MapQueryLazyWorker}} is started and link with {{MapNodeResults}} to handle
> next pages lazy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9909) Merge FsyncWalManager and WalManager
[ https://issues.apache.org/jira/browse/IGNITE-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681372#comment-16681372 ] Ivan Bessonov commented on IGNITE-9909: --- [~akalashnikov] code looks good, thank you! > Merge FsyncWalManager and WalManager > > > Key: IGNITE-9909 > URL: https://issues.apache.org/jira/browse/IGNITE-9909 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > Now we have two similar WAL managers FileWriteAheadLogManager and > FsyncModeFileWriteAheadLogManager and because of similarity it is too > difficult to support them. It is need to extract unique part from them and > leave only one manager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9909) Merge FsyncWalManager and WalManager
[ https://issues.apache.org/jira/browse/IGNITE-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681370#comment-16681370 ] ASF GitHub Bot commented on IGNITE-9909: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5013 > Merge FsyncWalManager and WalManager > > > Key: IGNITE-9909 > URL: https://issues.apache.org/jira/browse/IGNITE-9909 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > Now we have two similar WAL managers FileWriteAheadLogManager and > FsyncModeFileWriteAheadLogManager and because of similarity it is too > difficult to support them. It is need to extract unique part from them and > leave only one manager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9909) Merge FsyncWalManager and WalManager
[ https://issues.apache.org/jira/browse/IGNITE-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9909: --- Ignite Flags: (was: Docs Required) > Merge FsyncWalManager and WalManager > > > Key: IGNITE-9909 > URL: https://issues.apache.org/jira/browse/IGNITE-9909 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > Now we have two similar WAL managers FileWriteAheadLogManager and > FsyncModeFileWriteAheadLogManager and because of similarity it is too > difficult to support them. It is need to extract unique part from them and > leave only one manager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9909) Merge FsyncWalManager and WalManager
[ https://issues.apache.org/jira/browse/IGNITE-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9909: --- Fix Version/s: 2.8 > Merge FsyncWalManager and WalManager > > > Key: IGNITE-9909 > URL: https://issues.apache.org/jira/browse/IGNITE-9909 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > Now we have two similar WAL managers FileWriteAheadLogManager and > FsyncModeFileWriteAheadLogManager and because of similarity it is too > difficult to support them. It is need to extract unique part from them and > leave only one manager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10173) Gradually move unit tests from Junit 3 to newer version
[
https://issues.apache.org/jira/browse/IGNITE-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681354#comment-16681354
]
Oleg Ignatenko commented on IGNITE-10173:
-
(i) related guidance: [August 2007: Migrating from JUnit 3 to JUnit 4: Nothing
but Good News --
OCI|https://objectcomputing.com/resources/publications/sett/august-2007-migrating-from-junit-3-to-junit-4-nothing-but-good-news]
> Gradually move unit tests from Junit 3 to newer version
> ---
>
> Key: IGNITE-10173
> URL: https://issues.apache.org/jira/browse/IGNITE-10173
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain, technical_debt
>
> (i) Related dev list discussion: [Is it time to move forward to JUnit4
> (5)?|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-td29608.html]
> Currently unit tests in the project are mix of two versions Junit 3 and 4.
> This makes it hard to develop and maintain.
> Another reason why migration to newer version is desirable is Junit 4
> provides developer an option to conveniently mute tests by Ignore annotation
> while with Junit 3 this could only be done by adding fail and manually muting
> the test in Teamcity (the latter turned out to be extremely painful when I
> had to do some things per IGNITE-9884).
> This task is to migrate all tests to single uniform version Junit 4 (with
> further option to migrate to Junit 5, see also note below).
> The difficulty of migration is that too many tests depend on Junit3-based
> [GridAbstractTest|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java]
> and its subclasses so that making them all change in a single move would be
> very tedious and risky. A way to work around this is to create a parallel
> Junit-4 based "twin" of GridAbstractTest (tentative name
> {{IgniteAbstractTest}}) and using is move to Junit 4 gradually, smoothly and
> safely.
> Step by step plan of changes is below (made to sub-tasks under this
> "umbrella" ticket):
> # migrate examples tests from Junit 3 to 4
> This is first task because examples are most publicly visible, relativelly
> small and least risky part of unit tests in the project.
> Steps: 1) create Junit-4 based twin of GridAbstractTest (and all needed
> subclasses), 2) declare GridAbstractTest deprecated with reference to use
> newer API instead 3) change unit tests in examples to use new API
> # migrate core module tests from Junit 3 to 4
> using new API introduced and tested at prior step
> # migrate non-core modules tests from Junit 3 to 4
> using new API introduced and tested at prior step
> # cleanup Junit 3 from the project
> 1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
> dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
> steps, if there are any
> # change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
> ticket URL")
> Note this step would better be coordinated with Teamcity and TC bot
> maintainers because it may substantially impact them
> # Change new tests root to use @BeforeClass and @AfterClass instead of
> isFirstTest() and isLastTest()
> these homebrew methods seem to be in GridAbstractTest only because Junit 3
> lacked necessary functionality; after migration to Junit 4 these would better
> changed to use standard API of this framework.
> # Investigate migration from Junit 4 to 5
> Find out if Junit 5 is mature enough - specifically why maven still uses
> Junit 4 as default, are there serious reasons for that or not. If it looks
> okay, create a new JIRA task to migrate.
>
> Note on migrating to Junit 5. While preparing this task I considered an
> option to migrate from Junit 3 to 5 instead of 4.
> I dropped that primarily because migration from Junit 3 requires quite a lot
> of manual changes in the code (changing imports and adding annotations), as
> opposed to migration from Junit 4 to 5 for which there seem to be options to
> make most changes automatically (eg IntelliJ seem to provide such an option).
> Because of that it looks more convenient to split it to separate steps, so
> that after all tests in the project get to Junit 4 we could do an automated
> migration to newer version.
> Another thing that made me prefer this way is that I wanted to avoid having
> three different versions Junit in the project (3, 4, 5), even if that would
> be temporarily (note that migration from Junit 3 is expected to be manual and
> quite lengthy, so "temporarily" may mean quite a lot of time really).
> Also note that as pointed in above
[jira] [Commented] (IGNITE-10167) MVCC-compatible IgniteCache.localEntries
[
https://issues.apache.org/jira/browse/IGNITE-10167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681325#comment-16681325
]
Ivan Pavlukhin commented on IGNITE-10167:
-
Proposed solution is to iterate over the data tree filtering visible rows with
_MAX_ snapshot seeing latest committed entries.
> MVCC-compatible IgniteCache.localEntries
>
>
> Key: IGNITE-10167
> URL: https://issues.apache.org/jira/browse/IGNITE-10167
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>
> IgniteCache API method {{localEntries}} should be supported. The idea is to
> provide an entries iterator seeing latest committed versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9843) IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta without losing data
[ https://issues.apache.org/jira/browse/IGNITE-9843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681340#comment-16681340 ] Sergey Chugunov commented on IGNITE-9843: - [~ilyak], patch looks good to me. I restarted failing suites but TC Bot still shows some tests as "possible blockers". They look flaky in fact but could you please take a quick look at them too? If they are not the problem then please proceed with merging. Thank you for contribution! > IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta > without losing data > -- > > Key: IGNITE-9843 > URL: https://issues.apache.org/jira/browse/IGNITE-9843 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > >
[jira] [Commented] (IGNITE-9870) GridDhtPartitionsFullMessage#prepareMarshal compression parallelization.
[
https://issues.apache.org/jira/browse/IGNITE-9870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681341#comment-16681341
]
Ignite TC Bot commented on IGNITE-9870:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2278248buildTypeId=IgniteTests24Java8_RunAll]
> GridDhtPartitionsFullMessage#prepareMarshal compression parallelization.
>
>
> Key: IGNITE-9870
> URL: https://issues.apache.org/jira/browse/IGNITE-9870
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.6
>Reporter: Stanilovsky Evgeny
>Assignee: Pavel Voronkin
>Priority: Major
> Fix For: 2.8
>
>
> In huge topologies ~ 200 cluster nodes , 100 caches , 32k partitions per
> cache, full map generation takes about 3 sec, seems correct approach here in
> parallelization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[ https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARomantsov updated IGNITE-9980: --- Fix Version/s: 2.8 > Modify ./control.sh --cache idle_verify --dump print to diff mode (user > persistant only/user not-persistent only/system only) cache > --- > > Key: IGNITE-9980 > URL: https://issues.apache.org/jira/browse/IGNITE-9980 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: ARomantsov >Priority: Major > Fix For: 2.8 > > > It will be cool , if control.sh --cache idle_verify can show > persistent/not-persistent/system caches and it will be impliments due utility > flag -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10052) Restart node during TX causes vacuum error.
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681318#comment-16681318
]
Andrew Mashenkov commented on IGNITE-10052:
---
[~Artukhov], thanks for feedback.
This error is not related to PDS broken state or any vacuum issues.
For now, Tx operation can fails due to primary\backup node failure.
This should be fixed within IGNITE-9928 and partially in IGNITE-7164.
> Restart node during TX causes vacuum error.
> ---
>
> Key: IGNITE-10052
> URL: https://issues.apache.org/jira/browse/IGNITE-10052
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.7
>
>
> 1. Start 2 nodes with PDS, activate , start {{sqlline}}
> 2. Create table
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1 (a int, b int, primary
> key(a)) with "atomicity=TRANSACTIONAL_SNAPSHOT,
> backups=1";
> No rows affected (0,294 seconds)
> {noformat}
> 3. Open TX:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,007 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> 1 row affected (0,112 seconds)
> {noformat}
> 4. Stop and then start 2nd node
> 5. Rollback TX and check the table data (no rows added):
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> rollback;
> No rows affected (0,011 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> select * from t1;
> +++
> | A| B|
> +++
> +++
> No rows selected (0,067 seconds)
> {noformat}
> 6. Start second TX that throws the exception:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,001 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> Error: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []] (state=50
> 000,code=1)
> java.sql.SQLException: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchR
> ow []]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> The server nodes print out:
> {noformat}
> [18:46:32,136][SEVERE][jdbc-request-handler-worker-#62][DmlStatementsProcessor]
> Error during update [localNodeId=319a2fda-1315-4bdf-8647-7ddee2d3342e]
> class org.apache.ignite.IgniteCheckedException: Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1919)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:530)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:460)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:368)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearTxQueryResultsEnlistRequest(GridDhtTransactionalCacheAdapter.java:2000)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$700(GridDhtTransactionalCacheAdapter.java:112)
> at
>
[jira] [Commented] (IGNITE-9558) Avoid changing AffinityTopologyVersion on client connect when possible
[ https://issues.apache.org/jira/browse/IGNITE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681313#comment-16681313 ] Alexey Goncharuk commented on IGNITE-9558: -- I also see an OOME in PDS Indexing suite, this was recently fixed in master. > Avoid changing AffinityTopologyVersion on client connect when possible > -- > > Key: IGNITE-9558 > URL: https://issues.apache.org/jira/browse/IGNITE-9558 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Assignee: Ilya Lantukh >Priority: Major > Fix For: 2.8 > > > Currently a client join event changes discovery topology version which, in > turn, changes AffinityTopologyVersion. > When a client maps transaction on new AffinityTopologyVersion, corresponding > message is not processed on remote node until remote node receives the > corresponding discovery event. If discovery event delivery is delayed for > some reason, this will result in transaction stalls on client joins. > Since the client node does not change partition affinity, we can safely map > transactions on the previous topology version and do not change the affinity > topology version at all. > Some cases need special care and probably do not qualify for this > optimization, such as when client has near cache or client hosts partition > for REPLICATED cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9558) Avoid changing AffinityTopologyVersion on client connect when possible
[
https://issues.apache.org/jira/browse/IGNITE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681310#comment-16681310
]
Alexey Goncharuk commented on IGNITE-9558:
--
[~ilantukh] I see the following error on TC:
{code}
[16:37:45]W: [org.apache.ignite:ignite-core]
java.lang.AssertionError: Invalid cached affinity:
[cache=HistoryAffinityAssignment [topVer=AffinityTopologyVersion [topVer=251,
minorTopVer=0], mvccCrd=MvccCoordinator
[nodeId=1fd96fa9-55f1-46c4-854e-f7844300, crdVer=1541684159656,
topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0]]],
topVer=AffinityTopologyVersion [topVer=10, minorTopVer=0],
lastAffChangedTopVer=AffinityTopologyVersion [topVer=10, minorTopVer=0]]
{code}
https://ci.ignite.apache.org/viewLog.html?buildId=2271833=IgniteTests24Java8_Basic1=buildResultsDiv
Please take a look.
> Avoid changing AffinityTopologyVersion on client connect when possible
> --
>
> Key: IGNITE-9558
> URL: https://issues.apache.org/jira/browse/IGNITE-9558
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.8
>
>
> Currently a client join event changes discovery topology version which, in
> turn, changes AffinityTopologyVersion.
> When a client maps transaction on new AffinityTopologyVersion, corresponding
> message is not processed on remote node until remote node receives the
> corresponding discovery event. If discovery event delivery is delayed for
> some reason, this will result in transaction stalls on client joins.
> Since the client node does not change partition affinity, we can safely map
> transactions on the previous topology version and do not change the affinity
> topology version at all.
> Some cases need special care and probably do not qualify for this
> optimization, such as when client has near cache or client hosts partition
> for REPLICATED cache.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10052) Restart node during TX causes vacuum error.
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681309#comment-16681309
]
Ivan Artukhov commented on IGNITE-10052:
The latter problem seems to be the cause of
https://issues.apache.org/jira/browse/IGNITE-9928.
> Restart node during TX causes vacuum error.
> ---
>
> Key: IGNITE-10052
> URL: https://issues.apache.org/jira/browse/IGNITE-10052
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.7
>
>
> 1. Start 2 nodes with PDS, activate , start {{sqlline}}
> 2. Create table
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1 (a int, b int, primary
> key(a)) with "atomicity=TRANSACTIONAL_SNAPSHOT,
> backups=1";
> No rows affected (0,294 seconds)
> {noformat}
> 3. Open TX:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,007 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> 1 row affected (0,112 seconds)
> {noformat}
> 4. Stop and then start 2nd node
> 5. Rollback TX and check the table data (no rows added):
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> rollback;
> No rows affected (0,011 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> select * from t1;
> +++
> | A| B|
> +++
> +++
> No rows selected (0,067 seconds)
> {noformat}
> 6. Start second TX that throws the exception:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,001 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> Error: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []] (state=50
> 000,code=1)
> java.sql.SQLException: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchR
> ow []]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> The server nodes print out:
> {noformat}
> [18:46:32,136][SEVERE][jdbc-request-handler-worker-#62][DmlStatementsProcessor]
> Error during update [localNodeId=319a2fda-1315-4bdf-8647-7ddee2d3342e]
> class org.apache.ignite.IgniteCheckedException: Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1919)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:530)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:460)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:368)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearTxQueryResultsEnlistRequest(GridDhtTransactionalCacheAdapter.java:2000)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$700(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$12.apply(GridDhtTransactionalCacheAdapter.java:215)
> at
>
[jira] [Updated] (IGNITE-10205) add to utility command - ./control.sh --cache idle_verify --dump abbility to exclude cache from output file
[ https://issues.apache.org/jira/browse/IGNITE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARomantsov updated IGNITE-10205: Affects Version/s: 2.6 > add to utility command - ./control.sh --cache idle_verify --dump abbility to > exclude cache from output file > > > Key: IGNITE-10205 > URL: https://issues.apache.org/jira/browse/IGNITE-10205 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: ARomantsov >Priority: Critical > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10196) Change scope of kafka-clients-*-test dependency to test
[ https://issues.apache.org/jira/browse/IGNITE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681293#comment-16681293 ] ASF GitHub Bot commented on IGNITE-10196: - GitHub user Max-Pudov opened a pull request: https://github.com/apache/ignite/pull/5356 IGNITE-10196 Change scope of kafka-clients-*-test dependency to test You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10196 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5356.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 #5356 commit 0b6a30d71004b0746fe9290c606b10a26062d529 Author: Max-Pudov Date: 2018-11-09T11:19:05Z IGNITE-10196 Change scope of kafka-clients-*-test dependency to test > Change scope of kafka-clients-*-test dependency to test > --- > > Key: IGNITE-10196 > URL: https://issues.apache.org/jira/browse/IGNITE-10196 > Project: Ignite > Issue Type: Bug > Components: build >Affects Versions: 2.7 >Reporter: Sergey Kozlov >Assignee: Maxim Pudov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10205) add to utility command - ./control.sh --cache idle_verify --dump abbility to exclude cache from output file
[ https://issues.apache.org/jira/browse/IGNITE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARomantsov updated IGNITE-10205: Fix Version/s: 2.8 > add to utility command - ./control.sh --cache idle_verify --dump abbility to > exclude cache from output file > > > Key: IGNITE-10205 > URL: https://issues.apache.org/jira/browse/IGNITE-10205 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: ARomantsov >Priority: Critical > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10205) add to utility command - ./control.sh --cache idle_verify --dump abbility to exclude cache from output file
ARomantsov created IGNITE-10205: --- Summary: add to utility command - ./control.sh --cache idle_verify --dump abbility to exclude cache from output file Key: IGNITE-10205 URL: https://issues.apache.org/jira/browse/IGNITE-10205 Project: Ignite Issue Type: Improvement Reporter: ARomantsov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[ https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARomantsov updated IGNITE-9980: --- Issue Type: Improvement (was: Bug) > Modify ./control.sh --cache idle_verify --dump print to diff mode (user > persistant only/user not-persistent only/system only) cache > --- > > Key: IGNITE-9980 > URL: https://issues.apache.org/jira/browse/IGNITE-9980 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: ARomantsov >Priority: Major > Fix For: 2.8 > > > It will be cool , if control.sh --cache idle_verify can show > persistent/not-persistent/system caches and it will be impliments due utility > flag -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10159) IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap fails non-null assertion at localPeek
[
https://issues.apache.org/jira/browse/IGNITE-10159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681307#comment-16681307
]
Ignite TC Bot commented on IGNITE-10159:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2278938]]
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlQueryMinMaxTest.testMinMaxQueryPlanOnKey - 0,0% fails in last 100
master runs.
{color:#d04437}Cache (Restarts) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2278903]]
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithPutEightNodesTwoBackups -
0,0% fails in last 100 master runs.
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2278883]]
* IgniteBasicTestSuite: GridEventConsumeSelfTest.testAllEvents - 0,0% fails in
last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2278836]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
OomFailureHandlerTest.testServiceExecuteOomError - 0,0% fails in last 100
master runs.
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2278877]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_KillRandom - 0,0%
fails in last 100 master runs.
{color:#d04437}Platform C++ (Linux){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2278879]]
{color:#d04437}Thin client: Python{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2278940]]
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2278945buildTypeId=IgniteTests24Java8_RunAll]
> IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap fails non-null
> assertion at localPeek
> --
>
> Key: IGNITE-10159
> URL: https://issues.apache.org/jira/browse/IGNITE-10159
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap (in current codebase
> muted by renaming to {{_testObjectQueryWithSwap}}) fails with the following
> error:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertNotNull(Assert.java:256)
> at junit.framework.Assert.assertNotNull(Assert.java:248)
> at junit.framework.TestCase.assertNotNull(TestCase.java:417)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap(IgniteCacheAbstractQuerySelfTest.java:960)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ...{noformat}
> Code referred to above is:
> {code}assertNotNull(c.localPeek(i, CachePeekMode.ONHEAP));{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[ https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARomantsov updated IGNITE-9980: --- Description: It will be cool , if control.sh --cache idle_verify can show persistent/not-persistent/system caches and it will be impliments due utility flag (was: It will be cool , if control.sh --cache idle_verify can show persistent/not-persistent/both caches and it will be impliments due utility flag) > Modify ./control.sh --cache idle_verify --dump print to diff mode (user > persistant only/user not-persistent only/system only) cache > --- > > Key: IGNITE-9980 > URL: https://issues.apache.org/jira/browse/IGNITE-9980 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: ARomantsov >Priority: Major > > It will be cool , if control.sh --cache idle_verify can show > persistent/not-persistent/system caches and it will be impliments due utility > flag -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[ https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARomantsov updated IGNITE-9980: --- Summary: Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache (was: Modify ./control.sh --cache idle_verify --dump to print only persistante cache or add flag --persistentOnly) > Modify ./control.sh --cache idle_verify --dump print to diff mode (user > persistant only/user not-persistent only/system only) cache > --- > > Key: IGNITE-9980 > URL: https://issues.apache.org/jira/browse/IGNITE-9980 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: ARomantsov >Priority: Major > > It will be cool , if control.sh --cache idle_verify can show > persistent/not-persistent/both caches and it will be impliments due utility > flag -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10052) Restart node during TX causes vacuum error.
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681287#comment-16681287
]
Ivan Artukhov edited comment on IGNITE-10052 at 11/9/18 11:26 AM:
--
Commit b2f697b shows another error when I go through the steps from description.
Error on client's side:
{code}
0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
Error: Failed to run update. Failed to update backup node:
[localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98,
remoteNodeId=56dadffc-0d9a-4c42-8d3b-55266e093fc8] (state=5,code=1)
{code}
On server's side:
{noformat}
[14:08:44,202][SEVERE][jdbc-request-handler-worker-#48][DmlStatementsProcessor]
Error during update [localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98]
class org.apache.ignite.IgniteCheckedException: Failed to update backup node:
[localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98,
remoteNodeId=56dadffc-0d9a-4c42-8d3b-55266e093fc8]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:987)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2342)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1939)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:532)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.mvccEnlistBatch(IgniteTxHandler.java:1920)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2305)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1100(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:250)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:248)
... 13 more
Caused by: class
org.apache.ignite.internal.transactions.IgniteTxMvccVersionCheckedException:
Unexpected state: [state=0, rowVer=1541761538351:12:1,
[jira] [Commented] (IGNITE-10167) MVCC-compatible IgniteCache.localEntries
[
https://issues.apache.org/jira/browse/IGNITE-10167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681296#comment-16681296
]
ASF GitHub Bot commented on IGNITE-10167:
-
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5357
IGNITE-10167: MVCC-compatible IgniteCache.localEntries
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10167
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5357.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 #5357
commit 0359a3ad885c869a6d492af23e84fa8507bac848
Author: ipavlukhin
Date: 2018-11-02T15:32:56Z
mvcc-compatible peek draft
commit 514b793910a88ab4718829d1f77055f45740e349
Author: ipavlukhin
Date: 2018-11-06T11:09:40Z
do "peek" operation similarly to SQL query (use mvcc tracker)
commit 751048bed4012be6608bb01fdc42a2ab58ef5395
Author: ipavlukhin
Date: 2018-11-06T11:13:23Z
add todo
commit 067782a81e7851f3c84455fdfb281a537fd142a3
Author: ipavlukhin
Date: 2018-11-06T11:28:25Z
Merge branch 'master' into mvcc-peek
commit 1b2a19969039c9a53da9de9b5802c7aa751a6a7c
Author: ipavlukhin
Date: 2018-11-06T11:29:56Z
cleanup
commit c1f774ee78b46587cb42010782b8b435df640159
Author: ipavlukhin
Date: 2018-11-06T14:02:45Z
use special MAX snapshot which can see all committed versions for mvccPeek
commit 1d46b4b20f49dd2cdacebc45b993b4972fe2c533
Author: ipavlukhin
Date: 2018-11-06T17:45:33Z
tune MVCC_MAX_SNAPSHOT
commit 35b822e87b80ba428dec23d4068cead3ea306988
Author: ipavlukhin
Date: 2018-11-06T17:47:30Z
dummy for a code style
commit c90c3f34c0b7b732f139024e24e42716c03e02ac
Author: ipavlukhin
Date: 2018-11-07T06:28:20Z
move peek test to core module
commit e88d70910ef43f0c7803928d6732e0b6ea0bcaac
Author: ipavlukhin
Date: 2018-11-07T06:31:17Z
remove test checking that peek is not supported for mvcc
commit 61b019bbf7a270d4f80b4acfeb9b1c113a9fbef4
Author: ipavlukhin
Date: 2018-11-07T08:45:25Z
* call checkObsolete() in mvccPeek;
* javadoc for mvccPeek.
commit c4e2807c53ce545d46f6b0161eaa7c484487c600
Author: ipavlukhin
Date: 2018-11-07T09:31:54Z
update IgniteCache.peek javadoc
commit 0db14098fe2e36cc74c1a0a35b0eefb4a709453d
Author: ipavlukhin
Date: 2018-11-07T09:38:27Z
minor javadoc fix
commit 63e8de61963b10b3c71800275d0f44c8169550a6
Author: ipavlukhin
Date: 2018-11-07T09:43:58Z
comments for special mvcc constants
commit b57533135cace90828caa1cea0d964e709876213
Author: ipavlukhin
Date: 2018-11-07T10:03:35Z
rework MvccCachePeekTest to stop grid only once
commit 25653c9b255294268722e2e62dfeb422b6a8c21b
Author: ipavlukhin
Date: 2018-11-07T10:41:20Z
Merge branch 'master' into mvcc-peek
commit edb496b9489615852d2c48960d79b4d8325e375a
Author: ipavlukhin
Date: 2018-11-07T13:28:22Z
adopt existing peek tests and add them to MVCC suite
commit 16219757547e0fe14a96622ad9d53cce1c7ff331
Author: ipavlukhin
Date: 2018-11-08T13:27:36Z
Merge branch 'master' into mvcc-peek
commit 977f13a2d39e0f4785e06ea4775d25a3e45ce264
Author: ipavlukhin
Date: 2018-11-08T16:08:57Z
IgniteCache.localEntries draft
commit 5d71df8da19211aedc428bf96ea95eb2359b4789
Author: ipavlukhin
Date: 2018-11-09T10:59:27Z
use MvccUtils.MVCC_MAX_SNAPSHOT for "localEntries" implementation
commit eea412024fcb58072c7ddfcc92a9e36ae28ac943
Author: ipavlukhin
Date: 2018-11-09T11:03:29Z
minor
> MVCC-compatible IgniteCache.localEntries
>
>
> Key: IGNITE-10167
> URL: https://issues.apache.org/jira/browse/IGNITE-10167
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>
> IgniteCache API method {{localEntries}} should be supported. The idea is to
> provide an entries iterator seeing latest committed versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10196) Change scope of kafka-clients-*-test dependency to test
[ https://issues.apache.org/jira/browse/IGNITE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Pudov updated IGNITE-10196: - Summary: Change scope of kafka-clients-*-test dependency to test (was: Remove kafka-clients-*-test dependency) > Change scope of kafka-clients-*-test dependency to test > --- > > Key: IGNITE-10196 > URL: https://issues.apache.org/jira/browse/IGNITE-10196 > Project: Ignite > Issue Type: Bug > Components: build >Affects Versions: 2.7 >Reporter: Sergey Kozlov >Assignee: Maxim Pudov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10052) Restart node during TX causes vacuum error.
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681287#comment-16681287
]
Ivan Artukhov commented on IGNITE-10052:
Commit b2f697b shows another error when I go through the steps from description.
Error on client's side:
{code}
0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
Error: Failed to run update. Failed to update backup node:
[localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98,
remoteNodeId=56dadffc-0d9a-4c42-8d3b-55266e093fc8] (state=5,code=1)
{code}
On server's side:
{code}
[14:08:44,202][SEVERE][jdbc-request-handler-worker-#48][DmlStatementsProcessor]
Error during update [localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98]
class org.apache.ignite.IgniteCheckedException: Failed to update backup node:
[localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98,
remoteNodeId=56dadffc-0d9a-4c42-8d3b-55266e093fc8]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:987)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2342)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1939)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:532)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.mvccEnlistBatch(IgniteTxHandler.java:1920)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2305)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1100(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:250)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:248)
... 13 more
{code}
*a80dc9b8-6a28-4015-a288-0436e2916f98* is the ID of the first server node.
*56dadffc-0d9a-4c42-8d3b-55266e093fc8* is the ID of the second (restarted)
server node.
> Restart node during TX causes
[jira] [Commented] (IGNITE-9005) Eviction policy MBeans change failed LifecycleAwareTest on cache name injectoin
[
https://issues.apache.org/jira/browse/IGNITE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681286#comment-16681286
]
Stanislav Lukyanov commented on IGNITE-9005:
I've taken a look at my PR and at the issue one more time. The problem is that
cache doesn't properly initalize all of the nested lifecycle aware entities. I
think a good solution is to move initialization outside of the cache itself.
Eviction policies are owned by eviction manager, so let's handle them there.
I can't remember what was the problem with the PR in its current state -
probably some test failures.
I've started a TC run, let's wait for the result. I guess if the tests pass we
might ask for a review and merge.
> Eviction policy MBeans change failed LifecycleAwareTest on cache name
> injectoin
> ---
>
> Key: IGNITE-9005
> URL: https://issues.apache.org/jira/browse/IGNITE-9005
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1485687-needs-to-be-handled-td32531.html
> New test failure detected
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7246907407546697403=%3Cdefault%3E=testDetails
> after merging
> IGNITE-8776 Eviction policy MBeans are never registered if
> evictionPolicyFactory is used
> Revert of commit makes test passing.
> Locally test also failed. Failed with message
> {noformat}
> Unexpected cache name for
> org.apache.ignite.internal.processors.cache.GridCacheLifecycleAwareSelfTest$TestEvictionPolicy@322714f4
> expected: but was:
> {noformat}
> Message of failure seems to be related to TestEvictionPolicy instance from
> test class.
> Seems that returing call to cctx.kernalContext (). resource ().
> injectCacheName (rsrc, cfg.getName ()); should fix issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-884) Cache store usability issues
[
https://issues.apache.org/jira/browse/IGNITE-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681277#comment-16681277
]
PetrovMikhail commented on IGNITE-884:
--
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Basic 1{color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=2226949]]
* IgniteBasicTestSuite: GridVersionSelfTest.testVersions - 3,2% fails in last
100 master runs.
* IgniteBasicTestSuite: GridMessageListenSelfTest.testNonNullTopic - 0,0% fails
in last 100 master runs.
* IgniteBasicTestSuite: GridMessageListenSelfTest.testStopListen - 0,0% fails
in last 100 master runs.
* IgniteBasicTestSuite:
IgniteDaemonNodeMarshallerCacheTest.testMarshalOnDaemonNode1 - 0,0% fails in
last 100 master runs.
* IgniteBasicTestSuite: GridP2PLocalDeploymentSelfTest.testIsolatedMode - 0,0%
fails in last 100 master runs.
{color:#d04437}SPI{color} [[tests 5 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=2226936]]
* IgniteSpiTestSuite:
GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow - 0,0% fails in
last 100 master runs.
* IgniteSpiTestSuite:
IgniteTcpCommunicationRecoveryAckClosureSelfTest.testAckOnIdle - 0,0% fails in
last 100 master runs.
* IgniteSpiTestSuite:
IgniteTcpCommunicationRecoveryAckClosureSelfTest.testAckOnCount - 0,0% fails in
last 100 master runs.
* IgniteSpiTestSuite:
IgniteTcpCommunicationRecoveryAckClosureSelfTest.testQueueOverflow - 0,0% fails
in last 100 master runs.
* IgniteSpiTestSuite:
GridTcpCommunicationSpiConcurrentConnectSelfTest.testWithLoad - 0,0% fails in
last 100 master runs.
{color:#d04437}Client Nodes{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2226906]]
* IgniteClientNodesTestSuite:
IgniteClientReconnectFailoverTest.testReconnectAtomicCache - 0,0% fails in last
100 master runs.
{color:#d04437}Java Client{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=2226923]]
* IgniteClientTestSuite: RestMemcacheProtocolSelfTest.testMetrics - 0,0% fails
in last 100 master runs.
{color:#d04437}Cache 2{color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=2226973]]
* IgniteCacheTestSuite2: GridCacheLocalIsolatedNodesSelfTest.testIsolatedNodes
- 0,0% fails in last 100 master runs.
{color:#d04437}Cache 4{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=2226975]]
* IgniteCacheTestSuite4:
IgniteDynamicCacheStartNoExchangeTimeoutTest.testOldestNotAffinityNode1 - 0,0%
fails in last 100 master runs.
* IgniteCacheTestSuite4: IgniteStartCacheInTransactionSelfTest.testStopCache -
0,0% fails in last 100 master runs.
{color:#d04437}Cache (Full API Multi JVM){color} [[tests
175|https://ci.ignite.apache.org/viewLog.html?buildId=2226967]]
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedNearDisabledMultiJvmFullApiSelfTest.testPutAllRemoveAll -
0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedCopyOnReadDisabledMultiJvmFullApiSelfTest.testPutAllRemoveAll
- 0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedMultiJvmFullApiSelfTest.testPutAllRemoveAll - 0,0% fails in
last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedMultiJvmP2PDisabledFullApiSelfTest.testPutAllRemoveAll -
0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedNearDisabledMultiJvmP2PDisabledFullApiSelfTest.testPutAllRemoveAll
- 0,0% fails in last 100 master runs.
{color:#d04437}AOP{color} [[tests
41|https://ci.ignite.apache.org/viewLog.html?buildId=2226898]]
* IgniteAopSelfTestSuite: NonSpringAopSelfTest.testNonDefaultNameIsolated -
0,0% fails in last 100 master runs.
* IgniteAopSelfTestSuite: NonSpringAopSelfTest.testNonDefaultNameResourceShared
- 0,0% fails in last 100 master runs.
* IgniteAopSelfTestSuite:
ExternalNonSpringAopSelfTest.testTaskNameAndTaskClassShared - 0,0% fails in
last 100 master runs.
* IgniteAopSelfTestSuite:
ExternalNonSpringAopSelfTest.testNonDefaultNameResourceIsolated - 0,0% fails in
last 100 master runs.
* IgniteAopSelfTestSuite: ExternalNonSpringAopSelfTest.testNonDefaultNameShared
- 0,0% fails in last 100 master runs.
* IgniteAopSelfTestSuite:
ExternalNonSpringAopSelfTest.testNonDefaultNameResourceContinuous - 0,0% fails
in last 100 master runs.
* IgniteAopSelfTestSuite:
ExternalNonSpringAopSelfTest.testNonDefaultClassResourceShared - 0,0% fails in
last 100 master runs.
* IgniteAopSelfTestSuite:
ExternalNonSpringAopSelfTest.testTaskNameAndTaskClassContinuous - 0,0% fails in
last 100 master runs.
* IgniteAopSelfTestSuite:
ExternalNonSpringAopSelfTest.testNonDefaultNameContinuous - 0,0% fails in last
100 master runs.
* IgniteAopSelfTestSuite: ExternalNonSpringAopSelfTest.testNonDefaultContinuous
- 0,0% fails in last 100 master
[jira] [Commented] (IGNITE-9870) GridDhtPartitionsFullMessage#prepareMarshal compression parallelization.
[
https://issues.apache.org/jira/browse/IGNITE-9870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681259#comment-16681259
]
Ignite TC Bot commented on IGNITE-9870:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 3{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2278967]]
* IgniteBinaryObjectsCacheTestSuite3:
GridCacheWriteBehindStoreReplicatedTest.testWriteThrough - 0,0% fails in last
100 master runs.
* IgniteBinaryObjectsCacheTestSuite3:
GridCacheWriteBehindStoreLocalTest.testWriteThrough - 0,0% fails in last 100
master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2278248buildTypeId=IgniteTests24Java8_RunAll]
> GridDhtPartitionsFullMessage#prepareMarshal compression parallelization.
>
>
> Key: IGNITE-9870
> URL: https://issues.apache.org/jira/browse/IGNITE-9870
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.6
>Reporter: Stanilovsky Evgeny
>Assignee: Pavel Voronkin
>Priority: Major
> Fix For: 2.8
>
>
> In huge topologies ~ 200 cluster nodes , 100 caches , 32k partitions per
> cache, full map generation takes about 3 sec, seems correct approach here in
> parallelization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9406) Improve SQL "Performance and Debugging" page
[ https://issues.apache.org/jira/browse/IGNITE-9406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-9406: -- Assignee: Vladimir Ozerov (was: Artem Budnikov) > Improve SQL "Performance and Debugging" page > > > Key: IGNITE-9406 > URL: https://issues.apache.org/jira/browse/IGNITE-9406 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > Attachments: ignite_sql_perf.txt > > > I prepared a document for one of Ignite clients with some advanced > information about how various performance optimizations work in Ignite SQL. > Let's compare this document with our "Performance and Debugging" page [1], > and enhance the latter with missing info (if any). > P.S.: Document is attached. Russian language. > [1] > https://apacheignite-sql.readme.io/docs/performance-and-debugging#query-execution-flow-optimizations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-10196) Remove kafka-clients-*-test dependency
[ https://issues.apache.org/jira/browse/IGNITE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Pudov reopened IGNITE-10196: -- however, we need to exclude it from the binary version of our project > Remove kafka-clients-*-test dependency > -- > > Key: IGNITE-10196 > URL: https://issues.apache.org/jira/browse/IGNITE-10196 > Project: Ignite > Issue Type: Bug > Components: build >Affects Versions: 2.7 >Reporter: Sergey Kozlov >Assignee: Maxim Pudov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10167) MVCC-compatible IgniteCache.localEntries
[
https://issues.apache.org/jira/browse/IGNITE-10167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin reassigned IGNITE-10167:
---
Assignee: Ivan Pavlukhin
> MVCC-compatible IgniteCache.localEntries
>
>
> Key: IGNITE-10167
> URL: https://issues.apache.org/jira/browse/IGNITE-10167
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
>
> IgniteCache API method {{localEntries}} should be supported. The idea is to
> provide an entries iterator seeing latest committed versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10151) Fix BinaryMarshallerSelfTest#testDefaultMapping test
[
https://issues.apache.org/jira/browse/IGNITE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681195#comment-16681195
]
ASF GitHub Bot commented on IGNITE-10151:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5316
> Fix BinaryMarshallerSelfTest#testDefaultMapping test
>
>
> Key: IGNITE-10151
> URL: https://issues.apache.org/jira/browse/IGNITE-10151
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> BinaryMarshallerSelfTest#testDefaultMapping:
> reflectively refers method {{BinaryContext.typeName}} that was removed per
> IGNITE-2191 in [commit
> 40f9a8d|https://github.com/apache/ignite/commit/62502b2c44d7d35584b31c8f1284b810840f9a8d]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10204) Web Console: Rename "Allow non-collocated joins" checkbox
Vica Abramova created IGNITE-10204: -- Summary: Web Console: Rename "Allow non-collocated joins" checkbox Key: IGNITE-10204 URL: https://issues.apache.org/jira/browse/IGNITE-10204 Project: Ignite Issue Type: Improvement Components: UI, wizards Reporter: Vica Abramova Assignee: Alexey Kuznetsov Rename checkbox "Allow non-collocated joins" => "Allow distributed joins" In the Web Console's query tab, it says "Allow non-collocated joins". I propose that this be renamed to "Allow distributed joins". I say that because in your documentation it refers to it as distributed joins. Inconsistent naming caused some confusion to our development teams. Consistent naming can solve this. https://apacheignite-sql.readme.io/docs/distributed-joins Attached is screenshot of what I get from google when search for non-collocated joins which seems to suggests that distrbuted joins is the preferred terminology. https://www.google.com/search?q=GridGain+non-collocated+joins -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10196) Remove kafka-clients-*-test dependency
[ https://issues.apache.org/jira/browse/IGNITE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Pudov resolved IGNITE-10196. -- Resolution: Won't Fix Tests don't work without this dependency [https://stackoverflow.com/questions/25195583/kafka-jar-does-not-include-kafka-utils-testutils/33665275] > Remove kafka-clients-*-test dependency > -- > > Key: IGNITE-10196 > URL: https://issues.apache.org/jira/browse/IGNITE-10196 > Project: Ignite > Issue Type: Bug > Components: build >Affects Versions: 2.7 >Reporter: Sergey Kozlov >Assignee: Maxim Pudov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9171) Use lazy mode with results pre-fetch
[
https://issues.apache.org/jira/browse/IGNITE-9171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681182#comment-16681182
]
Ignite TC Bot commented on IGNITE-9171:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2264654]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteSqlSplitterSelfTest.testReplicatedTablesUsingPartitionedCacheClient -
0,0% fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2264662buildTypeId=IgniteTests24Java8_RunAll]
> Use lazy mode with results pre-fetch
>
>
> Key: IGNITE-9171
> URL: https://issues.apache.org/jira/browse/IGNITE-9171
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Blocker
> Labels: sql-stability
> Fix For: 2.8
>
>
> Current implementation of the {{lazy}} mode always starts separate thread for
> {{MapQueryLazyWorker}}. It causes excessive overhead for requests that
> produces small results set.
> We have to begin execute query at the {{QUERY_POOL}} thread pool and fetch
> first page of the results. In case results set is bigger than one page
> {{MapQueryLazyWorker}} is started and link with {{MapNodeResults}} to handle
> next pages lazy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9976) [Test Failed] BinaryMetadataUpdatesFlowTest.testFlowNoConflicts flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-9976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681158#comment-16681158
]
ASF GitHub Bot commented on IGNITE-9976:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5056
> [Test Failed] BinaryMetadataUpdatesFlowTest.testFlowNoConflicts flaky fails
> on TC.
> --
>
> Key: IGNITE-9976
> URL: https://issues.apache.org/jira/browse/IGNITE-9976
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Test {{BinaryMetadataUpdatesFlowTest.testFlowNoConflicts}} fails sometimes on
> master branch.
> Example of recent failure:
> https://ci.ignite.apache.org/viewLog.html?buildId=2136137=buildResultsDiv=IgniteTests24Java8_BinaryObjects#testNameId-3561618975502992496
> Typical failure 1:
> {noformat}
> [2018-10-20 16:26:55,321][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: There are less than expected entries,
> data loss occurred; expected:<5000> but was:<4108>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.TestCase.assertEquals(TestCase.java:401)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataUpdatesFlowTest.testFlowNoConflicts(BinaryMetadataUpdatesFlowTest.java:309)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:142)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2091)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Suggested solution - await {{PME}} before call {{IgniteCache#size()}}.
> Typical failure 2:
> {noformat}
> java.lang.AssertionError: Error occurred on grid stop (see log for more
> details).
> ...
> [ERROR][node-killer-thread][root] Failed to stop grid
> [igniteInstanceName=binary.BinaryMetadataUpdatesFlowTest2, cancel=false]
> class org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
> interrupted
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7783)
> at
> org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1737)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2325)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1187)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1162)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1462)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataUpdatesFlowTest.access$900(BinaryMetadataUpdatesFlowTest.java:65)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataUpdatesFlowTest$ServerNodeKiller.run(BinaryMetadataUpdatesFlowTest.java:444)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7778)
> ... 8 more
> {noformat}
> Suggested solution - in test framework don't interrupt thread from which we
> call the {{stopGrid}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10188) Move tests with persistence to the convenient suite
[
https://issues.apache.org/jira/browse/IGNITE-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681156#comment-16681156
]
Ryabov Dmitrii commented on IGNITE-10188:
-
[~EdShangGG], ok, should I remove public static field with this property too?
> Move tests with persistence to the convenient suite
> ---
>
> Key: IGNITE-10188
> URL: https://issues.apache.org/jira/browse/IGNITE-10188
> Project: Ignite
> Issue Type: Test
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Major
>
> Tests with persistence from {{IgniteCachePartitionLossPolicySelfTest}} must
> be moved to another class and suite.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
