[jira] [Updated] (IGNITE-11036) IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest fail in master
[ https://issues.apache.org/jira/browse/IGNITE-11036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev updated IGNITE-11036: Labels: MakeTeamcityGreenAgain (was: ) > IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest > fail in master > -- > > Key: IGNITE-11036 > URL: https://issues.apache.org/jira/browse/IGNITE-11036 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > Labels: MakeTeamcityGreenAgain > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11036) IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest fail in master
Sergey Kosarev created IGNITE-11036: --- Summary: IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest fail in master Key: IGNITE-11036 URL: https://issues.apache.org/jira/browse/IGNITE-11036 Project: Ignite Issue Type: Bug Reporter: Sergey Kosarev Assignee: Sergey Kosarev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11036) IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest fail in master
[ https://issues.apache.org/jira/browse/IGNITE-11036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev updated IGNITE-11036: Description: On my local environment (Mac OS X) IgniteTcpCommunicationHandshakeWaitSslTest fails in 100% rate. I've investigated and found problem the test overrides TcpDiscoverySpi but does not set ipFinder to the new object. Setting ipFinder solves it. was:On my machine this test fails > IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest > fail in master > -- > > Key: IGNITE-11036 > URL: https://issues.apache.org/jira/browse/IGNITE-11036 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > Labels: MakeTeamcityGreenAgain > > On my local environment (Mac OS X) IgniteTcpCommunicationHandshakeWaitSslTest > fails in 100% rate. > I've investigated and found problem the test overrides TcpDiscoverySpi but > does not set ipFinder to the new object. Setting ipFinder solves it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11036) IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest fail in master
[ https://issues.apache.org/jira/browse/IGNITE-11036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev updated IGNITE-11036: Fix Version/s: 2.8 > IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest > fail in master > -- > > Key: IGNITE-11036 > URL: https://issues.apache.org/jira/browse/IGNITE-11036 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > On my local environment (Mac OS X) IgniteTcpCommunicationHandshakeWaitSslTest > fails in 100% rate. > I've investigated and found problem the test overrides TcpDiscoverySpi but > does not set ipFinder to the new object. Setting ipFinder solves it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11036) IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest fail in master
[ https://issues.apache.org/jira/browse/IGNITE-11036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev updated IGNITE-11036: Affects Version/s: 2.8 > IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest > fail in master > -- > > Key: IGNITE-11036 > URL: https://issues.apache.org/jira/browse/IGNITE-11036 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > On my local environment (Mac OS X) IgniteTcpCommunicationHandshakeWaitSslTest > fails in 100% rate. > I've investigated and found problem the test overrides TcpDiscoverySpi but > does not set ipFinder to the new object. Setting ipFinder solves it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11036) IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest fail in master
[ https://issues.apache.org/jira/browse/IGNITE-11036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev updated IGNITE-11036: Description: On my machine this test fails > IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest > fail in master > -- > > Key: IGNITE-11036 > URL: https://issues.apache.org/jira/browse/IGNITE-11036 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > Labels: MakeTeamcityGreenAgain > > On my machine this test fails -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9879) Web console: split major features to modules - configuration
[
https://issues.apache.org/jira/browse/IGNITE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Borisov updated IGNITE-9879:
-
Remaining Estimate: 48h
Original Estimate: 48h
> Web console: split major features to modules - configuration
>
>
> Key: IGNITE-9879
> URL: https://issues.apache.org/jira/browse/IGNITE-9879
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> The issue:
> 1. _app.js_ is massive, hard to maintain and often a source of various merge
> conflicts.
> 2. Even if some code is de facto separated by feature
> (configuration/queries/admin/profile), no agreement was made on how to
> structure directories, which leads to confusion and app.js growth.
> I propose to:
> 1. Reorganize source code file structure:
> {noformat}
> frontend
> app
> configuration
> queries
> profile
> admin
> common
> {noformat}
> 2. Slim _app.js_ down to something like this:
> {noformat}
> import common from './common'
> import configuration from './configuration'
> import queries from './queries'
> import profile from './profile'
> import admin from './admin'
> export default angular.module('ignite-console', [
> common.name,
> configuration.name,
> queries.name,
> profile.name,
> admin.name
> ])
> {noformat}
> Each directory inside app will follow the same module structure as agreed
> upon before (i.e. components/services/filters, etc).
> 3. In order to test water, update the configuration module first and if
> everything goes as expect proceed with other modules.
> [~kuaw26], [~anovikov] what do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7128) .NET: Add missing DataRegionMetrics
[
https://issues.apache.org/jira/browse/IGNITE-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lev Khenkin reassigned IGNITE-7128:
---
Assignee: Lev Khenkin
> .NET: Add missing DataRegionMetrics
> ---
>
> Key: IGNITE-7128
> URL: https://issues.apache.org/jira/browse/IGNITE-7128
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Lev Khenkin
>Priority: Minor
> Labels: .NET
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See {{DataRegionMetricsParityTest}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9879) Web console: split major features to modules - configuration
[
https://issues.apache.org/jira/browse/IGNITE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Borisov updated IGNITE-9879:
-
Remaining Estimate: 16h (was: 48h)
Original Estimate: 16h (was: 48h)
> Web console: split major features to modules - configuration
>
>
> Key: IGNITE-9879
> URL: https://issues.apache.org/jira/browse/IGNITE-9879
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Original Estimate: 16h
> Remaining Estimate: 16h
>
> The issue:
> 1. _app.js_ is massive, hard to maintain and often a source of various merge
> conflicts.
> 2. Even if some code is de facto separated by feature
> (configuration/queries/admin/profile), no agreement was made on how to
> structure directories, which leads to confusion and app.js growth.
> I propose to:
> 1. Reorganize source code file structure:
> {noformat}
> frontend
> app
> configuration
> queries
> profile
> admin
> common
> {noformat}
> 2. Slim _app.js_ down to something like this:
> {noformat}
> import common from './common'
> import configuration from './configuration'
> import queries from './queries'
> import profile from './profile'
> import admin from './admin'
> export default angular.module('ignite-console', [
> common.name,
> configuration.name,
> queries.name,
> profile.name,
> admin.name
> ])
> {noformat}
> Each directory inside app will follow the same module structure as agreed
> upon before (i.e. components/services/filters, etc).
> 3. In order to test water, update the configuration module first and if
> everything goes as expect proceed with other modules.
> [~kuaw26], [~anovikov] what do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10920) Optimize HistoryAffinityAssignment heap usage.
[
https://issues.apache.org/jira/browse/IGNITE-10920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749621#comment-16749621
]
Ignite TC Bot commented on IGNITE-10920:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2876991buildTypeId=IgniteTests24Java8_RunAll]
> Optimize HistoryAffinityAssignment heap usage.
> --
>
> Key: IGNITE-10920
> URL: https://issues.apache.org/jira/browse/IGNITE-10920
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Konstantin Bolyandra
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With large topology and large amount of caches/partitions many server
> discovery events may quickly produce large affinity history, eating gigabytes
> of heap.
> Solution: implement some kind of a compression for affinity cache map.
> On example, affinity history could be stored as delta to some previous
> version.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10629) Migration follow up: check for old style tests that could be slipped through in transition period
[
https://issues.apache.org/jira/browse/IGNITE-10629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749614#comment-16749614
]
Oleg Ignatenko commented on IGNITE-10629:
-
(i) to address the second part suggested in description, I searched master and
found no classes extending JUnit 3 {{TestCase}} class. These were probably all
cleaned up in prior migration changes.
I performed two checks to search for mentioned classes, one was usage search
and another was search for plain text {{"junit.framework.TestCase"}} string.
Both searches got empty results.
> Migration follow up: check for old style tests that could be slipped through
> in transition period
> -
>
> Key: IGNITE-10629
> URL: https://issues.apache.org/jira/browse/IGNITE-10629
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: junit_inspections.xml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to account for risk that while tests are migrating some commits may
> by mistake slip in old style test cases - that will be ignored by JUnit 4.
> In order to address possible issues of that kind, do the following a week or
> two after IGNITE-10177 is merged to master: run the IntelliJ inspection
> called "old style Junit test method in JUnit 4 class", review report and fix
> discovered problems if there are any.
> For the reference, my version of IDE explains this inspection as follows:
> {quote}Reports JUnit 3 style test methods which are located inside a class
> which does not extend the abstract JUnit 3 class TestCase and contains JUnit
> 4/JUnit 5 @Test annotated methods.{quote}
> (note concerns mentioned in this ticket were originally raised at dev list:
> [here|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-tp29608p39300.html])
> -
> Another part of this task is to find (and rework if there are still any)
> classes that still extend {{junit.framework.TestCase}}. These classes are
> technically legal but after vast majority have been migrated they became
> harmful from maintenance perspective, by forcing readers of their code learn
> details of obsolete framework version that lacks many important features. One
> particularly bad thing about such tests is that they deprive maintainers
> standard ways to suppress test execution using modern JUnit API of Ignore and
> Assume.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10921) Add IGNITE_CONSISTENT_ID system property
[
https://issues.apache.org/jira/browse/IGNITE-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749586#comment-16749586
]
Ignite TC Bot commented on IGNITE-10921:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2876758buildTypeId=IgniteTests24Java8_RunAll]
> Add IGNITE_CONSISTENT_ID system property
>
>
> Key: IGNITE-10921
> URL: https://issues.apache.org/jira/browse/IGNITE-10921
> Project: Ignite
> Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Artur Muradimov
>Priority: Major
> Labels: newbie
>
> IGNITE-10900 explains the benefits of setting consistent ID explicitly and
> suggests adding a warning it isn't. However, currently changing consistentId
> for each node is rather cumbersome if the nodes share the configuration.
> It would be good to add a new system property as a shorthand way to set
> consistent ID.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11033) IllegalStateException in VisorBaselineTask
[ https://issues.apache.org/jira/browse/IGNITE-11033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749399#comment-16749399 ] Vasiliy Sisko edited comment on IGNITE-11033 at 1/23/19 7:27 AM: - Fixed illegal state exception. [~pkonstantinov] Please test saving of baseline topology with missed node. Also test topology restart after save was (Author: vsisko): Fixed illegal state exception. [~pkonstantinov] Please test > IllegalStateException in VisorBaselineTask > -- > > Key: IGNITE-11033 > URL: https://issues.apache.org/jira/browse/IGNITE-11033 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > > Thrown when set command executed. The reason that we throw exception instead > of setting DetachedClusterNode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10961) Web console: add more countries
[ https://issues.apache.org/jira/browse/IGNITE-10961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749589#comment-16749589 ] Ilya Borisov edited comment on IGNITE-10961 at 1/23/19 7:12 AM: As per suggestion in PR, I've changed "Country" field label to "Country/Region" (signup page, user creation by admin, user profile). I've also fixed local e2e runner. [~kuaw26] please review. was (Author: klaster_1): As per suggestion in PR, I've change "Country" field label to "Country/Region" (signup page, user creation by admin, user profile). I've also fixed local e2e runner. [~kuaw26] please review. > Web console: add more countries > --- > > Key: IGNITE-10961 > URL: https://issues.apache.org/jira/browse/IGNITE-10961 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Countries to add: > * Taiwan > * Hong Kong > * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10961) Web console: add more countries
[ https://issues.apache.org/jira/browse/IGNITE-10961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749589#comment-16749589 ] Ilya Borisov commented on IGNITE-10961: --- As per suggestion in PR, I've change "Country" field label to "Country/Region" (signup page, user creation by admin, user profile). I've also fixed local e2e runner. [~kuaw26] please review. > Web console: add more countries > --- > > Key: IGNITE-10961 > URL: https://issues.apache.org/jira/browse/IGNITE-10961 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Countries to add: > * Taiwan > * Hong Kong > * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10961) Web console: add more countries
[ https://issues.apache.org/jira/browse/IGNITE-10961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-10961: - Assignee: Alexey Kuznetsov (was: Ilya Borisov) > Web console: add more countries > --- > > Key: IGNITE-10961 > URL: https://issues.apache.org/jira/browse/IGNITE-10961 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Countries to add: > * Taiwan > * Hong Kong > * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10961) Web console: add more countries
[ https://issues.apache.org/jira/browse/IGNITE-10961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-10961: - Assignee: Ilya Borisov (was: Alexey Kuznetsov) > Web console: add more countries > --- > > Key: IGNITE-10961 > URL: https://issues.apache.org/jira/browse/IGNITE-10961 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Countries to add: > * Taiwan > * Hong Kong > * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[
https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749549#comment-16749549
]
Ignite TC Bot commented on IGNITE-10754:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2869201buildTypeId=IgniteTests24Java8_RunAll]
> Query history statistics API
>
>
> Key: IGNITE-10754
> URL: https://issues.apache.org/jira/browse/IGNITE-10754
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, monitoring
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As of now we have query statistics
> (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues.
> 1) Duration execution it just time between start execution and return cursor
> to client and doesn't include all life time of query.
> 2) It doesn't know about multistatement queries. Such queries participate in
> statistics as single query without splitting.
> 3) API to access the statistics expose as depend on cache, however query
> don't have such dependency.
>
> Need to create parallel similar realization as we already have.
> Use new infrastructure of tracking running queries developed under
> IGNITE-10621 and update statistics on unregister phase.
> Expose API on upper level then it placed now. Right place will be written
> later.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10688) Expose SQL views for ache groups IO statistics
[
https://issues.apache.org/jira/browse/IGNITE-10688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-10688:
---
Summary: Expose SQL views for ache groups IO statistics (was: Expose SQL
views for IO statistics)
> Expose SQL views for ache groups IO statistics
> --
>
> Key: IGNITE-10688
> URL: https://issues.apache.org/jira/browse/IGNITE-10688
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-27
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now no such way to get IO statistics through SQL.
> Need to expose system SQL views to be able view statistics for cache group
> caches.
>
> CACHE_GROUPS_IO
> {quote}group_id - Cache group id
> group_name - Name of cache group
> physical_read - Number of physical read of pages
> logical_read - Number of logical read of pages
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10742) Replace java.io.Console to GridConsole
[ https://issues.apache.org/jira/browse/IGNITE-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749516#comment-16749516 ] ramil commented on IGNITE-10742: Team city Run All https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull/5890/head > Replace java.io.Console to GridConsole > --- > > Key: IGNITE-10742 > URL: https://issues.apache.org/jira/browse/IGNITE-10742 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: ramil >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We should create and use GridConsole instead of java.io.Console because of > using Console in tests impossible. The API of GridConsole must be identical > Console API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749517#comment-16749517 ] Pavel Voronkin commented on IGNITE-10877: - Thanks for your feedback [~ascherbakov], i've resolved them. > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png, image-2019-01-18-11-36-57-451.png, > image-2019-01-18-11-38-39-410.png, image-2019-01-18-11-55-39-496.png, > image-2019-01-18-11-56-10-339.png, image-2019-01-18-11-56-18-040.png, > image-2019-01-18-12-09-04-835.png, image-2019-01-18-12-09-32-876.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10742) Replace java.io.Console to GridConsole
[ https://issues.apache.org/jira/browse/IGNITE-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramil reassigned IGNITE-10742: -- Assignee: ramil > Replace java.io.Console to GridConsole > --- > > Key: IGNITE-10742 > URL: https://issues.apache.org/jira/browse/IGNITE-10742 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: ramil >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We should create and use GridConsole instead of java.io.Console because of > using Console in tests impossible. The API of GridConsole must be identical > Console API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8420) "Unignore" Web console unit tests
[ https://issues.apache.org/jira/browse/IGNITE-8420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8420: Assignee: Alexander Kalinin (was: Ilya Borisov) > "Unignore" Web console unit tests > - > > Key: IGNITE-8420 > URL: https://issues.apache.org/jira/browse/IGNITE-8420 > Project: Ignite > Issue Type: Test > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > Original Estimate: 32h > Time Spent: 10h > Remaining Estimate: 22h > > Currently he have about 40 muted tests in web console front-end. They should > revised, and updated an or removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8420) "Unignore" Web console unit tests
[ https://issues.apache.org/jira/browse/IGNITE-8420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749491#comment-16749491 ] Ilya Borisov commented on IGNITE-8420: -- [~alexdel] can you merge master in and sync the changes between branches? > "Unignore" Web console unit tests > - > > Key: IGNITE-8420 > URL: https://issues.apache.org/jira/browse/IGNITE-8420 > Project: Ignite > Issue Type: Test > Components: wizards >Reporter: Alexander Kalinin >Assignee: Ilya Borisov >Priority: Major > Original Estimate: 32h > Time Spent: 10h > Remaining Estimate: 22h > > Currently he have about 40 muted tests in web console front-end. They should > revised, and updated an or removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11035) Web console: Implemement improvements for query page controller.
Vasiliy Sisko created IGNITE-11035:
--
Summary: Web console: Implemement improvements for query page
controller.
Key: IGNITE-11035
URL: https://issues.apache.org/jira/browse/IGNITE-11035
Project: Ignite
Issue Type: Improvement
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko
# Implement processing of query result task without one level recursion.
# Explicit serialization to JSON of Paragraph object. Possible
{{Paragraph.prototype.toJSON }}{{should be implemented.}}
{{# Try to use RXJS operator chain instead of direct usage of subscription
object.}}
{{# On query cancel task unlock UI in Promise.prototype.finally.}}
{{# Check initialization of queryId and resultNodeId on execute of refresh in
auto refresh mode.}}
{{# Some paragraph manipulation methods should be moved into Paragraph class:
_initQueryResult}}{{{color:#00}_, _showLoading._
{color}}}{{{color:#00}Check other methods with paragraph as
argument.{color}}}
{{{color:#00}# Check clearing of data in _initQueryResult method.
{color}}}{{{color:#00}Try to not use direct calling of grid
API{color}}}{{{color:#00}. Possible we should show
“{color}}}{{{color:#00}Query execution{color}}}{{{color:#00}” stub
{color}}}{{{color:#00}instead. {color}}}
{{{color:#00}# {color}}}{{{color:#00}Remove “beforeunload” listener on
leave of Queries page.{color}}}
{{{color:#00}# Possible we should cancel queries when client session is
over.{color}}}
{{{color:#00}# Add docs for return values of queries task in agent manager.
F.e:{color}}}
{{{color:#00}{code}{color}}}
/*
* @returns \{Promise}
*/
{code}
# Confirm on leaving of Queries page when running queries exist:
{code}
You have running queries. Are you sure you want to cancel them?
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11035) Web console: Implemement improvements for query page controller.
[
https://issues.apache.org/jira/browse/IGNITE-11035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko updated IGNITE-11035:
---
Description:
# Implement processing of query result task without one level recursion.
# Explicit serialization to JSON of Paragraph object. Possible
{{Paragraph.prototype.toJSON should be implemented.}}
# {{Try to use RXJS operator chain instead of direct usage of subscription
object.}}
# {{On query cancel task unlock UI in Promise.prototype.finally.}}
# {{Check initialization of queryId and resultNodeId on execute of refresh in
auto refresh mode.}}
# {{Some paragraph manipulation methods should be moved into Paragraph class:
_initQueryResult}}{{{color:#00}_, _showLoading._
{color}}}{{{color:#00}Check other methods with paragraph as
argument.{color}}}
# {{{color:#00}Check clearing of data in _initQueryResult method.
{color}}}{{{color:#00}Try to not use direct calling of grid
API{color}}}{{{color:#00}. Possible we should show
“{color}}}{{{color:#00}Query execution{color}}}{{{color:#00}” stub
{color}}}{{{color:#00}instead.{color}}}
# {{{color:#00}Remove “beforeunload” listener on leave of Queries
page.{color}}}
# {{{color:#00}Possible we should cancel queries when client session is
over.{color}}}
# {{{color:#00}Add docs for return values of queries task in agent
manager. F.e:{color}}}
{code:java}
/*
@returns {Promise}
*/{code}
# Confirm on leaving of Queries page when running queries exist:
{code:java}
You have running queries. Are you sure you want to cancel them?
{code}
was:
# Implement processing of query result task without one level recursion.
# Explicit serialization to JSON of Paragraph object. Possible
{{Paragraph.prototype.toJSON }}{{should be implemented.}}
{{# Try to use RXJS operator chain instead of direct usage of subscription
object.}}
{{# On query cancel task unlock UI in Promise.prototype.finally.}}
{{# Check initialization of queryId and resultNodeId on execute of refresh in
auto refresh mode.}}
{{# Some paragraph manipulation methods should be moved into Paragraph class:
_initQueryResult}}{{{color:#00}_, _showLoading._
{color}}}{{{color:#00}Check other methods with paragraph as
argument.{color}}}
{{{color:#00}# Check clearing of data in _initQueryResult method.
{color}}}{{{color:#00}Try to not use direct calling of grid
API{color}}}{{{color:#00}. Possible we should show
“{color}}}{{{color:#00}Query execution{color}}}{{{color:#00}” stub
{color}}}{{{color:#00}instead. {color}}}
{{{color:#00}# {color}}}{{{color:#00}Remove “beforeunload” listener on
leave of Queries page.{color}}}
{{{color:#00}# Possible we should cancel queries when client session is
over.{color}}}
{{{color:#00}# Add docs for return values of queries task in agent manager.
F.e:{color}}}
{{{color:#00}{code}{color}}}
/*
* @returns \{Promise}
*/
{code}
# Confirm on leaving of Queries page when running queries exist:
{code}
You have running queries. Are you sure you want to cancel them?
{code}
> Web console: Implemement improvements for query page controller.
>
>
> Key: IGNITE-11035
> URL: https://issues.apache.org/jira/browse/IGNITE-11035
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>Priority: Major
>
> # Implement processing of query result task without one level recursion.
> # Explicit serialization to JSON of Paragraph object. Possible
> {{Paragraph.prototype.toJSON should be implemented.}}
> # {{Try to use RXJS operator chain instead of direct usage of subscription
> object.}}
> # {{On query cancel task unlock UI in Promise.prototype.finally.}}
> # {{Check initialization of queryId and resultNodeId on execute of refresh
> in auto refresh mode.}}
> # {{Some paragraph manipulation methods should be moved into Paragraph
> class: _initQueryResult}}{{{color:#00}_, _showLoading._
> {color}}}{{{color:#00}Check other methods with paragraph as
> argument.{color}}}
> # {{{color:#00}Check clearing of data in _initQueryResult method.
> {color}}}{{{color:#00}Try to not use direct calling of grid
> API{color}}}{{{color:#00}. Possible we should show
> “{color}}}{{{color:#00}Query execution{color}}}{{{color:#00}” stub
> {color}}}{{{color:#00}instead.{color}}}
> # {{{color:#00}Remove “beforeunload” listener on leave of Queries
> page.{color}}}
> # {{{color:#00}Possible we should cancel queries when client session is
> over.{color}}}
> # {{{color:#00}Add docs for return values of queries task in agent
> manager. F.e:{color}}}
> {code:java}
> /*
> @returns {Promise}
> */{code}
> # Confirm on leaving of Queries page when
[jira] [Commented] (IGNITE-10961) Web console: add more countries
[ https://issues.apache.org/jira/browse/IGNITE-10961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749480#comment-16749480 ] Ilya Borisov commented on IGNITE-10961: --- [~ysergeev] done. > Web console: add more countries > --- > > Key: IGNITE-10961 > URL: https://issues.apache.org/jira/browse/IGNITE-10961 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Countries to add: > * Taiwan > * Hong Kong > * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11034) Web console: update some dependencies
Ilya Borisov created IGNITE-11034: - Summary: Web console: update some dependencies Key: IGNITE-11034 URL: https://issues.apache.org/jira/browse/IGNITE-11034 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Alexander Kalinin We need to update: 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module loading. 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11033) IllegalStateException in VisorBaselineTask
[ https://issues.apache.org/jira/browse/IGNITE-11033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-11033: -- Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > IllegalStateException in VisorBaselineTask > -- > > Key: IGNITE-11033 > URL: https://issues.apache.org/jira/browse/IGNITE-11033 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > > Thrown when set command executed. The reason that we throw exception instead > of setting DetachedClusterNode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11033) IllegalStateException in VisorBaselineTask
[ https://issues.apache.org/jira/browse/IGNITE-11033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749399#comment-16749399 ] Vasiliy Sisko edited comment on IGNITE-11033 at 1/23/19 2:28 AM: - Fixed illegal state exception. [~pkonstantinov] Please test was (Author: vsisko): Fixed illegal state exception. > IllegalStateException in VisorBaselineTask > -- > > Key: IGNITE-11033 > URL: https://issues.apache.org/jira/browse/IGNITE-11033 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > > Thrown when set command executed. The reason that we throw exception instead > of setting DetachedClusterNode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11033) IllegalStateException in VisorBaselineTask
Vasiliy Sisko created IGNITE-11033: -- Summary: IllegalStateException in VisorBaselineTask Key: IGNITE-11033 URL: https://issues.apache.org/jira/browse/IGNITE-11033 Project: Ignite Issue Type: Bug Components: wizards Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko Fix For: 2.8 Thrown when set command executed. The reason that we throw exception instead of setting DetachedClusterNode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10921) Add IGNITE_CONSISTENT_ID system property
[ https://issues.apache.org/jira/browse/IGNITE-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749266#comment-16749266 ] Artur Muradimov commented on IGNITE-10921: -- I have a fix for this issue - look at my PR. TC should by finished soon. https://ci.ignite.apache.org/viewLog.html?buildId=2876758=IgniteTests24Java8_RunAll > Add IGNITE_CONSISTENT_ID system property > > > Key: IGNITE-10921 > URL: https://issues.apache.org/jira/browse/IGNITE-10921 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Artur Muradimov >Priority: Major > Labels: newbie > > IGNITE-10900 explains the benefits of setting consistent ID explicitly and > suggests adding a warning it isn't. However, currently changing consistentId > for each node is rather cumbersome if the nodes share the configuration. > It would be good to add a new system property as a shorthand way to set > consistent ID. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7128) .NET: Add missing DataRegionMetrics
[
https://issues.apache.org/jira/browse/IGNITE-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749213#comment-16749213
]
Ignite TC Bot commented on IGNITE-7128:
---
{panel:title=- Run :: .NET: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *- Run :: .NET*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2875157buildTypeId=IgniteTests24Java8_RunAllNet]
> .NET: Add missing DataRegionMetrics
> ---
>
> Key: IGNITE-7128
> URL: https://issues.apache.org/jira/browse/IGNITE-7128
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See {{DataRegionMetricsParityTest}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10688) Expose SQL views for IO statistics
[
https://issues.apache.org/jira/browse/IGNITE-10688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749136#comment-16749136
]
Ignite TC Bot commented on IGNITE-10688:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2833015buildTypeId=IgniteTests24Java8_RunAll]
> Expose SQL views for IO statistics
> --
>
> Key: IGNITE-10688
> URL: https://issues.apache.org/jira/browse/IGNITE-10688
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-27
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now no such way to get IO statistics through SQL.
> Need to expose system SQL views to be able view statistics for cache group
> caches.
>
> CACHE_GROUPS_IO
> {quote}group_id - Cache group id
> group_name - Name of cache group
> physical_read - Number of physical read of pages
> logical_read - Number of logical read of pages
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10347) Expose system SQL view for running queries
[
https://issues.apache.org/jira/browse/IGNITE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749135#comment-16749135
]
Ignite TC Bot commented on IGNITE-10347:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2868810buildTypeId=IgniteTests24Java8_RunAll]
> Expose system SQL view for running queries
> --
>
> Key: IGNITE-10347
> URL: https://issues.apache.org/jira/browse/IGNITE-10347
> Project: Ignite
> Issue Type: Task
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, sql
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose system SQL view to provide list of running queries. Proposed
> name is *running_queries* with following columns: query_id, node_id, sql,
> schema_name, duration.
> Where,
> query_id - cluster unique id of query with format \{node_order_id}
> {X}
> {node_qry_cntr}, both node_order_id and node_qry_cntr encoded to HEX. X - 'X'
> letter used as separator.
> node_id - id of node where query was started
> sql - sql command
> schema_name - SQL schema name
> duration - time in ms from start of execution of query
>
> The view should contains all kind of running queries from RunningQueryManager
> on local node
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10160) Add cluster wide unique identifier for running queries
[
https://issues.apache.org/jira/browse/IGNITE-10160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749134#comment-16749134
]
Ignite TC Bot commented on IGNITE-10160:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2860177buildTypeId=IgniteTests24Java8_RunAll]
> Add cluster wide unique identifier for running queries
> --
>
> Key: IGNITE-10160
> URL: https://issues.apache.org/jira/browse/IGNITE-10160
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Each of execution query should have unique identifier for whole cluster. It
> should be \{node_order_id}{X}\{node_qry_cntr}
> where
> node_order_id - node order id where query was started.
> X - letter 'X' used as separator.
> node_qry_cntr - local node query counter.
>
> both node_order_id and node_qry_cntr encoded to HEX.
>
> Example of such id - a1fXbc71d
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7128) .NET: Add missing DataRegionMetrics
[
https://issues.apache.org/jira/browse/IGNITE-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749133#comment-16749133
]
Lev Khenkin commented on IGNITE-7128:
-
Hi! I've done PR with fix, but cannot assign jira to me :( Please, add me
rights.
> .NET: Add missing DataRegionMetrics
> ---
>
> Key: IGNITE-7128
> URL: https://issues.apache.org/jira/browse/IGNITE-7128
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See {{DataRegionMetricsParityTest}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[
https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749104#comment-16749104
]
Ignite TC Bot commented on IGNITE-10754:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=2872600]]
* IgniteBinaryCacheQueryTestSuite: RunningQueriesTest.testQueries - 0,0% fails
in last 345 master runs.
* IgniteBinaryCacheQueryTestSuite: RunningQueriesTest.testJdbcBatchDML - 0,0%
fails in last 345 master runs.
* IgniteBinaryCacheQueryTestSuite: RunningQueriesTest.testJdbcStreamBatchUpdate
- 0,0% fails in last 345 master runs.
* IgniteBinaryCacheQueryTestSuite: RunningQueriesTest.testMultiStatement - 0,0%
fails in last 345 master runs.
* IgniteBinaryCacheQueryTestSuite: RunningQueriesTest.testCopyCommand - 0,0%
fails in last 345 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2869201buildTypeId=IgniteTests24Java8_RunAll]
> Query history statistics API
>
>
> Key: IGNITE-10754
> URL: https://issues.apache.org/jira/browse/IGNITE-10754
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, monitoring
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As of now we have query statistics
> (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues.
> 1) Duration execution it just time between start execution and return cursor
> to client and doesn't include all life time of query.
> 2) It doesn't know about multistatement queries. Such queries participate in
> statistics as single query without splitting.
> 3) API to access the statistics expose as depend on cache, however query
> don't have such dependency.
>
> Need to create parallel similar realization as we already have.
> Use new infrastructure of tracking running queries developed under
> IGNITE-10621 and update statistics on unregister phase.
> Expose API on upper level then it placed now. Right place will be written
> later.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10920) Optimize HistoryAffinityAssignment heap usage.
[ https://issues.apache.org/jira/browse/IGNITE-10920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Bolyandra reassigned IGNITE-10920: - Assignee: Konstantin Bolyandra > Optimize HistoryAffinityAssignment heap usage. > -- > > Key: IGNITE-10920 > URL: https://issues.apache.org/jira/browse/IGNITE-10920 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Konstantin Bolyandra >Priority: Major > > With large topology and large amount of caches/partitions many server > discovery events may quickly produce large affinity history, eating gigabytes > of heap. > Solution: implement some kind of a compression for affinity cache map. > On example, affinity history could be stored as delta to some previous > version. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11032) Typescript for Node.js Client
[ https://issues.apache.org/jira/browse/IGNITE-11032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Havlik updated IGNITE-11032: --- Description: So I've started doing this today. My goal is to complete this work quickly so it has a good chance of being merged. I've found it difficult to find whoever the right person would be to get started on this. [https://github.com/thavlik/ignite] Note that I can't get the tests to run because my computer is having issues running Ignite locally, and I have no intention of moving the tests to Typescript. Only the imports for the tests will be changing. Also, I am removing all default exports as per its numerous caveats: [https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad] Edit: I am able to confirm the Typescript client is a working drop-in replacement for my app after changing the imports. was: So I've started doing this today. My goal is to complete this work quickly so it has a good chance of being merged. I've found it difficult to find whoever the right person would be to get started on this. [https://github.com/thavlik/ignite] Note that I can't get the tests to run because my computer is having issues running Ignite locally, and I have no intention of moving the tests to Typescript. Only the imports for the tests will be changing. Also, I am removing all default exports as per its numerous caveats: [https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad] > Typescript for Node.js Client > - > > Key: IGNITE-11032 > URL: https://issues.apache.org/jira/browse/IGNITE-11032 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Thomas Havlik >Priority: Major > > So I've started doing this today. My goal is to complete this work quickly so > it has a good chance of being merged. I've found it difficult to find whoever > the right person would be to get started on this. > [https://github.com/thavlik/ignite] > Note that I can't get the tests to run because my computer is having issues > running Ignite locally, and I have no intention of moving the tests to > Typescript. Only the imports for the tests will be changing. > Also, I am removing all default exports as per its numerous caveats: > [https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad] > Edit: I am able to confirm the Typescript client is a working drop-in > replacement for my app after changing the imports. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11032) Typescript for Node.js Client
Thomas Havlik created IGNITE-11032: -- Summary: Typescript for Node.js Client Key: IGNITE-11032 URL: https://issues.apache.org/jira/browse/IGNITE-11032 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Thomas Havlik So I've started doing this today. My goal is to complete this work quickly so it has a good chance of being merged. I've found it difficult to find whoever the right person would be to get started on this. [https://github.com/thavlik/ignite] Note that I can't get the tests to run because my computer is having issues running Ignite locally, and I have no intention of moving the tests to Typescript. Only the imports for the tests will be changing. Also, I am removing all default exports as per its numerous caveats: [https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11031) Improve test coverage on ssl and fix existing ssl tcp communication spi tests.
Pavel Voronkin created IGNITE-11031: --- Summary: Improve test coverage on ssl and fix existing ssl tcp communication spi tests. Key: IGNITE-11031 URL: https://issues.apache.org/jira/browse/IGNITE-11031 Project: Ignite Issue Type: Improvement Reporter: Pavel Voronkin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10921) Add IGNITE_CONSISTENT_ID system property
[ https://issues.apache.org/jira/browse/IGNITE-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artur Muradimov reassigned IGNITE-10921: Assignee: Artur Muradimov > Add IGNITE_CONSISTENT_ID system property > > > Key: IGNITE-10921 > URL: https://issues.apache.org/jira/browse/IGNITE-10921 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Artur Muradimov >Priority: Major > Labels: newbie > > IGNITE-10900 explains the benefits of setting consistent ID explicitly and > suggests adding a warning it isn't. However, currently changing consistentId > for each node is rather cumbersome if the nodes share the configuration. > It would be good to add a new system property as a shorthand way to set > consistent ID. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11030) Teamcity Bot cache is in unrecoverable state after bot restart: need to check reasons
Dmitriy Pavlov created IGNITE-11030:
---
Summary: Teamcity Bot cache is in unrecoverable state after bot
restart: need to check reasons
Key: IGNITE-11030
URL: https://issues.apache.org/jira/browse/IGNITE-11030
Project: Ignite
Issue Type: Task
Reporter: Dmitriy Pavlov
- TC Bot was stopped with kill command (default signal).
- Shutdown hook calls ignite close
But after updating to V190122 TC Bot DB was became unrecoverable for
"teamcityTestRunHist" cache with exception
{noformat}
Failure periodic check failed: javax.cache.CacheException: class
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
Runtime failure on lookup row: SearchRow
[key=org.apache.ignite.ci.teamcity.ignited.runhist.RunHistKey
[idHash=1028871081, hash=1241170874, srvId=1411517106, testOrSuiteName=11924,
branch=281], hash=1241170874, cacheId=0]
com.google.common.util.concurrent.UncheckedExecutionException:
javax.cache.CacheException: class
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
Runtime failure on lookup row: SearchRow
[key=org.apache.ignite.ci.teamcity.ignited.runhist.RunHistKey
[idHash=1028871081, hash=1241170874, srvId=1411517106, testOrSuiteName=11924,
branch=281], hash=1241170874, cacheId=0]
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2050)
at com.google.common.cache.LocalCache.get(LocalCache.java:3952)
at
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4871)
at
org.apache.ignite.ci.di.cache.GuavaCachedInterceptor.invoke(GuavaCachedInterceptor.java:59)
at
org.apache.ignite.ci.teamcity.ignited.TeamcityIgnitedImpl.getTestRunHist(TeamcityIgnitedImpl.java:404)
at
org.apache.ignite.ci.di.AutoProfilingInterceptor.invoke(AutoProfilingInterceptor.java:76)
at
org.apache.ignite.ci.web.model.current.SuiteCurrentStatus.lambda$initFromContext$0(SuiteCurrentStatus.java:155)
at java.util.Comparator.lambda$comparing$77a9974f$1(Comparator.java:469)
at
java.util.Collections$ReverseComparator2.compare(Collections.java:5178)
at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355)
at java.util.TimSort.sort(TimSort.java:220)
at java.util.Arrays.sort(Arrays.java:1512)
at java.util.ArrayList.sort(ArrayList.java:1462)
at
org.apache.ignite.ci.web.model.current.SuiteCurrentStatus.initFromContext(SuiteCurrentStatus.java:160)
at
org.apache.ignite.ci.web.model.current.ChainAtServerCurrentStatus.lambda$initFromContext$0(ChainAtServerCurrentStatus.java:171)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.apache.ignite.ci.web.model.current.ChainAtServerCurrentStatus.initFromContext(ChainAtServerCurrentStatus.java:167)
at
org.apache.ignite.ci.tcbot.chain.TrackedBranchChainsProcessor.lambda$getTrackedBranchTestFailures$1(TrackedBranchChainsProcessor.java:121)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.apache.ignite.ci.tcbot.chain.TrackedBranchChainsProcessor.getTrackedBranchTestFailures(TrackedBranchChainsProcessor.java:125)
at
org.apache.ignite.ci.di.AutoProfilingInterceptor.invoke(AutoProfilingInterceptor.java:76)
at
org.apache.ignite.ci.tcbot.issue.IssueDetector.checkFailuresEx(IssueDetector.java:445)
at
[jira] [Assigned] (IGNITE-10742) Replace java.io.Console to GridConsole
[ https://issues.apache.org/jira/browse/IGNITE-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov reassigned IGNITE-10742: --- Assignee: (was: Sergey Antonov) > Replace java.io.Console to GridConsole > --- > > Key: IGNITE-10742 > URL: https://issues.apache.org/jira/browse/IGNITE-10742 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > We should create and use GridConsole instead of java.io.Console because of > using Console in tests impossible. The API of GridConsole must be identical > Console API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10520) MVCC: Next to mvcc-tx non-mvcc-Tx failed with unexpected exception.
[ https://issues.apache.org/jira/browse/IGNITE-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748848#comment-16748848 ] Andrew Mashenkov commented on IGNITE-10520: --- [~Pavlukhin], Look ok. Thanks. > MVCC: Next to mvcc-tx non-mvcc-Tx failed with unexpected exception. > --- > > Key: IGNITE-10520 > URL: https://issues.apache.org/jira/browse/IGNITE-10520 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Ivan Pavlukhin >Priority: Critical > Labels: mvcc_stabilization_stage_1, transactions > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > IgniteCachePrimarySyncTest.testPutGet) failed. > It run tx operations one by one > # tx on Transactional cache > # tx on Transactional_snapshot cache. > # tx on Transactional cache > Last tx failed with "TransactionException: Only pessimistic repeatable read > transactions are supported when MVCC is enabled." which is unexpected. > Looks like we forget to reset tx context somewhere. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10996) [ML] Add additional host and port into IgniteDataset to retrieve schema
[ https://issues.apache.org/jira/browse/IGNITE-10996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748843#comment-16748843 ] Anton Dmitriev commented on IGNITE-10996: - PR has been approved and merged into tensorflow/io repository. > [ML] Add additional host and port into IgniteDataset to retrieve schema > --- > > Key: IGNITE-10996 > URL: https://issues.apache.org/jira/browse/IGNITE-10996 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Anton Dmitriev >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > Currently > [IgniteDataset|https://github.com/tensorflow/io/tree/master/tensorflow_io/ignite#distributed-in-memory-datasource] > provides ability to specify only a single host/port for data schema > extraction and for data loading. This limitation doesn't allow to use > [Dataset.interleave(...)|https://www.tensorflow.org/api_docs/python/tf/data/Dataset#interleave] > and > [tf.data.experimental.parallel_interleave|https://www.tensorflow.org/api_docs/python/tf/data/experimental/parallel_interleave] > function for parallel data loading. > We need to add ability to specify host/port separately for schema extraction > and to data loading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10855) Performance problems while running SQL query involving JOINS and ORDER BY eventually leading to heap OOME.
[ https://issues.apache.org/jira/browse/IGNITE-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gourav Agrawal updated IGNITE-10855: Summary: Performance problems while running SQL query involving JOINS and ORDER BY eventually leading to heap OOME. (was: Delayed execution when running SQL query involving JOINS and ORDER BY eventually leading to heap OOME.) > Performance problems while running SQL query involving JOINS and ORDER BY > eventually leading to heap OOME. > -- > > Key: IGNITE-10855 > URL: https://issues.apache.org/jira/browse/IGNITE-10855 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Gourav Agrawal >Priority: Blocker > Fix For: None > > > To simplify our use-case, we created two caches using the SQL query and > loaded data consisting of about 4 million records and 60k records > approximately, in the respective caches with INDEX created on all the > columns. Ignite is set up to run on a single node, meaning all the data is > present on the same node. The query used for testing/the one we are facing > issue with is of the type - > _SELECT * FROM CACHE1 C1, CACHE2 C2 WHERE C1.JOINCol = C2.JOINCol AND > C1.COL1 = 'someValue' ORDER BY C1.COL2_ > The above query execution leads to the Ignite thread memory rising > extensively, eventually leading to heap OOME. When the heap memory was > increased to about 14GB, we were able to get the results back, but the > processing time of the query was too long, about 2-4 minutes ( with CPUs =2). > We ran an EXPLAIN for the above query and found out that INDEX was created on > COL1 for C1 cache and on JOINCol for C2 cache. There was no index on the > sorted column. We think the problem of 'slow querying and huge heap memory > requirement' is because of the absence of an index in the sorted column. > Whenever there is a condition present in the WHERE clause ( in our example > C1.COL1='someValue'), Ignite is using an INDEX for that column and there is > no INDEX being created on the ORDER BY column. > And for our use-case, it is imperative that we have a condition in the where > clause ( to filter out the data) and a join condition apart from the order by > clause. > We tried the multiple column indexing strategy on the COL1, COL2 as per our > use case. > In case of a composite index with the order as (COL1, COL2), INDEX was > created only for the COL1. > While for the composite index order as (COL2, COL1), INDEX was getting > created for both COL1 and COL2 and the results were index sorted. ( But only > in case of the absence of an INDEX for COL1, it looks for the ORDER BY clause > column and uses a composite index). But, if we don't have a separate INDEX > for COL1, it again poses a problem as COL1 is something which is heavily used > for filtering in all other queries. So an INDEX on COL1 is necessary. > To summarize, In case there is a condition present in the WHERE clause, > Ignite uses the WHERE clause column for indexing, and therefore there is no > INDEX in the sorting column, resulting in severe query performance, which can > eventually lead us to our system going down. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10855) Performance problems while running SQL query involving JOINS and ORDER BY eventually leading to heap OOME.
[ https://issues.apache.org/jira/browse/IGNITE-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748814#comment-16748814 ] Gourav Agrawal commented on IGNITE-10855: - Any updates? > Performance problems while running SQL query involving JOINS and ORDER BY > eventually leading to heap OOME. > -- > > Key: IGNITE-10855 > URL: https://issues.apache.org/jira/browse/IGNITE-10855 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Gourav Agrawal >Priority: Blocker > Fix For: None > > > To simplify our use-case, we created two caches using the SQL query and > loaded data consisting of about 4 million records and 60k records > approximately, in the respective caches with INDEX created on all the > columns. Ignite is set up to run on a single node, meaning all the data is > present on the same node. The query used for testing/the one we are facing > issue with is of the type - > _SELECT * FROM CACHE1 C1, CACHE2 C2 WHERE C1.JOINCol = C2.JOINCol AND > C1.COL1 = 'someValue' ORDER BY C1.COL2_ > The above query execution leads to the Ignite thread memory rising > extensively, eventually leading to heap OOME. When the heap memory was > increased to about 14GB, we were able to get the results back, but the > processing time of the query was too long, about 2-4 minutes ( with CPUs =2). > We ran an EXPLAIN for the above query and found out that INDEX was created on > COL1 for C1 cache and on JOINCol for C2 cache. There was no index on the > sorted column. We think the problem of 'slow querying and huge heap memory > requirement' is because of the absence of an index in the sorted column. > Whenever there is a condition present in the WHERE clause ( in our example > C1.COL1='someValue'), Ignite is using an INDEX for that column and there is > no INDEX being created on the ORDER BY column. > And for our use-case, it is imperative that we have a condition in the where > clause ( to filter out the data) and a join condition apart from the order by > clause. > We tried the multiple column indexing strategy on the COL1, COL2 as per our > use case. > In case of a composite index with the order as (COL1, COL2), INDEX was > created only for the COL1. > While for the composite index order as (COL2, COL1), INDEX was getting > created for both COL1 and COL2 and the results were index sorted. ( But only > in case of the absence of an INDEX for COL1, it looks for the ORDER BY clause > column and uses a composite index). But, if we don't have a separate INDEX > for COL1, it again poses a problem as COL1 is something which is heavily used > for filtering in all other queries. So an INDEX on COL1 is necessary. > To summarize, In case there is a condition present in the WHERE clause, > Ignite uses the WHERE clause column for indexing, and therefore there is no > INDEX in the sorting column, resulting in severe query performance, which can > eventually lead us to our system going down. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10978) Remove unused tests marked with unclear todo
[
https://issues.apache.org/jira/browse/IGNITE-10978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748805#comment-16748805
]
Konstantin Bolyandra commented on IGNITE-10978:
---
[~ilyak]
Classes did not contain test cases and have been removed:
# GridCacheOnCopyFlagTxPartitionedSelfTest
# GridCacheOnCopyFlagReplicatedSelfTest
# GridCacheOnCopyFlagLocalSelfTest
# GridCacheOnCopyFlagAtomicSelfTest
*GridCacheDeploymentSelfTest* - Class is removed according to issue reporter
suggestion "these tests were testing peer class loading for cache entry
(key/value). This case is not to be supported in the nearest future".
*GridCacheDeploymentOffHeapSelfTest* - Class file is absent already.
*GridCacheDeploymentOffHeapValuesSelfTest* - Class file is absent already.
> Remove unused tests marked with unclear todo
>
>
> Key: IGNITE-10978
> URL: https://issues.apache.org/jira/browse/IGNITE-10978
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Dmitriy Pavlov
>Assignee: Konstantin Bolyandra
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> IgniteCacheTestSuite3
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapValuesSelfTest.class,
> ignoredTests);
> IgniteCacheInterceptorSelfTestSuite
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class,
> ignoredTests);
> {noformat}
> Test classes not used, so there is no reason to keep it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10520) MVCC: Next to mvcc-tx non-mvcc-Tx failed with unexpected exception.
[ https://issues.apache.org/jira/browse/IGNITE-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748799#comment-16748799 ] Ivan Pavlukhin commented on IGNITE-10520: - [~amashenkov] Could you please take a look at the patch? I disabled the mentioned test in forced MVCC mode. > MVCC: Next to mvcc-tx non-mvcc-Tx failed with unexpected exception. > --- > > Key: IGNITE-10520 > URL: https://issues.apache.org/jira/browse/IGNITE-10520 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Ivan Pavlukhin >Priority: Critical > Labels: mvcc_stabilization_stage_1, transactions > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > IgniteCachePrimarySyncTest.testPutGet) failed. > It run tx operations one by one > # tx on Transactional cache > # tx on Transactional_snapshot cache. > # tx on Transactional cache > Last tx failed with "TransactionException: Only pessimistic repeatable read > transactions are supported when MVCC is enabled." which is unexpected. > Looks like we forget to reset tx context somewhere. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10933) Node may hang on join to topology and not move forward
[
https://issues.apache.org/jira/browse/IGNITE-10933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748797#comment-16748797
]
Yakov Zhdanov commented on IGNITE-10933:
Changes look good to me
> Node may hang on join to topology and not move forward
> --
>
> Key: IGNITE-10933
> URL: https://issues.apache.org/jira/browse/IGNITE-10933
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Alexei Scherbakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Several nodes join to topology simultaneously and hang on a long time.
> That can be on first start all cluster nodes or join nodes to completed
> topology.
> In the logs of problem nodes can see messages:
> {noformat}
> 2019-01-11 18:37:39.296 [WARN ][Thread-56][o.a.i.s.d.tcp.TcpDiscoverySpi]
> Node has not been connected to topology and will repeat join process. Check
> remote nodes logs for possible error messages. Note that large topology may
> require sig
> nificant time to start. Increase 'TcpDiscoverySpi.networkTimeout'
> configuration property if getting this message on the starting nodes
> [networkTimeout=5000]
> 2019-01-11 18:43:09.374 [WARN ][Thread-56][o.a.i.s.d.tcp.TcpDiscoverySpi]
> Node has not been connected to topology and will repeat join process. Check
> remote nodes logs for possible error messages. Note that large topology may
> require sig
> nificant time to start. Increase 'TcpDiscoverySpi.networkTimeout'
> configuration property if getting this message on the starting nodes
> [networkTimeout=5000]
> ...
> {noformat}
> and so for a long time without others.
> UPDATE: such behavior is caused by transferring
> TcpDiscoveryClientReconnectMessage stored in pending objects collection to
> joining node causing socket connection invalidation to joining node and
> marking it as failed.
> Reproduced by the following scenario:
> 1. Create topology in specific order: srv1 srv2 client srv3 srv4
> 2. Delay client reconnect.
> 3. Trigger topology change by restarting srv2 (will trigger reconnect to next
> node), srv3, srv4
> 4. Resume reconnect to node with empty EnsuredMessageHistory (triggering
> discovery message of type TcpDiscoveryClientReconnectMessage) and wait for
> completion.
> 5. Add new node to topology.
> New node will fail with assertion or forever will stuck on join depending on
> timings.
> Same scenario could be probably triggered by temporary connection loss to
> joining node.
> [~v.pyatkov], thanks for help with the investigation.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11029) Public API for edge-chasing deadlock detection configuration
[
https://issues.apache.org/jira/browse/IGNITE-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin reassigned IGNITE-11029:
---
Assignee: Ivan Pavlukhin
> Public API for edge-chasing deadlock detection configuration
>
>
> Key: IGNITE-11029
> URL: https://issues.apache.org/jira/browse/IGNITE-11029
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> As deadlock detection introduce overhead during transaction processing some
> configuration means should be introduced. Following aspects should be
> addressed:
> 1. Turning detection on/off.
> 2. Adjusting a timeout before starting actual detection.
> It is proposed to introduce single property in {{TransactionConfiguration}}
> to address both concerns.
> Also configuration should achieve following goals:
> 1. Be the same for every node in cluster.
> 2. Be configurable in run time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
[
https://issues.apache.org/jira/browse/IGNITE-10645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748781#comment-16748781
]
Ignite TC Bot commented on IGNITE-10645:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2869956]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySegmentationAndConnectionRestoreTest.testSegmentation2 - 0,0%
fails in last 76 master runs.
{color:#d04437}Cache (Restarts) 1{color} [[tests
13|https://ci.ignite.apache.org/viewLog.html?buildId=2869979]]
* IgniteCacheRestartTestSuite: GridCachePartitionedNodeRestartTest.testRestart
- 0,0% fails in last 575 master runs.
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithPutTwoNodesNoBackups - 0,0%
fails in last 575 master runs.
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithTxTwoNodesOneBackup - 0,0%
fails in last 575 master runs.
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithPutTwoNodesOneBackup - 0,0%
fails in last 575 master runs.
{color:#d04437}MVCC Queries{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2869967]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlTxQueriesTest.testAccountsTxDmlSql_SingleNode_Persistence
- 0,0% fails in last 620 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2870033buildTypeId=IgniteTests24Java8_RunAll]
> SQL properties ownership flag should be set at configuration parsing, not
> query execution.
> --
>
> Key: IGNITE-10645
> URL: https://issues.apache.org/jira/browse/IGNITE-10645
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> At processing time, query entities are transformed and validated, table
> descriptors with properties are created.
> Now in some case (thre's no keyFields and key is of complex non-sql type),
> ownership flag of query property is calculated at execution time (for example
> at first put()):
> https://github.com/apache/ignite/blob/dcdb27a24a450f63487290360b265e1570534629/modules/core/src/main/java/org/apache/ignite/internal/processors/query/property/QueryBinaryProperty.java#L132
> So we can't access metadata, that uses this not-yet-initialized field before
> we put the data.
> But we already have all necessary info to set this field at processing time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11029) Public API for edge-chasing deadlock detection configuration
[
https://issues.apache.org/jira/browse/IGNITE-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11029:
Description:
As deadlock detection introduce overhead during transaction processing some
configuration means should be introduced. Following aspects should be addressed:
1. Turning detection on/off.
2. Adjusting a timeout before starting actual detection.
It is proposed to introduce single property in {{TransactionConfiguration}} to
address both concerns.
Also configuration should achieve following goals:
1. Be the same for every node in cluster.
2. Be configurable in run time.
was:
As deadlock detection introduce overhead during transaction processing some
configuration means should be introduced. Following aspects should be addressed:
1. Turning detection on/off.
2. Adjusting a timeout before starting actual detection.
It is proposed to introduce single property in {{TransactionConfiguration}} to
address both items.
> Public API for edge-chasing deadlock detection configuration
>
>
> Key: IGNITE-11029
> URL: https://issues.apache.org/jira/browse/IGNITE-11029
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> As deadlock detection introduce overhead during transaction processing some
> configuration means should be introduced. Following aspects should be
> addressed:
> 1. Turning detection on/off.
> 2. Adjusting a timeout before starting actual detection.
> It is proposed to introduce single property in {{TransactionConfiguration}}
> to address both concerns.
> Also configuration should achieve following goals:
> 1. Be the same for every node in cluster.
> 2. Be configurable in run time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11029) Public API for edge-chasing deadlock detection configuration
Ivan Pavlukhin created IGNITE-11029:
---
Summary: Public API for edge-chasing deadlock detection
configuration
Key: IGNITE-11029
URL: https://issues.apache.org/jira/browse/IGNITE-11029
Project: Ignite
Issue Type: Task
Components: mvcc
Reporter: Ivan Pavlukhin
Fix For: 2.8
As deadlock detection introduce overhead during transaction processing some
configuration means should be introduced. Following aspects should be addressed:
1. Turning detection on/off.
2. Adjusting a timeout before starting actual detection.
It is proposed to introduce single property in {{TransactionConfiguration}} to
address both items.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10688) Expose SQL views for IO statistics
[
https://issues.apache.org/jira/browse/IGNITE-10688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-10688:
---
Description:
As of now no such way to get IO statistics through SQL.
Need to expose system SQL views to be able view statistics for cache group
caches.
CACHE_GROUPS_IO
{quote}group_id - Cache group id
group_name - Name of cache group
physical_read - Number of physical read of pages
logical_read - Number of logical read of pages
{quote}
was:
As of now no such way to get IO statistics through SQL.
Need to expose two system SQL views to be able view statistics for indexes and
cache group caches.
1) STATIO_CACHE_GRP
{quote}cache_grp_name - Name of cache group
physical_read - Number of physical read of pages
logical_read - Number of logical read of pages{quote}
2) STATIO_IDX
{quote}cache_grp_name - Name of cache group{quote}
{quote}idx_name - Name of index
physical_read - Common number of physical reads of pages for the
index
logical_read - Common number of logical reads of pages for the
index{quote}
{quote}leaf_logical_read - Number of logical reads of index leaf
pages{quote}
{quote}leaf_physical_read - Number of physical reads of index leaf
pages{quote}
{quote}inner_logical_read - Number of logical reads of index inner
pages{quote}
{quote}inner_physical_read - Number of physical reads of index leaf
pages{quote}
> Expose SQL views for IO statistics
> --
>
> Key: IGNITE-10688
> URL: https://issues.apache.org/jira/browse/IGNITE-10688
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-27
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now no such way to get IO statistics through SQL.
> Need to expose system SQL views to be able view statistics for cache group
> caches.
>
> CACHE_GROUPS_IO
> {quote}group_id - Cache group id
> group_name - Name of cache group
> physical_read - Number of physical read of pages
> logical_read - Number of logical read of pages
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10873) CorruptedTreeException during simultaneous cache put operations
[
https://issues.apache.org/jira/browse/IGNITE-10873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev reassigned IGNITE-10873:
Assignee: Ilya Kasnacheev
> CorruptedTreeException during simultaneous cache put operations
> ---
>
> Key: IGNITE-10873
> URL: https://issues.apache.org/jira/browse/IGNITE-10873
> Project: Ignite
> Issue Type: Bug
> Components: cache, persistence, sql
>Affects Versions: 2.7
>Reporter: Pavel Vinokurov
>Assignee: Ilya Kasnacheev
>Priority: Critical
>
> {code}
> [2019-01-09 20:47:04,376][ERROR][pool-9-thread-9][GridDhtAtomicCache]
> Unexpected exception during cache update
> org.h2.message.DbException: General error: "class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on row: Row@780acfb4[ key: .. ][ GTEST, null, 254, null,
> null, null, null, 0, null, null, null, null, null, null, null, 0, 0, 0, null,
> 0, 0, 0, 0, 0, 0, 0, null, 0, 0, null, 0, null, 0, null, 0, null, null, null,
> 0, 0, 0, 0, 0, 0, null, null, null, null, null, null, null, 0.0, 0, 0.0, 0,
> 0.0, 0, null, 0, 0, 0, 0, null, null, null, null, null, null, null, null,
> null, null, null, null, null, null, null, null ]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:302)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:546)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:479)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:768)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1905)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:404)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2633)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1646)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1621)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1935)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:428)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2295)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2494)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1951)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1780)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1153)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:611)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2449)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2426)
> at
>
[jira] [Updated] (IGNITE-9455) Total allocated size memory metric is always zero for metastore data region.
[ https://issues.apache.org/jira/browse/IGNITE-9455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9455: -- Labels: jmx (was: ) > Total allocated size memory metric is always zero for metastore data region. > > > Key: IGNITE-9455 > URL: https://issues.apache.org/jira/browse/IGNITE-9455 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: jmx > Fix For: 2.8 > > Attachments: Reproducer.java > > > Persistence enabled and metrics for all regions enabled, but total allocated > size is always zero for metastore data region > Even if we change NO_OP allocated page tracker to a real page tracker in > CacheStoreHolder this metric counts incorrectly, because this region is > recreated, > Reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10688) Expose SQL views for IO statistics
[
https://issues.apache.org/jira/browse/IGNITE-10688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748741#comment-16748741
]
Yury Gerzhedovich commented on IGNITE-10688:
[~vozerov],
# Yes, 'statio' prefix used by postgres. But I've changed name of the view to
suggested by you CACHE_GROUPS_IO.
# Rename CACHE_GRP_NAME column to GROUP_NAME and add new GROUP_ID.
# Yes, it is so. Added corresponded test.
# Ok, removed view for indexes.
If I right understood your note, you mean GROUP_ID name for column instead of
GROUP_NAME.
> Expose SQL views for IO statistics
> --
>
> Key: IGNITE-10688
> URL: https://issues.apache.org/jira/browse/IGNITE-10688
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-27
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now no such way to get IO statistics through SQL.
> Need to expose two system SQL views to be able view statistics for indexes
> and cache group caches.
>
> 1) STATIO_CACHE_GRP
> {quote}cache_grp_name - Name of cache group
> physical_read - Number of physical read of pages
> logical_read - Number of logical read of pages{quote}
> 2) STATIO_IDX
> {quote}cache_grp_name - Name of cache group{quote}
> {quote}idx_name - Name of index
> physical_read - Common number of physical reads of pages for
> the index
> logical_read - Common number of logical reads of pages for
> the index{quote}
> {quote}leaf_logical_read - Number of logical reads of index leaf
> pages{quote}
> {quote}leaf_physical_read - Number of physical reads of index leaf
> pages{quote}
> {quote}inner_logical_read - Number of logical reads of index inner
> pages{quote}
> {quote}inner_physical_read - Number of physical reads of index leaf
> pages{quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11009) TX: TransactionProxyRollbackOnlyImpl throws unexpected exceptions to user.
[ https://issues.apache.org/jira/browse/IGNITE-11009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11009: -- Ignite Flags: (was: Docs Required) > TX: TransactionProxyRollbackOnlyImpl throws unexpected exceptions to user. > -- > > Key: IGNITE-11009 > URL: https://issues.apache.org/jira/browse/IGNITE-11009 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Priority: Major > > TransactionProxyRollbackOnlyImpl can throws UnsupportedOperationException to > user. > It is ok if objects throws such exception if someones tries to violate > contract, > but seems user can faced this exception within normal flow. > See TxRollbackAsyncTest.testRollbackProxy(). > Let's fix implementation to throw correct TransactionException to user. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10944) Plugin discovery data from PluginProvider.provideDiscoveryData should be available in PluginProvider.validateNewNode
[ https://issues.apache.org/jira/browse/IGNITE-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748731#comment-16748731 ] Ilya Kasnacheev commented on IGNITE-10944: -- [~mcherkasov] please rebase on top of master. I have started tests. > Plugin discovery data from PluginProvider.provideDiscoveryData should be > available in PluginProvider.validateNewNode > > > Key: IGNITE-10944 > URL: https://issues.apache.org/jira/browse/IGNITE-10944 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > *Current sequence:* > > 1)Server starts (coordinator) > 2)Client starts > 3)Client sends to the coordinator its discovery data using > *provideDiscoveryData* method > 4)Coordinator start validation of the node using *validateNewNode* > 5)The client joins the cluster; otherwise fails > 6)Coordinator provides the discovery data to plugin provider in > *receiveDiscoveryData.* After that this data could be passed to the plugin. > But in case if we require to validate new node using the discovery data from > *receiveDiscoveryData* method then we should add a possibility to get this > data in *validateNewNode* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10833) Web Console: Implement query cancel
[ https://issues.apache.org/jira/browse/IGNITE-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-10833. --- Resolution: Duplicate > Web Console: Implement query cancel > --- > > Key: IGNITE-10833 > URL: https://issues.apache.org/jira/browse/IGNITE-10833 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > Web Console lacks query cancel functionality. > Lets add this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10833) Web Console: Implement query cancel
[ https://issues.apache.org/jira/browse/IGNITE-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10833: -- Ignite Flags: (was: Docs Required) > Web Console: Implement query cancel > --- > > Key: IGNITE-10833 > URL: https://issues.apache.org/jira/browse/IGNITE-10833 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > Web Console lacks query cancel functionality. > Lets add this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-10833) Web Console: Implement query cancel
[ https://issues.apache.org/jira/browse/IGNITE-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-10833. - > Web Console: Implement query cancel > --- > > Key: IGNITE-10833 > URL: https://issues.apache.org/jira/browse/IGNITE-10833 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > Web Console lacks query cancel functionality. > Lets add this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10833) Web Console: Implement query cancel
[ https://issues.apache.org/jira/browse/IGNITE-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10833: -- Fix Version/s: (was: 2.8) > Web Console: Implement query cancel > --- > > Key: IGNITE-10833 > URL: https://issues.apache.org/jira/browse/IGNITE-10833 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > Web Console lacks query cancel functionality. > Lets add this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores
[
https://issues.apache.org/jira/browse/IGNITE-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov reassigned IGNITE-10874:
Assignee: Pavel Kuznetsov
> JDBC thin driver metadata misses caches with queryEntities and names
> containing underscores
> ---
>
> Key: IGNITE-10874
> URL: https://issues.apache.org/jira/browse/IGNITE-10874
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc
>Affects Versions: 2.7
>Reporter: Alexey Kukushkin
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> +*Steps to reproduce*+
> 1) Build and run this app:
> {code:java}
> public class App {
> public static void main(String[] ags) {
> try (Ignite ignite = Ignition.start(
> new IgniteConfiguration()
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(
> new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
> )
> )
> )) {
> final String NAME = "V_MODELS_SHORT";
> ignite.getOrCreateCache(
> new CacheConfiguration<>()
> .setName(NAME)
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setQueryEntities(Collections.singleton(
> new QueryEntity()
> .setKeyType(Integer.class.getTypeName())
> .setValueType(NAME)
> .setKeyFieldName("VMS_ID")
> .setFields(
> Stream.of(
> new AbstractMap.SimpleEntry<>("VMS_ID",
> Integer.class.getTypeName()),
> new
> AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
> ).collect(Collectors.toMap(
> AbstractMap.SimpleEntry::getKey,
> AbstractMap.SimpleEntry::getValue,
> (u, v) -> {
> throw new
> IllegalStateException(String.format("Duplicate key %s", u));
> },
> LinkedHashMap::new
> ))
> )
> ))
> );
> System.in.read();
> }
> }
> }
> {code}
> 2) While the app is running use a JDBC database management tool like DBeaver
> to open a JDBC thin driver connection to Ignite.
> 3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Expected*+
> 3) Table "V_MODELS_SHORT" is visible under schema "V_MODELS_SHORT"
> +*Actual*+
> 3) There is no table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Notes*+
> You still can run queries on table V_MODELS_SHORT in DBeaver. For example,
> these queries work fine:
> {code:java}
> INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');
> SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-6564: Component/s: general > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Sergey Kosarev >Priority: Minor > Labels: iep-6 > Fix For: 2.8 > > Time Spent: 1h > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev resolved IGNITE-6564. - Resolution: Fixed Fix Version/s: 2.8 > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Sergey Kosarev >Priority: Minor > Labels: iep-6 > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748709#comment-16748709 ] Ilya Kasnacheev commented on IGNITE-6564: - Thank you for your contribution! I have merged it to master. > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Sergey Kosarev >Priority: Minor > Labels: iep-6 > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10520) MVCC: Next to mvcc-tx non-mvcc-Tx failed with unexpected exception.
[ https://issues.apache.org/jira/browse/IGNITE-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748706#comment-16748706 ] Andrew Mashenkov commented on IGNITE-10520: --- There is no need to run test in ForceMvcc mode. This should be fixed. The original issue was that checkPutGet(ignite.cache(TX_CACHE)...) always failed if it had called right after checkPutGet(ignite.cache(MVCC_CACHE),...) Seems, it has already been fixed within some another ticket. > MVCC: Next to mvcc-tx non-mvcc-Tx failed with unexpected exception. > --- > > Key: IGNITE-10520 > URL: https://issues.apache.org/jira/browse/IGNITE-10520 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Ivan Pavlukhin >Priority: Critical > Labels: mvcc_stabilization_stage_1, transactions > Fix For: 2.8 > > > IgniteCachePrimarySyncTest.testPutGet) failed. > It run tx operations one by one > # tx on Transactional cache > # tx on Transactional_snapshot cache. > # tx on Transactional cache > Last tx failed with "TransactionException: Only pessimistic repeatable read > transactions are supported when MVCC is enabled." which is unexpected. > Looks like we forget to reset tx context somewhere. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[
https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748693#comment-16748693
]
Ignite TC Bot commented on IGNITE-6564:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2868685buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect calculation size and keySize for cluster cache metrics
>
>
> Key: IGNITE-6564
> URL: https://issues.apache.org/jira/browse/IGNITE-6564
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Ilya Kasnacheev
>Assignee: Sergey Kosarev
>Priority: Minor
> Labels: iep-6
> Time Spent: 50m
> Remaining Estimate: 0h
>
> They are currently not passed by ring and therefore only taken from current
> node, which returns incorrect (local) value.
> See CacheMetricsSnapshot class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10699) Update documentation for control.sh
[
https://issues.apache.org/jira/browse/IGNITE-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-10699:
Description:
I renamed view parameters in control.sh utility. The changes are following:
||Was||Has been||
|--skipZeros|--skip-zeros|
|--cacheFilter|--cache-filter|
|checkFirst|--check-first|
|checkThrough|--check-through|
|limit| --limit|
|order|--order|
|servers|--servers|
|clients|--clients|
|minDuration|--min-duration|
|minSize|--min-size|
|label|--label|
|nodes|--nodes|
|xid|--xid|
|kill|--kill|
|groups|--groups|
|seq|--seq|
You could find current output command {{control.sh --cache help}}
{noformat}
Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
2018 Copyright(C) Apache Software Foundation
User: santonov
The '--cache subcommand' is used to get information about and perform actions
with caches. The command has the following syntax:
control.sh [[--host HOST_OR_IP], [--port PORT], [--user USER], [--password
PASSWORD], [--ping-interval PING_INTERVAL], [--ping-timeout PING_TIMEOUT],
[--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ..., SSL_PROTOCOL_N]],
[--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ..., SSL_CIPHER_N]],
[--ssl-key-algorithm SSL_KEY_ALGORITHM], [--keystore-type KEYSTORE_TYPE],
[--keystore KEYSTORE_PATH], [--keystore-password KEYSTORE_PASSWORD],
[--truststore-type TRUSTSTORE_TYPE], [--truststore TRUSTSTORE_PATH],
[--truststore-password TRUSTSTORE_PASSWORD]] --cache[subcommand]
The subcommands that take [nodeId] as an argument ('list', 'contention' and
'validate_indexes') will be executed on the given node or on all server nodes
if the option is not specified. Other commands will run on a random server node.
Subcommands:
--cache list regexPattern [groups|seq] [nodeId] [--config] [--output-format
multi-line]
Show information about caches, groups or sequences that match a regular
expression. When executed without parameters, this subcommand prints the list
of caches.
Parameters:
--config - print a all configuration parameters for each cache.
--output-format multi-line - print configuration parameters per line. This
option has effect only when used with --config and without [groups|seq].
--cache contention minQueueSize [nodeId] [maxPrint]
Show the keys that are point of contention for multiple transactions.
--cache idle_verify [--dump] [--skip-zeros] [cache1,...,cacheN] [--cache-filter
ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT]
Verify counters and hash sums of primary and backup partitions for the
specified caches on an idle cluster and print out the differences, if any.
--cache validate_indexes [cache1,...,cacheN] [nodeId] [--check-first
N|--check-through K]
Validate indexes on an idle cluster and print out the keys that are missing in
the indexes.
Parameters:
--check-first N - validate only the first N keys
--check-through K - validate every Kth key
--cache distribution nodeId|null [cacheName1,...,cacheNameN] [--user-attributes
attrName1,...,attrNameN]
Prints the information about partition distribution.
--cache reset_lost_partitions cacheName1,...,cacheNameN
Reset the state of lost partitions for the specified caches.{noformat}
And {{control.sh --help}}
{noformat}
Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
2018 Copyright(C) Apache Software Foundation
User: santonov
Contol.sh is used to execute admin commands on cluster or get common cluster
info. The command has the following syntax:
control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
[--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...]] [--ssl-cipher-suites
SSL_CIPHER_1[, SSL_CIPHER_2, ...]] [--ssl-key-algorithm SSL_KEY_ALGORITHM]
[--keystore-type KEYSTORE_TYPE] [--keystore KEYSTORE] [--keystore-password
KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
TRUSTSTORE] [--truststore-password TRUSTSTORE_PASSWORD] [command]
This utility can do the following commands:
Activate cluster:
control.sh --activate
Deactivate cluster:
control.sh --deactivate [--yes]
Print current cluster state:
control.sh --state
Print cluster baseline topology:
control.sh --baseline
Add nodes into baseline
[jira] [Updated] (IGNITE-11028) [ML] Flaky test(KeepBinaryTest)
[ https://issues.apache.org/jira/browse/IGNITE-11028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-11028: Ignite Flags: (was: Docs Required) > [ML] Flaky test(KeepBinaryTest) > --- > > Key: IGNITE-11028 > URL: https://issues.apache.org/jira/browse/IGNITE-11028 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Yury Babak >Assignee: Yury Babak >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11028) [ML] Flaky test(KeepBinaryTest)
[ https://issues.apache.org/jira/browse/IGNITE-11028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-11028: Fix Version/s: 2.8 > [ML] Flaky test(KeepBinaryTest) > --- > > Key: IGNITE-11028 > URL: https://issues.apache.org/jira/browse/IGNITE-11028 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Yury Babak >Assignee: Yury Babak >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11028) [ML] Flaky test(KeepBinaryTest)
Yury Babak created IGNITE-11028: --- Summary: [ML] Flaky test(KeepBinaryTest) Key: IGNITE-11028 URL: https://issues.apache.org/jira/browse/IGNITE-11028 Project: Ignite Issue Type: Bug Components: ml Reporter: Yury Babak Assignee: Yury Babak -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores
[
https://issues.apache.org/jira/browse/IGNITE-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16738822#comment-16738822
]
Pavel Kuznetsov edited comment on IGNITE-10874 at 1/22/19 12:38 PM:
This issue seems to be "brother" of odbc ticket IGNITE-10009
So we need to search patterns like
{noformat}
MY\_TABLE
and
MY\%TABLE
{noformat}
to match '_' and '%' literally, not as wildcards.
was (Author: pkouznet):
This issue seems to be "brother" of odbc ticket IGNITE-10009
So we need search patterns like
{noformat}
MY\_TABLE
and
MY\%TABLE
{noformat}
to match '_' and '%' literally, not as wildcards.
> JDBC thin driver metadata misses caches with queryEntities and names
> containing underscores
> ---
>
> Key: IGNITE-10874
> URL: https://issues.apache.org/jira/browse/IGNITE-10874
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc
>Affects Versions: 2.7
>Reporter: Alexey Kukushkin
>Priority: Major
>
> +*Steps to reproduce*+
> 1) Build and run this app:
> {code:java}
> public class App {
> public static void main(String[] ags) {
> try (Ignite ignite = Ignition.start(
> new IgniteConfiguration()
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(
> new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
> )
> )
> )) {
> final String NAME = "V_MODELS_SHORT";
> ignite.getOrCreateCache(
> new CacheConfiguration<>()
> .setName(NAME)
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setQueryEntities(Collections.singleton(
> new QueryEntity()
> .setKeyType(Integer.class.getTypeName())
> .setValueType(NAME)
> .setKeyFieldName("VMS_ID")
> .setFields(
> Stream.of(
> new AbstractMap.SimpleEntry<>("VMS_ID",
> Integer.class.getTypeName()),
> new
> AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
> ).collect(Collectors.toMap(
> AbstractMap.SimpleEntry::getKey,
> AbstractMap.SimpleEntry::getValue,
> (u, v) -> {
> throw new
> IllegalStateException(String.format("Duplicate key %s", u));
> },
> LinkedHashMap::new
> ))
> )
> ))
> );
> System.in.read();
> }
> }
> }
> {code}
> 2) While the app is running use a JDBC database management tool like DBeaver
> to open a JDBC thin driver connection to Ignite.
> 3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Expected*+
> 3) Table "V_MODELS_SHORT" is visible under schema "V_MODELS_SHORT"
> +*Actual*+
> 3) There is no table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Notes*+
> You still can run queries on table V_MODELS_SHORT in DBeaver. For example,
> these queries work fine:
> {code:java}
> INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');
> SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10520) MVCC: Next to mvcc-tx non-mvcc-Tx failed with unexpected exception.
[
https://issues.apache.org/jira/browse/IGNITE-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748682#comment-16748682
]
Ivan Pavlukhin edited comment on IGNITE-10520 at 1/22/19 12:44 PM:
---
[~amashenkov] could you double check that ticket is relevant? Test contains
code:
{code:java}
checkPutGet(ignite.cache(TX_CACHE), ignite.transactions(), OPTIMISTIC,
REPEATABLE_READ);
{code}
and it is not surprise that it fails in {{FORCE_MVCC}} mode.
was (Author: pavlukhin):
[~amashenkov] could you double check that ticket is relevant? Test contains
code:
{code}
checkPutGet(ignite.cache(TX_CACHE), ignite.transactions(), OPTIMISTIC,
REPEATABLE_READ);
{code}
and it is not surprise that it fails in {{FORCE_MVCC}} mode.
> MVCC: Next to mvcc-tx non-mvcc-Tx failed with unexpected exception.
> ---
>
> Key: IGNITE-10520
> URL: https://issues.apache.org/jira/browse/IGNITE-10520
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Ivan Pavlukhin
>Priority: Critical
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> IgniteCachePrimarySyncTest.testPutGet) failed.
> It run tx operations one by one
> # tx on Transactional cache
> # tx on Transactional_snapshot cache.
> # tx on Transactional cache
> Last tx failed with "TransactionException: Only pessimistic repeatable read
> transactions are supported when MVCC is enabled." which is unexpected.
> Looks like we forget to reset tx context somewhere.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10520) MVCC: Next to mvcc-tx non-mvcc-Tx failed with unexpected exception.
[
https://issues.apache.org/jira/browse/IGNITE-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748682#comment-16748682
]
Ivan Pavlukhin commented on IGNITE-10520:
-
[~amashenkov] could you double check that ticket is relevant? Test contains
code:
{code}
checkPutGet(ignite.cache(TX_CACHE), ignite.transactions(), OPTIMISTIC,
REPEATABLE_READ);
{code}
and it is not surprise that it fails in {{FORCE_MVCC}} mode.
> MVCC: Next to mvcc-tx non-mvcc-Tx failed with unexpected exception.
> ---
>
> Key: IGNITE-10520
> URL: https://issues.apache.org/jira/browse/IGNITE-10520
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Ivan Pavlukhin
>Priority: Critical
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> IgniteCachePrimarySyncTest.testPutGet) failed.
> It run tx operations one by one
> # tx on Transactional cache
> # tx on Transactional_snapshot cache.
> # tx on Transactional cache
> Last tx failed with "TransactionException: Only pessimistic repeatable read
> transactions are supported when MVCC is enabled." which is unexpected.
> Looks like we forget to reset tx context somewhere.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11027) CPP: Add support of compact footer for C++
Igor Sapego created IGNITE-11027: Summary: CPP: Add support of compact footer for C++ Key: IGNITE-11027 URL: https://issues.apache.org/jira/browse/IGNITE-11027 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.7 Reporter: Igor Sapego Currently, compact footers are not supported by Ignite C++ and C++ thin clients. As they both share the same library - binary, we can add this support for both C++ thin and Ignite C++ at the same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10755) MVCC: Flaky continuous query tests
[
https://issues.apache.org/jira/browse/IGNITE-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748669#comment-16748669
]
Ignite TC Bot commented on IGNITE-10755:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2861304buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Flaky continuous query tests
> --
>
> Key: IGNITE-10755
> URL: https://issues.apache.org/jira/browse/IGNITE-10755
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, MakeTeamcityGreenAgain, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some continuous query tests are flaky when MVCC is enabled:
> * {{CacheContinuousQueryConcurrentPartitionUpdateTest}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTxCacheGroup}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTx}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[
https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748663#comment-16748663
]
Ignite TC Bot commented on IGNITE-6564:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 2{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2868632]]
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutTenNodesTwoBackups
- 0,0% fails in last 623 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups
- 0,0% fails in last 623 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxPutAllTenNodesTwoBackups
- 0,0% fails in last 623 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2868685buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect calculation size and keySize for cluster cache metrics
>
>
> Key: IGNITE-6564
> URL: https://issues.apache.org/jira/browse/IGNITE-6564
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Ilya Kasnacheev
>Assignee: Sergey Kosarev
>Priority: Minor
> Labels: iep-6
> Time Spent: 50m
> Remaining Estimate: 0h
>
> They are currently not passed by ring and therefore only taken from current
> node, which returns incorrect (local) value.
> See CacheMetricsSnapshot class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10559) MVCC TX: Use extracted partitions to reduce target nodes for Query Update
[
https://issues.apache.org/jira/browse/IGNITE-10559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748652#comment-16748652
]
Ignite TC Bot commented on IGNITE-10559:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2859637buildTypeId=IgniteTests24Java8_RunAll]
> MVCC TX: Use extracted partitions to reduce target nodes for Query Update
> -
>
> Key: IGNITE-10559
> URL: https://issues.apache.org/jira/browse/IGNITE-10559
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Igor Seliverstov
>Assignee: Taras Ledkov
>Priority: Minor
> Labels: iep-24
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We may avoid "query reduce" step on update queries without sorting/grouping
> by simply sending them to all data nodes and executing update operation
> locally. Using extracted from SQL partitions will reduce target nodes count
> and save resources.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11026) Support TcpCommunicationSpi.NeedWaitDelay, TcpCommunicationSpi.MaxNeedWaitDelay.
Pavel Voronkin created IGNITE-11026: --- Summary: Support TcpCommunicationSpi.NeedWaitDelay, TcpCommunicationSpi.MaxNeedWaitDelay. Key: IGNITE-11026 URL: https://issues.apache.org/jira/browse/IGNITE-11026 Project: Ignite Issue Type: Improvement Reporter: Pavel Voronkin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11026) Support TcpCommunicationSpi.NeedWaitDelay, TcpCommunicationSpi.MaxNeedWaitDelay in .NET.
[ https://issues.apache.org/jira/browse/IGNITE-11026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-11026: Summary: Support TcpCommunicationSpi.NeedWaitDelay, TcpCommunicationSpi.MaxNeedWaitDelay in .NET. (was: Support TcpCommunicationSpi.NeedWaitDelay, TcpCommunicationSpi.MaxNeedWaitDelay.) > Support TcpCommunicationSpi.NeedWaitDelay, > TcpCommunicationSpi.MaxNeedWaitDelay in .NET. > > > Key: IGNITE-11026 > URL: https://issues.apache.org/jira/browse/IGNITE-11026 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10998) Option --check-crc is not shown in help for control.sh
[ https://issues.apache.org/jira/browse/IGNITE-10998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748647#comment-16748647 ] Ivan Bessonov commented on IGNITE-10998: [~antonovsergey93] code looks good, thank you! > Option --check-crc is not shown in help for control.sh > -- > > Key: IGNITE-10998 > URL: https://issues.apache.org/jira/browse/IGNITE-10998 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Alex Volkov >Assignee: Sergey Antonov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > After implementing IGNITE-10507 it seems like this option (--check-crc) is > not shown in help for control.sh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11016) RecoveryLastReceivedMessage(NEED_WAIT) fails with "Failed to encrypt data (SSL engine error)".
[
https://issues.apache.org/jira/browse/IGNITE-11016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Voronkin reassigned IGNITE-11016:
---
Assignee: Pavel Voronkin
> RecoveryLastReceivedMessage(NEED_WAIT) fails with "Failed to encrypt data
> (SSL engine error)".
> --
>
> Key: IGNITE-11016
> URL: https://issues.apache.org/jira/browse/IGNITE-11016
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
> Attachments: IgniteClientConnectSslTest.java
>
>
> Problem:
> In case of initiator node haven't joined topology yet (doesn't exist in
> DiscoCache, but exists in TcpDsicovery ring)
> we are writing back new RecoveryLastReceivedMessage(NEED_WAIT)) in the below
> else clause:
> if (unknownNode)
> { U.warn(log, "Close incoming connection, unknown node [nodeId=" + sndId + ",
> ses=" + ses + ']'); ses.close(); }
> else {
> ses.send(new RecoveryLastReceivedMessage(NEED_WAIT)).listen(new
> CI1>() {
> @Override public void apply(IgniteInternalFuture fut)
> { ses.close(); }
> });
> }
> In case of SSL such code do encrypt and send concurrently with
> session.close() which results in exception:
> javax.net.ssl.SSLException: Failed to encrypt data (SSL engine error)
> [status=CLOSED, handshakeStatus=NEED_UNWRAP, ses=GridSelectorNioSessionImpl
> [worker=GridWorker [name=grid-nio-worker-tcp-comm-10,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> hashCode=1324367867, interrupted=false,
> runner=grid-nio-worker-tcp-comm-10-#130%DPL_GRID%DplGridNodeName%|#130%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
> [idx=10, bytesRcvd=121406754, bytesSent=0, bytesRcvd0=16659, bytesSent0=0,
> select=true, super=]DirectNioClientWorker [super=],
> writeBuf=java.nio.DirectByteBuffer[pos=0 lim=10 cap=32768],
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
> inRecovery=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/10.116.69.208:47100, rmtAddr=/10.53.15.23:55380,
> createTime=1544502852482, closeTime=0, bytesSent=4076, bytesRcvd=4346,
> bytesSent0=4076, bytesRcvd0=4346, sndSchedTime=1544502852522,
> lastSndTime=1544502852522, lastRcvTime=1544502852522, readsPaused=false,
> filterChain=FilterChain[filters=[, GridConnectionBytesVerifyFilter, SSL
> filter], accepted=true, markedForClose=true]]]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.encrypt(GridNioSslHandler.java:380)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.encrypt(GridNioSslFilter.java:270)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processWriteSsl(GridNioServer.java:1465)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processWrite(GridNioServer.java:1326)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2374)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2138)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1792)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
>
> So initiator receive closed exception instead of NEED_WAIT message which
> leads to exception scenario.
> As result instead of NEED_WAIT loop we retry with exception N times and fail.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11023) Processing data bag on GridMarshallerMappingProcessor consume many time
[
https://issues.apache.org/jira/browse/IGNITE-11023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-11023:
--
Assignee: Vladislav Pyatkov
> Processing data bag on GridMarshallerMappingProcessor consume many time
> ---
>
> Key: IGNITE-11023
> URL: https://issues.apache.org/jira/browse/IGNITE-11023
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> I have measure a processing data bag time on each join node and discovered
> what GridMarshallerMappingProcessor consume more time then others.
> It slow down on collecting topology, in particular case if joining some
> nodes.
> {noformat}
> 2019-01-11 20:35:01.207 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Starting processing discovery data bag
> 2019-01-11 20:35:01.207 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component ClusterProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:01.207 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component IgnitePluginProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:01.208 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component CacheObjectBinaryProcessorImpl processed joining node data bag in
> 0ms
> 2019-01-11 20:35:01.208 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:01.219 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component GridCacheProcessor processed joining node data bag in 10ms
> 2019-01-11 20:35:01.219 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component GridQueryProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:01.219 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component GridContinuousProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:01.463 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component GridMarshallerMappingProcessor processed joining node data bag in
> 242ms
> 2019-01-11 20:35:01.463 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Total
> time of processing discovery data bag: 252ms
> 2019-01-11 20:35:01.780 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Starting processing discovery data bag
> 2019-01-11 20:35:01.781 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component ClusterProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:01.781 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component IgnitePluginProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:01.781 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component CacheObjectBinaryProcessorImpl processed joining node data bag in
> 0ms
> 2019-01-11 20:35:01.781 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:01.791 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component GridCacheProcessor processed joining node data bag in 10ms
> 2019-01-11 20:35:01.792 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component GridQueryProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:01.792 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component GridContinuousProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:02.134 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component GridMarshallerMappingProcessor processed joining node data bag in
> 338ms
> 2019-01-11 20:35:02.134 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Total
> time of processing discovery data bag: 348ms
> 2019-01-11 20:35:02.326 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Starting processing discovery data bag
> 2019-01-11 20:35:02.326 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component ClusterProcessor processed joining node data bag in 0ms
> 2019-01-11 20:35:02.326 [INFO
> ][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Component IgnitePluginProcessor processed joining node data bag in 0ms
> 2019-01-11
[jira] [Commented] (IGNITE-10753) MVCC: Sometimes vacuum does not cleanup all outdated versions
[
https://issues.apache.org/jira/browse/IGNITE-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748625#comment-16748625
]
Ignite TC Bot commented on IGNITE-10753:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2861173buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Sometimes vacuum does not cleanup all outdated versions
> -
>
> Key: IGNITE-10753
> URL: https://issues.apache.org/jira/browse/IGNITE-10753
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1,
> transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When mvcc test is finished, we check if there any outdated versions are left
> in cache and not cleaned by vacuum. If so, an exception is thrown. There are
> some tests with this problem:
> * {{CacheMvccTransactionsTest.testCleanupWaitsForGet1}}
> * {{CacheMvccTransactionsTest.testCleanupWaitsForGet3}}
> *
> {{CacheMvccReplicatedSqlCoordinatorFailoverTest.testAccountsTxSql_SingleNode_CoordinatorFails_Persistence}}
> *
> {{CacheMvccReplicatedSqlCoordinatorFailoverTest.testPutAllGetAll_ClientServer_Backups0_RestartCoordinator_SqlDml}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10998) Option --check-crc is not shown in help for control.sh
[ https://issues.apache.org/jira/browse/IGNITE-10998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748634#comment-16748634 ] Vladislav Pyatkov commented on IGNITE-10998: Looks good to me. > Option --check-crc is not shown in help for control.sh > -- > > Key: IGNITE-10998 > URL: https://issues.apache.org/jira/browse/IGNITE-10998 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Alex Volkov >Assignee: Sergey Antonov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > After implementing IGNITE-10507 it seems like this option (--check-crc) is > not shown in help for control.sh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748633#comment-16748633 ] Alexei Scherbakov commented on IGNITE-10877: [~voropava], I left two minor comments in PR. Otherwise looks good. > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png, image-2019-01-18-11-36-57-451.png, > image-2019-01-18-11-38-39-410.png, image-2019-01-18-11-55-39-496.png, > image-2019-01-18-11-56-10-339.png, image-2019-01-18-11-56-18-040.png, > image-2019-01-18-12-09-04-835.png, image-2019-01-18-12-09-32-876.png > > Time Spent: 2h 20m > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[
https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748615#comment-16748615
]
Ignite TC Bot commented on IGNITE-10877:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2866643buildTypeId=IgniteTests24Java8_RunAll]
> GridAffinityAssignment.initPrimaryBackupMaps memory pressure
>
>
> Key: IGNITE-10877
> URL: https://issues.apache.org/jira/browse/IGNITE-10877
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
> Fix For: 2.8
>
> Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr,
> image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png,
> image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png,
> image-2019-01-17-15-46-32-872.png, image-2019-01-18-11-36-57-451.png,
> image-2019-01-18-11-38-39-410.png, image-2019-01-18-11-55-39-496.png,
> image-2019-01-18-11-56-10-339.png, image-2019-01-18-11-56-18-040.png,
> image-2019-01-18-12-09-04-835.png, image-2019-01-18-12-09-32-876.png
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> 1) While running tests with JFR we observe huge memory allocation pressure
> produced by:
> *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*
> java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784
> 100
> java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044
> 784 100
> java.util.HashMap.put(Object, Object) 481 298 044 784 100
> java.util.HashSet.add(Object) 480 297 221 040 99,724
>
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
> 1 823 744 0,276
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
> List, List) 1 823 744 0,276
> *Allocation stats*
> Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB
> Size(bytes) Total TLAB Size(bytes) Pressure(%)
> java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
> java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
> java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864
> 11,341
> java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
> java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198
> 2) Also another hot place found
> Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)
> java.util.ArrayList.grow(int) 7 5 766 448 9,554
> java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554
> java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554
> java.util.ArrayList.add(Object) 7 5 766 448 9,554
>
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int,
> AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5
> 766 448 9,554
> The reason of that is defail
> I think we need to improve memory efficiency by switching from from Sets to
> BitSets
>
> JFR attached, see Allocations in 12:50:28 - 12:50:29
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11021) PME join 5 server nodes -15%
[ https://issues.apache.org/jira/browse/IGNITE-11021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-11021: --- Summary: PME join 5 server nodes -15% (was: PME join server node -15%) > PME join 5 server nodes -15% > > > Key: IGNITE-11021 > URL: https://issues.apache.org/jira/browse/IGNITE-11021 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Blocker > Fix For: 2.5 > > > PME benchmark drop -15% on server node join -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11022) PME leave coordinator node -31%
[ https://issues.apache.org/jira/browse/IGNITE-11022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-11022: --- Description: PME benchmark on coordinator node leave drop -31% (was: PME benchmark on server node leave drop -31%) > PME leave coordinator node -31% > --- > > Key: IGNITE-11022 > URL: https://issues.apache.org/jira/browse/IGNITE-11022 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Blocker > Fix For: 2.5 > > > PME benchmark on coordinator node leave drop -31% -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11023) Processing data bag on GridMarshallerMappingProcessor consume many time
[
https://issues.apache.org/jira/browse/IGNITE-11023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-11023:
---
Description:
I have measure a processing data bag time on each join node and discovered what
GridMarshallerMappingProcessor consume more time then others.
It slow down on collecting topology, in particular case if joining some nodes.
{noformat}
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.208 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:01.208 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridCacheProcessor processed joining node data bag in 10ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridQueryProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridContinuousProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.463 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridMarshallerMappingProcessor processed joining node data bag in
242ms
2019-01-11 20:35:01.463 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Total
time of processing discovery data bag: 252ms
2019-01-11 20:35:01.780 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.791 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridCacheProcessor processed joining node data bag in 10ms
2019-01-11 20:35:01.792 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridQueryProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.792 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridContinuousProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.134 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridMarshallerMappingProcessor processed joining node data bag in
338ms
2019-01-11 20:35:02.134 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Total
time of processing discovery data bag: 348ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.337 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridCacheProcessor processed joining node data bag in 10ms
2019-01-11 20:35:02.337 [INFO
[jira] [Created] (IGNITE-11025) PME leave 5 server nodes -45%
Max Shonichev created IGNITE-11025: -- Summary: PME leave 5 server nodes -45% Key: IGNITE-11025 URL: https://issues.apache.org/jira/browse/IGNITE-11025 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11023) Processing data bag on GridMarshallerMappingProcessor consume many time
[
https://issues.apache.org/jira/browse/IGNITE-11023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-11023:
---
Description:
I have measure a processing data bag time on each join node and discovered what
GridMarshallerMappingProcessor consume more time then others.
It slow down on collecting topology, in particular case if joining some nodes.
{noformat}
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.208 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:01.208 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridCacheProcessor processed joining node data bag in 10ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridQueryProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridContinuousProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.463 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridMarshallerMappingProcessor processed joining node data bag in
242ms
2019-01-11 20:35:01.463 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Total
time of processing discovery data bag: 252ms
2019-01-11 20:35:01.780 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.791 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridCacheProcessor processed joining node data bag in 10ms
2019-01-11 20:35:01.792 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridQueryProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.792 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridContinuousProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.134 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridMarshallerMappingProcessor processed joining node data bag in
338ms
2019-01-11 20:35:02.134 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Total
time of processing discovery data bag: 348ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.337 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridCacheProcessor processed joining node data bag in 10ms
2019-01-11 20:35:02.337 [INFO
[jira] [Created] (IGNITE-11024) PME leave server node -69%
Max Shonichev created IGNITE-11024: -- Summary: PME leave server node -69% Key: IGNITE-11024 URL: https://issues.apache.org/jira/browse/IGNITE-11024 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 PME benchmark leave server node -69% -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11023) Processing data bag on GridMarshallerMappingProcessor consume many time
Vladislav Pyatkov created IGNITE-11023:
--
Summary: Processing data bag on GridMarshallerMappingProcessor
consume many time
Key: IGNITE-11023
URL: https://issues.apache.org/jira/browse/IGNITE-11023
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
I have measure a processing data bag time on each join node and discovered what
GridMarshallerMappingProcessor consume more time then others.
It slow down on collecting topology, in particular case if joining some node
simultaneous.
{noformat}
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.208 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:01.208 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridCacheProcessor processed joining node data bag in 10ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridQueryProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridContinuousProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.463 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridMarshallerMappingProcessor processed joining node data bag in
242ms
2019-01-11 20:35:01.463 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Total
time of processing discovery data bag: 252ms
2019-01-11 20:35:01.780 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.791 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridCacheProcessor processed joining node data bag in 10ms
2019-01-11 20:35:01.792 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridQueryProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.792 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridContinuousProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.134 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridMarshallerMappingProcessor processed joining node data bag in
338ms
2019-01-11 20:35:02.134 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Total
time of processing discovery data bag: 348ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.337 [INFO
[jira] [Created] (IGNITE-11022) PME leave server node -31%
Max Shonichev created IGNITE-11022: -- Summary: PME leave server node -31% Key: IGNITE-11022 URL: https://issues.apache.org/jira/browse/IGNITE-11022 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 PME benchmark on server node leave drop -31% -- This message was sent by Atlassian JIRA (v7.6.3#76005)
