[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=1210#comment-1210
]
Pavel Pereslegin edited comment on IGNITE-9858 at 10/27/18 8:00 PM:
[~agoncharuk], check for client node is performed in
{{TcpDiscoveryIpFinderAdapter#initializeLocalAddresses}} (I updated ticket
description).
We have one instance of IpFinder and following execution order:
1. Server injects ignite instance resource into IpFinder.
{noformat}
at
org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:283)
at
org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:252)
at
org.apache.ignite.internal.processors.resource.GridResourceProcessor.injectGeneric(GridResourceProcessor.java:233)
at
org.apache.ignite.internal.managers.GridManagerAdapter.inject(GridManagerAdapter.java:173)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:257)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
{noformat}
2. Client injects ignite instance resource into IpFinder (same stacktrace).
3. Client initializes SPI, checks for client discovery:
{noformat}
at
org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinderAdapter.discoveryClientMode(TcpDiscoveryIpFinderAdapter.java:113)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinderAdapter.initializeLocalAddresses(TcpDiscoveryIpFinderAdapter.java:61)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoveryImpl.registerLocalNodeAddress(TcpDiscoveryImpl.java:338)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStart(ClientImpl.java:298)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2023)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
{noformat}
4. Server initializes SPI:
{noformat}
at
org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinderAdapter.discoveryClientMode(TcpDiscoveryIpFinderAdapter.java:113)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinderAdapter.initializeLocalAddresses(TcpDiscoveryIpFinderAdapter.java:61)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoveryImpl.registerLocalNodeAddress(TcpDiscoveryImpl.java:338)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:374)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2023)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
{noformat}
As a result both nodes assume that the local node is a client and don't
register local address.
Usually in tests we start client node after starting the server, so this
problem is not reproduced.
was (Author: xtern):
[~agoncharuk], check for client node is performed in
[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=1210#comment-1210
]
Pavel Pereslegin commented on IGNITE-9858:
--
[~agoncharuk], check for client node is performed in
{{TcpDiscoveryIpFinderAdapter#initializeLocalAddresses}} (I updated ticket
description).
We have one instance of IpFinder and following execution order:
1. Server injects ignite instance resource into IpFinder.
{noformat}
at
org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:283)
at
org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:252)
at
org.apache.ignite.internal.processors.resource.GridResourceProcessor.injectGeneric(GridResourceProcessor.java:233)
at
org.apache.ignite.internal.managers.GridManagerAdapter.inject(GridManagerAdapter.java:173)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:257)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
{noformat}
2. Client injects ignite instance resource into IpFinder (same stacktrace).
3. Client initializes SPI, checks for client discovery:
{noformat}
at
org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinderAdapter.discoveryClientMode(TcpDiscoveryIpFinderAdapter.java:113)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinderAdapter.initializeLocalAddresses(TcpDiscoveryIpFinderAdapter.java:61)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoveryImpl.registerLocalNodeAddress(TcpDiscoveryImpl.java:338)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStart(ClientImpl.java:298)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2023)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
{noformat}
4. Server initializes SPI:
{noformat}
at
org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinderAdapter.discoveryClientMode(TcpDiscoveryIpFinderAdapter.java:113)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinderAdapter.initializeLocalAddresses(TcpDiscoveryIpFinderAdapter.java:61)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoveryImpl.registerLocalNodeAddress(TcpDiscoveryImpl.java:338)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:374)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2023)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
{noformat}
As a result both nodes assume that the local node is a client and don't
register local address.
> [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
>
>
> Key: IGNITE-9858
> URL: https://issues.apache.org/jira/browse/IGNITE-9858
>
[jira] [Commented] (IGNITE-10030) [TC Bot] Background upload of changes, problems, and statistics
[ https://issues.apache.org/jira/browse/IGNITE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1194#comment-1194 ] ASF GitHub Bot commented on IGNITE-10030: - dspavlov opened a new pull request #50: IGNITE-10030 Background upload of changes and references to changes URL: https://github.com/apache/ignite-teamcity-bot/pull/50 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [TC Bot] Background upload of changes, problems, and statistics > --- > > Key: IGNITE-10030 > URL: https://issues.apache.org/jira/browse/IGNITE-10030 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Minor > > After the implementation of [IGNITE-9848] load time is still long because of > statistics and changes requires significant time to be loaded > Refs: > BuildChainProcessor#loadTestsAndProblems > TeamcityIgnitedImpl#reloadBuild -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9858:
-
Description:
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}
was:
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}
> [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-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:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9858:
-
Description:
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}
was:
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#.
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}
> [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-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:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9858:
-
Description:
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#.
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}
was:
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.
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}
> [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#.
> 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-10033) Update Grid(Ignite)CacheDatabaseSharedManager according to accepted coding guidelines
[
https://issues.apache.org/jira/browse/IGNITE-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1182#comment-1182
]
ASF GitHub Bot commented on IGNITE-10033:
-
GitHub user Mmuzaf opened a pull request:
https://github.com/apache/ignite/pull/5156
IGNITE-10033: fix logging according coding guidelines
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Mmuzaf/ignite ignite-10033
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5156.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 #5156
commit d771029a29462d4cf0b0f51cab5741f745e5391d
Author: Maxim Muzafarov
Date: 2018-10-27T18:19:42Z
IGNITE-10033: fix logging according coding guidelines
> Update Grid(Ignite)CacheDatabaseSharedManager according to accepted coding
> guidelines
> -
>
> Key: IGNITE-10033
> URL: https://issues.apache.org/jira/browse/IGNITE-10033
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>
> We need to update minor issues according to Apache Ignite coding guidelines
> for {{IgniteCacheDatabaseSharedManager}} and
> {{GridCacheDatabaseSharedManager}} classes:
> * createDataRegionConfiguration method can be removed and simplified
> * startMemoryPolicies rename to startDataRegion
> * output messages format fix code style needed
> * fix format javadoc's
> * missed logging for cleanupCheckpointDirectory, cleanupCheckpointDirectory,
> cleanupWalDirectories
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10033) Update Grid(Ignite)CacheDatabaseSharedManager according to accepted coding guidelines
[
https://issues.apache.org/jira/browse/IGNITE-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10033:
-
Description:
We need to update minor issues according to Apache Ignite coding guidelines for
{{IgniteCacheDatabaseSharedManager}} and {{GridCacheDatabaseSharedManager}}
classes:
* createDataRegionConfiguration method can be removed and simplified
* startMemoryPolicies rename to startDataRegion
* output messages format fix code style needed
* fix format javadoc's
* missed logging for cleanupCheckpointDirectory, cleanupCheckpointDirectory,
cleanupWalDirectories
was:
We need to update minor issues according to Apache Ignite coding guidelines for
{{IgniteCacheDatabaseSharedManager}} and {{GridCacheDatabaseSharedManager}}
classes:
* createDataRegionConfiguration method can be removed and simplified
* startMemoryPolicies rename to startDataRegion
* output messages format fix code style needed
* fix format javadoc's
* make inner classes private
* missed logging for cleanupCheckpointDirectory, cleanupCheckpointDirectory,
cleanupWalDirectories
> Update Grid(Ignite)CacheDatabaseSharedManager according to accepted coding
> guidelines
> -
>
> Key: IGNITE-10033
> URL: https://issues.apache.org/jira/browse/IGNITE-10033
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>
> We need to update minor issues according to Apache Ignite coding guidelines
> for {{IgniteCacheDatabaseSharedManager}} and
> {{GridCacheDatabaseSharedManager}} classes:
> * createDataRegionConfiguration method can be removed and simplified
> * startMemoryPolicies rename to startDataRegion
> * output messages format fix code style needed
> * fix format javadoc's
> * missed logging for cleanupCheckpointDirectory, cleanupCheckpointDirectory,
> cleanupWalDirectories
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10033) Update Grid(Ignite)CacheDatabaseSharedManager according to accepted coding guidelines
Maxim Muzafarov created IGNITE-10033:
Summary: Update Grid(Ignite)CacheDatabaseSharedManager according
to accepted coding guidelines
Key: IGNITE-10033
URL: https://issues.apache.org/jira/browse/IGNITE-10033
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
We need to update minor issues according to Apache Ignite coding guidelines for
{{IgniteCacheDatabaseSharedManager}} and {{GridCacheDatabaseSharedManager}}
classes:
* createDataRegionConfiguration method can be removed and simplified
* startMemoryPolicies rename to startDataRegion
* output messages format fix code style needed
* fix format javadoc's
* make inner classes private
* missed logging for cleanupCheckpointDirectory, cleanupCheckpointDirectory,
cleanupWalDirectories
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10030) [TC Bot] Background upload of changes, problems, and statistics
[ https://issues.apache.org/jira/browse/IGNITE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1170#comment-1170 ] ASF GitHub Bot commented on IGNITE-10030: - asfgit closed pull request #49: IGNITE-10030 Background upload of changes, problems, and stat URL: https://github.com/apache/ignite-teamcity-bot/pull/49 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [TC Bot] Background upload of changes, problems, and statistics > --- > > Key: IGNITE-10030 > URL: https://issues.apache.org/jira/browse/IGNITE-10030 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Minor > > After the implementation of [IGNITE-9848] load time is still long because of > statistics and changes requires significant time to be loaded > Refs: > BuildChainProcessor#loadTestsAndProblems > TeamcityIgnitedImpl#reloadBuild -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10032) Web Agent: Optimize collecting topology from cluster
[ https://issues.apache.org/jira/browse/IGNITE-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1156#comment-1156 ] Alexey Kuznetsov commented on IGNITE-10032: --- [~anovikov], Please review my PR: https://github.com/apache/ignite/pull/5096 > Web Agent: Optimize collecting topology from cluster > > > Key: IGNITE-10032 > URL: https://issues.apache.org/jira/browse/IGNITE-10032 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > In current implementation Web Agent collect every 5 seconds topology via REST > with attributes. But attributes are immutable and can be collected only when > topology changed. > We can cache node IDs and collect lightweight topology on every 5 seconds and > if we detected that topology changed - collect full topology with attributes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10032) Web Agent: Optimize collecting topology from cluster
[ https://issues.apache.org/jira/browse/IGNITE-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1155#comment-1155 ] ASF GitHub Bot commented on IGNITE-10032: - GitHub user akuznetsov-gridgain opened a pull request: https://github.com/apache/ignite/pull/5096 IGNITE-10032 Web Agent: Optimized polling of cluster topology. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10032 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5096.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 #5096 commit 4bd36a24b5588e2cbbfddab838b8b3b4cf11ecd6 Author: Alexey Kuznetsov Date: 2018-10-27T16:15:24Z IGNITE-10032 Web Agent: Optimized polling of cluster topology. > Web Agent: Optimize collecting topology from cluster > > > Key: IGNITE-10032 > URL: https://issues.apache.org/jira/browse/IGNITE-10032 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > In current implementation Web Agent collect every 5 seconds topology via REST > with attributes. But attributes are immutable and can be collected only when > topology changed. > We can cache node IDs and collect lightweight topology on every 5 seconds and > if we detected that topology changed - collect full topology with attributes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10031) REST: Introduce "caches" param for "top" command.
[ https://issues.apache.org/jira/browse/IGNITE-10031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1113#comment-1113 ] Alexey Kuznetsov commented on IGNITE-10031: --- [~anovikov] Please review my PR: https://github.com/apache/ignite/pull/5095 > REST: Introduce "caches" param for "top" command. > - > > Key: IGNITE-10031 > URL: https://issues.apache.org/jira/browse/IGNITE-10031 > Project: Ignite > Issue Type: Improvement > Components: rest >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > We have top command on REST API: > https://apacheignite.readme.io/docs/rest-api#topology > And result of this command also contains short caches info (name, mode & SQL > Schema). > But in situation when node contains thousand caches and hundred nodes and > caches have long names - that will result in a HUGE JSON. > For example, I get 88Mb JSON for cluster of 128 nodes and 6000 caches. > And my application do not need that info about caches, I just need a list of > node IDs. > Lets add one more flag "excludeCaches" as we already have "attr" & "mtr". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10031) REST: Introduce "caches" param for "top" command.
[ https://issues.apache.org/jira/browse/IGNITE-10031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1111#comment-1111 ] ASF GitHub Bot commented on IGNITE-10031: - GitHub user akuznetsov-gridgain opened a pull request: https://github.com/apache/ignite/pull/5095 IGNITE-10031 REST: Added "excludeCaches" parameter for "top" command. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10031 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5095.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 #5095 commit e13c5f6d8b8d11d2a84dc00c1fe8aeff8e450313 Author: Alexey Kuznetsov Date: 2018-10-27T14:47:26Z IGNITE-10031 REST: Added "excludeCaches" parameter for "top" command. > REST: Introduce "caches" param for "top" command. > - > > Key: IGNITE-10031 > URL: https://issues.apache.org/jira/browse/IGNITE-10031 > Project: Ignite > Issue Type: Improvement > Components: rest >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > We have top command on REST API: > https://apacheignite.readme.io/docs/rest-api#topology > And result of this command also contains short caches info (name, mode & SQL > Schema). > But in situation when node contains thousand caches and hundred nodes and > caches have long names - that will result in a HUGE JSON. > For example, I get 88Mb JSON for cluster of 128 nodes and 6000 caches. > And my application do not need that info about caches, I just need a list of > node IDs. > Lets add one more flag "excludeCaches" as we already have "attr" & "mtr". -- 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=1110#comment-1110
]
Alexey Goncharuk commented on IGNITE-9858:
--
[~xtern], I believe the behavior you described is not correct because it breaks
concurrent server and client nodes start using shared VM IP finder.
Can you please elaborate how specifically the race between two nodes happen and
when the check for client node is performed?
We should fix this the root cause because many other tests may be affected by
the same issue.
> [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.
> 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-10030) [TC Bot] Background upload of changes, problems, and statistics
[ https://issues.apache.org/jira/browse/IGNITE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1105#comment-1105 ] ASF GitHub Bot commented on IGNITE-10030: - dspavlov opened a new pull request #49: IGNITE-10030 Background upload of changes, problems, and stat URL: https://github.com/apache/ignite-teamcity-bot/pull/49 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [TC Bot] Background upload of changes, problems, and statistics > --- > > Key: IGNITE-10030 > URL: https://issues.apache.org/jira/browse/IGNITE-10030 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Minor > > After the implementation of [IGNITE-9848] load time is still long because of > statistics and changes requires significant time to be loaded > Refs: > BuildChainProcessor#loadTestsAndProblems > TeamcityIgnitedImpl#reloadBuild -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9884) Some tests are incorrectly muted
[
https://issues.apache.org/jira/browse/IGNITE-9884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1103#comment-1103
]
ASF GitHub Bot commented on IGNITE-9884:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5055
> Some tests are incorrectly muted
>
>
> Key: IGNITE-9884
> URL: https://issues.apache.org/jira/browse/IGNITE-9884
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The following tests pass when unmuted. It looks like the reasons that made
> them fail in the past were somehow resolved by later code changes but tests
> were forgotten to unmute:
> {panel}
> GridCacheStoreManagerDeserializationTest#_testBinaryStream
> IgniteCacheConfigVariationsFullApiTest#_testDeletedEntriesFlag
> IgniteCacheConfigVariationsFullApiTest#_testEvictExpired
> PageIdDistributionTest#_testRealHistory
> GridEventConsumeSelfTest#_testMultithreadedWithNodeRestart
> BPlusTreeSelfTest#_testBenchInvoke
> IgniteClientReconnectMassiveShutdownTest#_testMassiveServersShutdown1
> IgniteClientReconnectMassiveShutdownTest#_testMassiveServersShutdown3
> TcpDiscoveryMultiThreadedTest#_testMultiThreadedServersRestart
> GridServiceProcessorBatchDeploySelfTest#_testDeployAllTopologyChange
> GridServiceProcessorBatchDeploySelfTest#_testDeployAllTopologyChangeFail
> GridServiceProcessorBatchDeploySelfTest#_testCancelAllTopologyChange
> {panel}
> The following tests are muted by renaming (prefixing with underscore,
> {{_test...}}, should use standard muting by known JIRA tickets instead:
> {panel}
> - CacheMvccTransactionsTest#_testNodesRestartNoHang
> should fail with the reference to IGNITE-5935
> - GridCacheAbstractFullApiSelfTest#_testInvokeAllMultithreaded
> should fail with the reference to IGNITE-4380{panel}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9884) Some tests are incorrectly muted
[
https://issues.apache.org/jira/browse/IGNITE-9884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1101#comment-1101
]
Alexey Goncharuk commented on IGNITE-9884:
--
[~oignatenko] I think the timeout is related to an issue that was introduced in
master by the ticket IGNITE-5795 which was later reverted (note the "Failed to
register class" messages in the log). Pulling up the latest master should have
resolved the hang.
Anyway, from my point of view it is good enough to merge, thanks!
> Some tests are incorrectly muted
>
>
> Key: IGNITE-9884
> URL: https://issues.apache.org/jira/browse/IGNITE-9884
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The following tests pass when unmuted. It looks like the reasons that made
> them fail in the past were somehow resolved by later code changes but tests
> were forgotten to unmute:
> {panel}
> GridCacheStoreManagerDeserializationTest#_testBinaryStream
> IgniteCacheConfigVariationsFullApiTest#_testDeletedEntriesFlag
> IgniteCacheConfigVariationsFullApiTest#_testEvictExpired
> PageIdDistributionTest#_testRealHistory
> GridEventConsumeSelfTest#_testMultithreadedWithNodeRestart
> BPlusTreeSelfTest#_testBenchInvoke
> IgniteClientReconnectMassiveShutdownTest#_testMassiveServersShutdown1
> IgniteClientReconnectMassiveShutdownTest#_testMassiveServersShutdown3
> TcpDiscoveryMultiThreadedTest#_testMultiThreadedServersRestart
> GridServiceProcessorBatchDeploySelfTest#_testDeployAllTopologyChange
> GridServiceProcessorBatchDeploySelfTest#_testDeployAllTopologyChangeFail
> GridServiceProcessorBatchDeploySelfTest#_testCancelAllTopologyChange
> {panel}
> The following tests are muted by renaming (prefixing with underscore,
> {{_test...}}, should use standard muting by known JIRA tickets instead:
> {panel}
> - CacheMvccTransactionsTest#_testNodesRestartNoHang
> should fail with the reference to IGNITE-5935
> - GridCacheAbstractFullApiSelfTest#_testInvokeAllMultithreaded
> should fail with the reference to IGNITE-4380{panel}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1097#comment-1097 ] Uday Kale commented on IGNITE-8617: --- [~dpavlov], [~slukyanov] Any actions pending from my side? > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Support for Node discovery using AWS Application ELB. -- 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=1095#comment-1095 ] Ilya Lantukh commented on IGNITE-9558: -- Done. > 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] [Created] (IGNITE-10032) Web Agent: Optimize collecting topology from cluster
Alexey Kuznetsov created IGNITE-10032: - Summary: Web Agent: Optimize collecting topology from cluster Key: IGNITE-10032 URL: https://issues.apache.org/jira/browse/IGNITE-10032 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.8 In current implementation Web Agent collect every 5 seconds topology via REST with attributes. But attributes are immutable and can be collected only when topology changed. We can cache node IDs and collect lightweight topology on every 5 seconds and if we detected that topology changed - collect full topology with attributes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10032) Web Agent: Optimize collecting topology from cluster
[ https://issues.apache.org/jira/browse/IGNITE-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10032: -- Ignite Flags: (was: Docs Required) > Web Agent: Optimize collecting topology from cluster > > > Key: IGNITE-10032 > URL: https://issues.apache.org/jira/browse/IGNITE-10032 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > In current implementation Web Agent collect every 5 seconds topology via REST > with attributes. But attributes are immutable and can be collected only when > topology changed. > We can cache node IDs and collect lightweight topology on every 5 seconds and > if we detected that topology changed - collect full topology with attributes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9682) Update full partition map in parallel
[
https://issues.apache.org/jira/browse/IGNITE-9682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9682:
-
Fix Version/s: 2.8
> Update full partition map in parallel
> -
>
> Key: IGNITE-9682
> URL: https://issues.apache.org/jira/browse/IGNITE-9682
> Project: Ignite
> Issue Type: Improvement
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
>Priority: Major
> Fix For: 2.8
>
>
> I've noticed that we are updating full partition map for each cache
> sequentially and during such update we are unable to run much of other tasks.
> Hence there should be some free threads which we can use for parallel
> updating. Sometimes it takes 20-30 seconds to update a map for 100+ caches
> before rebalancing can even start:
> {noformat}
> [2018-09-24 16:38:49,016][INFO ][sys-#219|#219] Received full message, will
> finish exchange [node=4d6b5921-0a61-4bfa-bf11-b8a1b8332dce,
> resVer=AffinityTopologyVersion [topVer=19, minorTopVer=2]]
> ...
> [2018-09-24 16:39:01,217][INFO ][sys-#219|#219] Finish exchange future
> [startVer=AffinityTopologyVersion [topVer=19, minorTopVer=2],
> resVer=AffinityTopologyVersion [topVer=19, minorTopVer=2], err=null]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9682) Update full partition map in parallel
[
https://issues.apache.org/jira/browse/IGNITE-9682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9682:
-
Ignite Flags: (was: Docs Required)
> Update full partition map in parallel
> -
>
> Key: IGNITE-9682
> URL: https://issues.apache.org/jira/browse/IGNITE-9682
> Project: Ignite
> Issue Type: Improvement
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
>Priority: Major
>
> I've noticed that we are updating full partition map for each cache
> sequentially and during such update we are unable to run much of other tasks.
> Hence there should be some free threads which we can use for parallel
> updating. Sometimes it takes 20-30 seconds to update a map for 100+ caches
> before rebalancing can even start:
> {noformat}
> [2018-09-24 16:38:49,016][INFO ][sys-#219|#219] Received full message, will
> finish exchange [node=4d6b5921-0a61-4bfa-bf11-b8a1b8332dce,
> resVer=AffinityTopologyVersion [topVer=19, minorTopVer=2]]
> ...
> [2018-09-24 16:39:01,217][INFO ][sys-#219|#219] Finish exchange future
> [startVer=AffinityTopologyVersion [topVer=19, minorTopVer=2],
> resVer=AffinityTopologyVersion [topVer=19, minorTopVer=2], err=null]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10031) REST: Introduce "caches" param for "top" command.
[ https://issues.apache.org/jira/browse/IGNITE-10031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10031: -- Description: We have top command on REST API: https://apacheignite.readme.io/docs/rest-api#topology And result of this command also contains short caches info (name, mode & SQL Schema). But in situation when node contains thousand caches and hundred nodes and caches have long names - that will result in a HUGE JSON. For example, I get 88Mb JSON for cluster of 128 nodes and 6000 caches. And my application do not need that info about caches, I just need a list of node IDs. Lets add one more flag "excludeCaches" as we already have "attr" & "mtr". was: We have top command on REST API: https://apacheignite.readme.io/docs/rest-api#topology And result of this command also contains short caches info (name, mode & SQL Schema). But in situation when node contains thousand caches and hundred nodes and caches have long names - that will result in a HUGE JSON. For example, I get 88Mb JSON for cluster of 128 nodes and 6000 caches. And my application do not need that info about caches, I just need a list of node IDs. Lets add one more flag "caches" as we already have "attr" & "mtr". For compatibility reasons I will preserve current behaviour if "caches" flag will not be specified. > REST: Introduce "caches" param for "top" command. > - > > Key: IGNITE-10031 > URL: https://issues.apache.org/jira/browse/IGNITE-10031 > Project: Ignite > Issue Type: Improvement > Components: rest >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > We have top command on REST API: > https://apacheignite.readme.io/docs/rest-api#topology > And result of this command also contains short caches info (name, mode & SQL > Schema). > But in situation when node contains thousand caches and hundred nodes and > caches have long names - that will result in a HUGE JSON. > For example, I get 88Mb JSON for cluster of 128 nodes and 6000 caches. > And my application do not need that info about caches, I just need a list of > node IDs. > Lets add one more flag "excludeCaches" as we already have "attr" & "mtr". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9982) SQLLine: can't run with option --autoCommit=false or true
[
https://issues.apache.org/jira/browse/IGNITE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1060#comment-1060
]
Ignite TC Bot commented on IGNITE-9982:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2174118buildTypeId=IgniteTests24Java8_RunAll]
> SQLLine: can't run with option --autoCommit=false or true
> -
>
> Key: IGNITE-9982
> URL: https://issues.apache.org/jira/browse/IGNITE-9982
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
>
> Trying to run sqlline with additional options
> {code}
> $ /bin/sqlline.sh --autoCommit=false --color=true --outputFormat=csv
> --showNestedErrs=true --showWarnings=true --verbose=true -u
> jdbc:ignite:thin://127.0.0.1:10800
> {code}
> SQLline is working but with exception on start:
> {code}
> issuing: !connect jdbc:ignite:thin://127.0.0.1:10800 '' ''
> org.apache.ignite.IgniteJdbcThinDriver
> Connecting to jdbc:ignite:thin://127.0.0.1:10800
> Connected to: Apache Ignite (version 2.7.1#20181023-sha1:0ccde7c4)
> Driver: Apache Ignite Thin JDBC Driver (version 2.7.1#20181023-sha1:0ccde7c4)
> Error: MVCC must be enabled in order to invoke transactional operation:
> COMMIT (state=25000,code=5002)
> java.sql.SQLException: MVCC must be enabled in order to invoke transactional
> operation: COMMIT
> 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
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.doCommit(JdbcThinConnection.java:369)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.setAutoCommit(JdbcThinConnection.java:328)
> at sqlline.DatabaseConnection.connect(DatabaseConnection.java:178)
> at
> sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:204)
> at sqlline.Commands.connect(Commands.java:1095)
> at sqlline.Commands.connect(Commands.java:1001)
> 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:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:566)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> Transaction isolation: TRANSACTION_REPEATABLE_READ
> {code}
> Without --autoCommit option sqlline running without this exception
--
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=1044#comment-1044 ] Alexey Goncharuk commented on IGNITE-9558: -- [~ilantukh], please merge the latest master, failed to apply your PR on 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-10020) control.sh error: Comparison method violates its general contract!
[ https://issues.apache.org/jira/browse/IGNITE-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1039#comment-1039 ] ASF GitHub Bot commented on IGNITE-10020: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5087 > control.sh error: Comparison method violates its general contract! > -- > > Key: IGNITE-10020 > URL: https://issues.apache.org/jira/browse/IGNITE-10020 > Project: Ignite > Issue Type: Bug >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Fix For: 2.8 > > > ./control.sh --host 192.168.1.1 --cache distribution null > Control utility [ver. 2.5#20181002-sha1:3d28432b] > 2018 Copyright(C) Apache Software Foundation > User: test > > Check arguments. > Error: Comparison method violates its general contract! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10020) control.sh error: Comparison method violates its general contract!
[ https://issues.apache.org/jira/browse/IGNITE-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10020: -- Fix Version/s: 2.8 > control.sh error: Comparison method violates its general contract! > -- > > Key: IGNITE-10020 > URL: https://issues.apache.org/jira/browse/IGNITE-10020 > Project: Ignite > Issue Type: Bug >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Fix For: 2.8 > > > ./control.sh --host 192.168.1.1 --cache distribution null > Control utility [ver. 2.5#20181002-sha1:3d28432b] > 2018 Copyright(C) Apache Software Foundation > User: test > > Check arguments. > Error: Comparison method violates its general contract! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10020) control.sh error: Comparison method violates its general contract!
[ https://issues.apache.org/jira/browse/IGNITE-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1037#comment-1037 ] Alexey Goncharuk commented on IGNITE-10020: --- Thanks, looks good, merged to master. > control.sh error: Comparison method violates its general contract! > -- > > Key: IGNITE-10020 > URL: https://issues.apache.org/jira/browse/IGNITE-10020 > Project: Ignite > Issue Type: Bug >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Fix For: 2.8 > > > ./control.sh --host 192.168.1.1 --cache distribution null > Control utility [ver. 2.5#20181002-sha1:3d28432b] > 2018 Copyright(C) Apache Software Foundation > User: test > > Check arguments. > Error: Comparison method violates its general contract! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10020) control.sh error: Comparison method violates its general contract!
[ https://issues.apache.org/jira/browse/IGNITE-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10020: -- Ignite Flags: (was: Docs Required) > control.sh error: Comparison method violates its general contract! > -- > > Key: IGNITE-10020 > URL: https://issues.apache.org/jira/browse/IGNITE-10020 > Project: Ignite > Issue Type: Bug >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > ./control.sh --host 192.168.1.1 --cache distribution null > Control utility [ver. 2.5#20181002-sha1:3d28432b] > 2018 Copyright(C) Apache Software Foundation > User: test > > Check arguments. > Error: Comparison method violates its general contract! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9418) Avoid initialize file page store manager for caches during PME synchronously
[
https://issues.apache.org/jira/browse/IGNITE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1005#comment-1005
]
Ignite TC Bot commented on IGNITE-9418:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2169790]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
BPlusTreeFakeReuseSelfTest.testTestRandomPutRemoveMultithreaded_1_30_1 - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2169897buildTypeId=IgniteTests24Java8_RunAll]
> Avoid initialize file page store manager for caches during PME synchronously
>
>
> Key: IGNITE-9418
> URL: https://issues.apache.org/jira/browse/IGNITE-9418
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Fix For: 2.8
>
>
> Currently, we do creation for partition and index files during PME for
> starting caches at the beginning of
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#readCheckpointAndRestoreMemory
> method.
> We should avoid this because sometimes it took a long time as we perform
> writing to disk.
> If the cache was registered during PME we should initialize page store lazy
> or asynchronously.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8873) Optimize cache scans with enabled persistence.
[ https://issues.apache.org/jira/browse/IGNITE-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665995#comment-16665995 ] ASF GitHub Bot commented on IGNITE-8873: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5091 > Optimize cache scans with enabled persistence. > -- > > Key: IGNITE-8873 > URL: https://issues.apache.org/jira/browse/IGNITE-8873 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.8 > > > Currently cache scans with enabled persistence involve link resolution, which > can lead to radom disk access resulting in bad performace on SAS disks. > One possibility is to preload cache data pages to remove slow random disk > access. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
