[jira] [Commented] (IGNITE-18580) Sql. Redesign the Exchange to use a pull-based approach
[ https://issues.apache.org/jira/browse/IGNITE-18580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679034#comment-17679034 ] Konstantin Orlov commented on IGNITE-18580: --- Run benchmark to get sure the patch doesn't affect performance. Turns out it does, but in positive way. Below is result on my branch: || Benchmark || Mode || Cnt || Score || Error || Units || |SqlBenchmark.selectAllSimple|thrpt|60|1402.852|± 83.882|ops/s| And there is result on main branch (revision a9350e42, some adjustment to benchmark is required): || Benchmark || Mode || Cnt || Score || Error || Units || |SqlBenchmark.selectAllSimple|thrpt|60|829.507|± 36.042|ops/s| > Sql. Redesign the Exchange to use a pull-based approach > --- > > Key: IGNITE-18580 > URL: https://issues.apache.org/jira/browse/IGNITE-18580 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, Exchange uses push-based strategy to exchange batches between > different fragments. Such an approach works well for cases of scanning the > whole table, but may cause an unnecessary overhead in cases, where the > smaller amount of rows is expected. For example, for query "SELECT * FROM > table LIMIT 4", IO_BATCH_SIZE * IO_BATCH_COUNT * NODE_COUNT rows will be sent > over network in push-based approach, whereas only 4 * NODE_COUNT will be sent > in pull-based. > Let's redesign Exchange to gain more control over amount of data that is sent > over the network. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18584) Possible memory errors and corruptions because of insufficient size of compression buffer.
[
https://issues.apache.org/jira/browse/IGNITE-18584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-18584:
-
Fix Version/s: 2.15
> Possible memory errors and corruptions because of insufficient size of
> compression buffer.
> --
>
> Key: IGNITE-18584
> URL: https://issues.apache.org/jira/browse/IGNITE-18584
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Ivan Daschinsky
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{org.apache.ignite.internal.processors.compress.CompressionProcessorImpl#compressBuf}}
> is initialized with 1024 extra space, that may be not enough for compressing.
> I.e. snappy requires 2762 extra space for 16K pages.
> The overhead must be calculated during the initialization with help of
> specialized methods, such as
> {{Snappy#maxCompressedLength}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18584) Possible memory errors and corruptions because of insufficient size of compression buffer.
[
https://issues.apache.org/jira/browse/IGNITE-18584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679026#comment-17679026
]
Ignite TC Bot commented on IGNITE-18584:
{panel:title=Branch: [pull/10490/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10490/head] Base: [master] : New Tests
(216)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Disk Page Compressions 1{color} [[tests
216|https://ci2.ignite.apache.org/viewLog.html?buildId=7006635]]
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testLeafPage[page_size = 4,096, block_size = 16,
compression = SKIP_GARBAGE, level = 0] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testDataPage[page_size = 4,096, block_size = 16,
compression = SNAPPY, level = 0] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testLeafPage[page_size = 4,096, block_size = 16,
compression = SNAPPY, level = 0] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testInnerPage[page_size = 4,096, block_size = 16,
compression = SKIP_GARBAGE, level = 0] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testDataPage[page_size = 4,096, block_size = 16,
compression = SKIP_GARBAGE, level = 0] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testInnerPage[page_size = 4,096, block_size = 16,
compression = LZ4, level = 0] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testDataPage[page_size = 4,096, block_size = 16,
compression = LZ4, level = 0] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testLeafPage[page_size = 4,096, block_size = 16,
compression = LZ4, level = 0] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testInnerPage[page_size = 4,096, block_size = 16,
compression = SNAPPY, level = 0] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testLeafPage[page_size = 4,096, block_size = 16,
compression = ZSTD, level = 3] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
CompressionProcessorTest.testInnerPage[page_size = 4,096, block_size = 16,
compression = LZ4, level = 17] - PASSED{color}
... and 205 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7006085&buildTypeId=IgniteTests24Java8_RunAll]
> Possible memory errors and corruptions because of insufficient size of
> compression buffer.
> --
>
> Key: IGNITE-18584
> URL: https://issues.apache.org/jira/browse/IGNITE-18584
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Ivan Daschinsky
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{org.apache.ignite.internal.processors.compress.CompressionProcessorImpl#compressBuf}}
> is initialized with 1024 extra space, that may be not enough for compressing.
> I.e. snappy requires 2762 extra space for 16K pages.
> The overhead must be calculated during the initialization with help of
> specialized methods, such as
> {{Snappy#maxCompressedLength}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18584) Possible memory errors and corruptions because of insufficient size of compression buffer.
[
https://issues.apache.org/jira/browse/IGNITE-18584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky reassigned IGNITE-18584:
Assignee: Ivan Daschinsky
> Possible memory errors and corruptions because of insufficient size of
> compression buffer.
> --
>
> Key: IGNITE-18584
> URL: https://issues.apache.org/jira/browse/IGNITE-18584
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{org.apache.ignite.internal.processors.compress.CompressionProcessorImpl#compressBuf}}
> is initialized with 1024 extra space, that may be not enough for compressing.
> I.e. snappy requires 2762 extra space for 16K pages.
> The overhead must be calculated during the initialization with help of
> specialized methods, such as
> {{Snappy#maxCompressedLength}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18254) Sql. Extend SQL grammar with ALTER ZONE statement
[
https://issues.apache.org/jira/browse/IGNITE-18254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-18254:
--
Ignite Flags: Docs Required (was: Docs Required,Release Notes Required)
> Sql. Extend SQL grammar with ALTER ZONE statement
> -
>
> Key: IGNITE-18254
> URL: https://issues.apache.org/jira/browse/IGNITE-18254
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Yury Gerzhedovich
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> As we can CREATE and DROP ZONE need to provide ability to altering a
> distribution zones by DDL commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> ALTER ZONE {fq_zone_name | simple_zone_name} RENAME TO {fq_new_zone_name} [;]
> ALTER ZONE
> { fq_zone_name | simple_zone_name }
> WITH
> [],
> [DATA_NODES_FILTER = filter],
> [REPLICAS = replicas],
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]
> {code}
> So, could be changed any distributed zone parameters except PARTITIONS and
> AFFINITY_FUNCTION
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18254) Sql. Extend SQL grammar with ALTER ZONE statement
[
https://issues.apache.org/jira/browse/IGNITE-18254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-18254:
--
Fix Version/s: 3.0.0-beta2
> Sql. Extend SQL grammar with ALTER ZONE statement
> -
>
> Key: IGNITE-18254
> URL: https://issues.apache.org/jira/browse/IGNITE-18254
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Yury Gerzhedovich
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> As we can CREATE and DROP ZONE need to provide ability to altering a
> distribution zones by DDL commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> ALTER ZONE {fq_zone_name | simple_zone_name} RENAME TO {fq_new_zone_name} [;]
> ALTER ZONE
> { fq_zone_name | simple_zone_name }
> WITH
> [],
> [DATA_NODES_FILTER = filter],
> [REPLICAS = replicas],
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]
> {code}
> So, could be changed any distributed zone parameters except PARTITIONS and
> AFFINITY_FUNCTION
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18593) Get rid of MvPartitionStorage and TxStateStorage in PartitionAccess
Kirill Tkalenko created IGNITE-18593: Summary: Get rid of MvPartitionStorage and TxStateStorage in PartitionAccess Key: IGNITE-18593 URL: https://issues.apache.org/jira/browse/IGNITE-18593 Project: Ignite Issue Type: Task Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 For *org.apache.ignite.internal.table.distributed.raft.snapshot.PartitionAccess*, we need to define specific simple methods that are needed for snapshots instead of using *org.apache.ignite.internal.storage.MvPartitionStorage* and *org.apache.ignite.internal.tx.storage.state.TxStateStorage* directly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18592) [ducktests] Do not free service node before test completion
[
https://issues.apache.org/jira/browse/IGNITE-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov reassigned IGNITE-18592:
Assignee: Sergey Korotkov
> [ducktests] Do not free service node before test completion
> ---
>
> Key: IGNITE-18592
> URL: https://issues.apache.org/jira/browse/IGNITE-18592
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
>
> The
> {{ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test}}
> test frees nodes used by one of its IgniteApplicationService (preloader)
> before the test completion.
> It causes the following two problems:
> 1. Logs of the preloader are not copied to the test results package
> 2. Some other test running concurrently may try to reuse this node (yet
> uncleaned and containing data at /mnt/service) which would cause unexpected
> test failures.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18592) [ducktests] Do not free service node before test completion
Sergey Korotkov created IGNITE-18592:
Summary: [ducktests] Do not free service node before test
completion
Key: IGNITE-18592
URL: https://issues.apache.org/jira/browse/IGNITE-18592
Project: Ignite
Issue Type: Test
Reporter: Sergey Korotkov
The
{{ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test}}
test frees nodes used by one of its IgniteApplicationService (preloader)
before the test completion.
It causes the following two problems:
1. Logs of the preloader are not copied to the test results package
2. Some other test running concurrently may try to reuse this node (yet
uncleaned and containing data at /mnt/service) which would cause unexpected
test failures.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18580) Sql. Redesign the Exchange to use a pull-based approach
[ https://issues.apache.org/jira/browse/IGNITE-18580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-18580: -- Fix Version/s: 3.0.0-beta2 > Sql. Redesign the Exchange to use a pull-based approach > --- > > Key: IGNITE-18580 > URL: https://issues.apache.org/jira/browse/IGNITE-18580 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, Exchange uses push-based strategy to exchange batches between > different fragments. Such an approach works well for cases of scanning the > whole table, but may cause an unnecessary overhead in cases, where the > smaller amount of rows is expected. For example, for query "SELECT * FROM > table LIMIT 4", IO_BATCH_SIZE * IO_BATCH_COUNT * NODE_COUNT rows will be sent > over network in push-based approach, whereas only 4 * NODE_COUNT will be sent > in pull-based. > Let's redesign Exchange to gain more control over amount of data that is sent > over the network. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18580) Sql. Redesign the Exchange to use a pull-based approach
[ https://issues.apache.org/jira/browse/IGNITE-18580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-18580: -- Epic Link: IGNITE-18202 > Sql. Redesign the Exchange to use a pull-based approach > --- > > Key: IGNITE-18580 > URL: https://issues.apache.org/jira/browse/IGNITE-18580 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Currently, Exchange uses push-based strategy to exchange batches between > different fragments. Such an approach works well for cases of scanning the > whole table, but may cause an unnecessary overhead in cases, where the > smaller amount of rows is expected. For example, for query "SELECT * FROM > table LIMIT 4", IO_BATCH_SIZE * IO_BATCH_COUNT * NODE_COUNT rows will be sent > over network in push-based approach, whereas only 4 * NODE_COUNT will be sent > in pull-based. > Let's redesign Exchange to gain more control over amount of data that is sent > over the network. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18556) Sql. TypeSystem. Default implementation of getDefaultPrecision for FLOAT and DOUBLE returns the same value.
[ https://issues.apache.org/jira/browse/IGNITE-18556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18556: -- Summary: Sql. TypeSystem. Default implementation of getDefaultPrecision for FLOAT and DOUBLE returns the same value. (was: Sql. TypeSystem. Default implementation of getDefaultPrecision for FLOAT and DECIMAL returns the same value.) > Sql. TypeSystem. Default implementation of getDefaultPrecision for FLOAT and > DOUBLE returns the same value. > --- > > Key: IGNITE-18556 > URL: https://issues.apache.org/jira/browse/IGNITE-18556 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite2-required, calcite3-required, ignite-3 > Fix For: 3.0.0-beta1 > > > Default implementation of TypeSystem::getDefaultPrecision, provided by > Calcite, returns the same value for FLOAT and DOUBLE types. Such behaviour > causes TypeFactory::leastRestrictiveType to return different results for > (FLOAT, DOUBLE) and (DOUBLE, FLOAT). > We fixed getDefaultPrecision to return different values to resolve the > problem with leastRestrictiveType in IGNITE-18163. > 1) Investigate how this change affects behaviour of other operators. > 2) Choose the appropriate value for default precision in IgniteTypeSystem for > FLOAT and DOUBLE if necessary. > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18556) Sql. TypeSystem. Default implementation of getDefaultPrecision for FLOAT and DECIMAL returns the same value.
[ https://issues.apache.org/jira/browse/IGNITE-18556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18556: -- Summary: Sql. TypeSystem. Default implementation of getDefaultPrecision for FLOAT and DECIMAL returns the same value. (was: Sql. TypeSystem. Default implementation of getDefaultPrecision FLOAT and DECIMAL returns the same value.) > Sql. TypeSystem. Default implementation of getDefaultPrecision for FLOAT and > DECIMAL returns the same value. > > > Key: IGNITE-18556 > URL: https://issues.apache.org/jira/browse/IGNITE-18556 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite2-required, calcite3-required, ignite-3 > Fix For: 3.0.0-beta1 > > > Default implementation of TypeSystem::getDefaultPrecision, provided by > Calcite, returns the same value for FLOAT and DOUBLE types. Such behaviour > causes TypeFactory::leastRestrictiveType to return different results for > (FLOAT, DOUBLE) and (DOUBLE, FLOAT). > We fixed getDefaultPrecision to return different values to resolve the > problem with leastRestrictiveType in IGNITE-18163. > 1) Investigate how this change affects behaviour of other operators. > 2) Choose the appropriate value for default precision in IgniteTypeSystem for > FLOAT and DOUBLE if necessary. > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-12932) Thin client cluster discovery
[ https://issues.apache.org/jira/browse/IGNITE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12932: --- Labels: IEP-44 important (was: important) > Thin client cluster discovery > - > > Key: IGNITE-12932 > URL: https://issues.apache.org/jira/browse/IGNITE-12932 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: IEP-44, important > Fix For: 2.9 > > Original Estimate: 336h > Time Spent: 20m > Remaining Estimate: 3h 50m > > Thin clients should be able to discover all server nodes automatically when > connected to any of them, and maintain an up to date list of servers at all > times. > See > [IEP-44|https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery] > for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18591) Java thin client: Cluster discovery
[ https://issues.apache.org/jira/browse/IGNITE-18591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18591: --- Labels: IEP-44 (was: ) > Java thin client: Cluster discovery > --- > > Key: IGNITE-18591 > URL: https://issues.apache.org/jira/browse/IGNITE-18591 > Project: Ignite > Issue Type: New Feature >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-44 > > We already have cluster endpoints discovery in protocol and implementation > for .NET thin client. > Implementation for java thin client should be added too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18591) Java thin client: Cluster discovery
Aleksey Plekhanov created IGNITE-18591: -- Summary: Java thin client: Cluster discovery Key: IGNITE-18591 URL: https://issues.apache.org/jira/browse/IGNITE-18591 Project: Ignite Issue Type: New Feature Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov We already have cluster endpoints discovery in protocol and implementation for .NET thin client. Implementation for java thin client should be added too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18525) Introduce new PlacementDriver Ignite component
[ https://issues.apache.org/jira/browse/IGNITE-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678821#comment-17678821 ] Alexander Lapin commented on IGNITE-18525: -- [~v.pyatkov] LGTM, merged, thx! > Introduce new PlacementDriver Ignite component > -- > > Key: IGNITE-18525 > URL: https://issues.apache.org/jira/browse/IGNITE-18525 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h > Remaining Estimate: 0h > > h3. Motivation > Placement Driver is expected to be used as > * A leaseholder tracker, or in other words, an engine for replication groups > leases selection and fail-over. > * Distributed meta data propagator, such as safe time, will be implemented > in Placement Driver [Part 2] though. > This is an initial ticket, a sort of utility one, that will introduce new > PlacementDriver Ignite component, add corresponding dependencies wihtin mvn > and gradle and incorporate the component into node start/stop flow. > h3. Definition of Done > * New Placement Driver Ignite Component is introduced along with > corresponding decencies (e.g. meta storage), busy locks, etc. > * It's properly started and stopped withing Ignite node start/stop process. > h3. Implementation Notes > Pretty straightforward. The one to mention is that introducing new component > will required to update tests and mocks, however because at this point > placement driver does nothing it'll possible to use nulls almost everywhere. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18525) Introduce new PlacementDriver Ignite component
[ https://issues.apache.org/jira/browse/IGNITE-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-18525: - Fix Version/s: 3.0.0-beta2 > Introduce new PlacementDriver Ignite component > -- > > Key: IGNITE-18525 > URL: https://issues.apache.org/jira/browse/IGNITE-18525 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h > Remaining Estimate: 0h > > h3. Motivation > Placement Driver is expected to be used as > * A leaseholder tracker, or in other words, an engine for replication groups > leases selection and fail-over. > * Distributed meta data propagator, such as safe time, will be implemented > in Placement Driver [Part 2] though. > This is an initial ticket, a sort of utility one, that will introduce new > PlacementDriver Ignite component, add corresponding dependencies wihtin mvn > and gradle and incorporate the component into node start/stop flow. > h3. Definition of Done > * New Placement Driver Ignite Component is introduced along with > corresponding decencies (e.g. meta storage), busy locks, etc. > * It's properly started and stopped withing Ignite node start/stop process. > h3. Implementation Notes > Pretty straightforward. The one to mention is that introducing new component > will required to update tests and mocks, however because at this point > placement driver does nothing it'll possible to use nulls almost everywhere. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18590) Transaction recovery tries rollback a tx concurrently with committing it
[ https://issues.apache.org/jira/browse/IGNITE-18590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18590: Ignite Flags: (was: Docs Required,Release Notes Required) > Transaction recovery tries rollback a tx concurrently with committing it > > > Key: IGNITE-18590 > URL: https://issues.apache.org/jira/browse/IGNITE-18590 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18590) Transaction recovery tries rollback a tx concurrently with committing it
Maksim Timonin created IGNITE-18590: --- Summary: Transaction recovery tries rollback a tx concurrently with committing it Key: IGNITE-18590 URL: https://issues.apache.org/jira/browse/IGNITE-18590 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin Assignee: Maksim Timonin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18550) Command for verifying incremental snapshot
[ https://issues.apache.org/jira/browse/IGNITE-18550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-18550: Assignee: Nikolay Izhikov > Command for verifying incremental snapshot > -- > > Key: IGNITE-18550 > URL: https://issues.apache.org/jira/browse/IGNITE-18550 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-89, ise > Fix For: 2.15 > > > control.sh should provide an util for checking incremental snapshots: > # It should parse specified snapshot on every node, prepare collection of > transactions and participated nodes > # all participated nodes must approve the transaction. (or coordinator must > validate collections from every node). > Check whether this check can be embedded in existing snapshot check commads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18556) Sql. TypeSystem. Default implementation of getDefaultPrecision FLOAT and DECIMAL returns the same value.
[ https://issues.apache.org/jira/browse/IGNITE-18556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-18556: --- Labels: calcite2-required calcite3-required ignite-3 (was: ignite-3) > Sql. TypeSystem. Default implementation of getDefaultPrecision FLOAT and > DECIMAL returns the same value. > > > Key: IGNITE-18556 > URL: https://issues.apache.org/jira/browse/IGNITE-18556 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite2-required, calcite3-required, ignite-3 > Fix For: 3.0.0-beta1 > > > Default implementation of TypeSystem::getDefaultPrecision, provided by > Calcite, returns the same value for FLOAT and DOUBLE types. Such behaviour > causes TypeFactory::leastRestrictiveType to return different results for > (FLOAT, DOUBLE) and (DOUBLE, FLOAT). > We fixed getDefaultPrecision to return different values to resolve the > problem with leastRestrictiveType in IGNITE-18163. > 1) Investigate how this change affects behaviour of other operators. > 2) Choose the appropriate value for default precision in IgniteTypeSystem for > FLOAT and DOUBLE if necessary. > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18163) Old-style join on different column types fails with ClassCastException
[
https://issues.apache.org/jira/browse/IGNITE-18163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-18163:
Labels: calcite2-required calcite3-required ignite-3 (was:
calcite3-required ignite-3)
> Old-style join on different column types fails with ClassCastException
> --
>
> Key: IGNITE-18163
> URL: https://issues.apache.org/jira/browse/IGNITE-18163
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Query:
> {code}
> select _T0.KEY, _T1.VAL from PUBLIC.TBL1 as _T0, PUBLIC.TBL_INT32 as _T1
> where _T0.KEY IS NOT DISTINCT FROM _T1.KEY
> {code}
> Result:
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:ef4217b1-04ef-4f08-b1c3-76effc3fc262 class java.lang.Long cannot be
> cast to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
> module java.base of loader 'bootstrap')
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.onError(MergeJoinNode.java:124)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:205)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.lambda$start$2(ExchangeServiceImpl.java:81)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$3(MessageServiceImpl.java:133)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class java.lang.Long cannot be cast
> to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
> module java.base of loader 'bootstrap')
> at java.base/java.lang.Integer.compareTo(Integer.java:59)
> at
> org.apache.calcite.rel.RelFieldCollation.compare(RelFieldCollation.java:43)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.compare(ExpressionFactoryImpl.java:235)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl$2.compare(ExpressionFactoryImpl.java:217)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$InnerJoin.join(MergeJoinNode.java:318)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode.pushLeft(MergeJoinNode.java:162)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.push(MergeJoin
[jira] [Updated] (IGNITE-18556) Sql. TypeSystem. Default implementation of getDefaultPrecision FLOAT and DECIMAL returns the same value.
[ https://issues.apache.org/jira/browse/IGNITE-18556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-18556: --- Affects Version/s: 3.0.0-beta1 > Sql. TypeSystem. Default implementation of getDefaultPrecision FLOAT and > DECIMAL returns the same value. > > > Key: IGNITE-18556 > URL: https://issues.apache.org/jira/browse/IGNITE-18556 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > Default implementation of TypeSystem::getDefaultPrecision, provided by > Calcite, returns the same value for FLOAT and DOUBLE types. Such behaviour > causes TypeFactory::leastRestrictiveType to return different results for > (FLOAT, DOUBLE) and (DOUBLE, FLOAT). > We fixed getDefaultPrecision to return different values to resolve the > problem with leastRestrictiveType in IGNITE-18163. > 1) Investigate how this change affects behaviour of other operators. > 2) Choose the appropriate value for default precision in IgniteTypeSystem for > FLOAT and DOUBLE if necessary. > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18589) Network serialization of arrays of NetworkMessage objects doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-18589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18589:
-
Description:
Consider the following class hierarchy:
{code:java}
@Transferable
interface A extends NetworkMessage {}
@Transferable
interface B extends NetworkMessage {
A[] arrayField();
}
{code}
When sending a message of type {{B}} from one node to another, the following
exception occurs:
{{java.lang.IllegalStateException: Cannot merge descriptors in the correct
order; a cycle?}}
This happens, because a descriptor of type {{A}} can't be found on the
receiving node.
This problem also appears if we change {{B}}'s field type to {{Collection}},
but provide {{Arrays.asList(new AImpl())}}, because the wrapper contains an
array inside.
was:
Consider the following class hierarchy:
{code:java}
@Transferable
interface A extends NetworkMessage {}
@Transferable
interface B extends NetworkMessage {
A[] arrayField();
}
{code}
When sending a message of type {{B}} from one node to another, the following
exception occurs:
{{java.lang.IllegalStateException: Cannot merge descriptors in the correct
order; a cycle?}}
This happens, because a descriptor of type {{A}} can't be found on the
receiving node.
This problem also appears if we change {{B}}'s field to {{Collection}}, but
provide {{Arrays.asList(new AImpl())}}, because the wrapper contains an array
inside.
> Network serialization of arrays of NetworkMessage objects doesn't work
> --
>
> Key: IGNITE-18589
> URL: https://issues.apache.org/jira/browse/IGNITE-18589
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> Consider the following class hierarchy:
> {code:java}
> @Transferable
> interface A extends NetworkMessage {}
> @Transferable
> interface B extends NetworkMessage {
> A[] arrayField();
> }
> {code}
> When sending a message of type {{B}} from one node to another, the following
> exception occurs:
> {{java.lang.IllegalStateException: Cannot merge descriptors in the correct
> order; a cycle?}}
> This happens, because a descriptor of type {{A}} can't be found on the
> receiving node.
> This problem also appears if we change {{B}}'s field type to
> {{Collection}}, but provide {{Arrays.asList(new AImpl())}}, because the
> wrapper contains an array inside.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18589) Network serialization of arrays of NetworkMessage objects doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-18589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18589:
-
Summary: Network serialization of arrays of NetworkMessage objects doesn't
work (was: Network serialization of arrays of NetworkMessage object doesn't
work)
> Network serialization of arrays of NetworkMessage objects doesn't work
> --
>
> Key: IGNITE-18589
> URL: https://issues.apache.org/jira/browse/IGNITE-18589
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> Consider the following class hierarchy:
> {code:java}
> @Transferable
> interface A extends NetworkMessage {}
> @Transferable
> interface B extends NetworkMessage {
> A[] arrayField();
> }
> {code}
> When sending a message of type {{B}} from one node to another, the following
> exception occurs:
> {{java.lang.IllegalStateException: Cannot merge descriptors in the correct
> order; a cycle?}}
> This happens, because a descriptor of type {{A}} can't be found on the
> receiving node.
> This problem also appears if we change {{B}}'s field to {{Collection}},
> but provide {{Arrays.asList(new AImpl())}}, because the wrapper contains an
> array inside.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18589) Network serialization of arrays of NetworkMessage object doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-18589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18589:
-
Description:
Consider the following class hierarchy:
{code:java}
@Transferable
interface A extends NetworkMessage {}
@Transferable
interface B extends NetworkMessage {
A[] arrayField();
}
{code}
When sending a message of type {{B}} from one node to another, the following
exception occurs:
{{java.lang.IllegalStateException: Cannot merge descriptors in the correct
order; a cycle?}}
This happens, because a descriptor of type {{A}} can't be found on the
receiving node.
This problem also appears if we change {{B}}'s field to {{Collection}}, but
provide {{Arrays.asList(new AImpl())}}, because the wrapper contains an array
inside.
> Network serialization of arrays of NetworkMessage object doesn't work
> -
>
> Key: IGNITE-18589
> URL: https://issues.apache.org/jira/browse/IGNITE-18589
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> Consider the following class hierarchy:
> {code:java}
> @Transferable
> interface A extends NetworkMessage {}
> @Transferable
> interface B extends NetworkMessage {
> A[] arrayField();
> }
> {code}
> When sending a message of type {{B}} from one node to another, the following
> exception occurs:
> {{java.lang.IllegalStateException: Cannot merge descriptors in the correct
> order; a cycle?}}
> This happens, because a descriptor of type {{A}} can't be found on the
> receiving node.
> This problem also appears if we change {{B}}'s field to {{Collection}},
> but provide {{Arrays.asList(new AImpl())}}, because the wrapper contains an
> array inside.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18589) Network serialization of arrays of NetworkMessage object doesn't work
Aleksandr Polovtcev created IGNITE-18589: Summary: Network serialization of arrays of NetworkMessage object doesn't work Key: IGNITE-18589 URL: https://issues.apache.org/jira/browse/IGNITE-18589 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18588) .NET: Thin 3.0: BinaryTupleReader incorrect behavior on type mismatch
[
https://issues.apache.org/jira/browse/IGNITE-18588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18588:
Description:
Add the following test to *BinaryTupleTests*:
{code:c#}
[Test]
public void TestShortAsByte()
{
var bytes = Build((ref BinaryTupleBuilder b) => b.AppendShort(257));
var reader = new BinaryTupleReader(bytes, 1);
Assert.AreEqual(257, reader.GetByte(0));
}
{code}
The result is assertion failure "Expected: 257 But was: 1" - we get incorrect
value, but there should be an exception when the data does not fit into the
requested type.
was:
Add the following test to *BinaryTupleTests*:
{code:csharp}
[Test]
public void TestShortAsByte()
{
var bytes = Build((ref BinaryTupleBuilder b) => b.AppendShort(257));
var reader = new BinaryTupleReader(bytes, 1);
Assert.AreEqual(257, reader.GetByte(0));
}
{code}
The result is assertion failure "Expected: 257 But was: 1" - we get incorrect
value, but there should be an exception when the data does not fit into the
requested type.
> .NET: Thin 3.0: BinaryTupleReader incorrect behavior on type mismatch
> -
>
> Key: IGNITE-18588
> URL: https://issues.apache.org/jira/browse/IGNITE-18588
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *BinaryTupleTests*:
> {code:c#}
> [Test]
> public void TestShortAsByte()
> {
> var bytes = Build((ref BinaryTupleBuilder b) => b.AppendShort(257));
> var reader = new BinaryTupleReader(bytes, 1);
> Assert.AreEqual(257, reader.GetByte(0));
> }
> {code}
> The result is assertion failure "Expected: 257 But was: 1" - we get
> incorrect value, but there should be an exception when the data does not fit
> into the requested type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18588) .NET: Thin 3.0: BinaryTupleReader incorrect behavior on type mismatch
[
https://issues.apache.org/jira/browse/IGNITE-18588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18588:
Description:
Add the following test to *BinaryTupleTests*:
{code:csharp}
[Test]
public void TestShortAsByte()
{
var bytes = Build((ref BinaryTupleBuilder b) => b.AppendShort(257));
var reader = new BinaryTupleReader(bytes, 1);
Assert.AreEqual(257, reader.GetByte(0));
}
{code}
The result is assertion failure "Expected: 257 But was: 1" - we get incorrect
value, but there should be an exception when the data does not fit into the
requested type.
> .NET: Thin 3.0: BinaryTupleReader incorrect behavior on type mismatch
> -
>
> Key: IGNITE-18588
> URL: https://issues.apache.org/jira/browse/IGNITE-18588
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *BinaryTupleTests*:
> {code:csharp}
> [Test]
> public void TestShortAsByte()
> {
> var bytes = Build((ref BinaryTupleBuilder b) => b.AppendShort(257));
> var reader = new BinaryTupleReader(bytes, 1);
> Assert.AreEqual(257, reader.GetByte(0));
> }
> {code}
> The result is assertion failure "Expected: 257 But was: 1" - we get
> incorrect value, but there should be an exception when the data does not fit
> into the requested type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18588) .NET: Thin 3.0: BinaryTupleReader incorrect behavior on type mismatch
Pavel Tupitsyn created IGNITE-18588: --- Summary: .NET: Thin 3.0: BinaryTupleReader incorrect behavior on type mismatch Key: IGNITE-18588 URL: https://issues.apache.org/jira/browse/IGNITE-18588 Project: Ignite Issue Type: Bug Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18587) Provide the ability to rollover performance staticstics files
[ https://issues.apache.org/jira/browse/IGNITE-18587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-18587. -- Resolution: Duplicate > Provide the ability to rollover performance staticstics files > - > > Key: IGNITE-18587 > URL: https://issues.apache.org/jira/browse/IGNITE-18587 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Minor > > It will be convinient for the user to have ability rollover and study > performance statistics files without turning off statistics collection. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18030) Integration of the new full rebalance API with IncomingSnapshotCopier
[ https://issues.apache.org/jira/browse/IGNITE-18030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-18030: Assignee: Kirill Tkalenko > Integration of the new full rebalance API with IncomingSnapshotCopier > - > > Key: IGNITE-18030 > URL: https://issues.apache.org/jira/browse/IGNITE-18030 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We need to integrate the new full rebalance API without losing user data with > *IncomingSnapshotCopier*, additional tests may be needed. > The main idea is described in IGNITE-17990. > API should be in ticket IGNITE-18021 and IGNITE-18022. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16160) [ignite-extensions] Failed CdcKafkaReplicationTest.testActivePassiveReplication
[
https://issues.apache.org/jira/browse/IGNITE-16160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-16160:
---
Component/s: extensions
> [ignite-extensions] Failed
> CdcKafkaReplicationTest.testActivePassiveReplication
> ---
>
> Key: IGNITE-16160
> URL: https://issues.apache.org/jira/browse/IGNITE-16160
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Sergei Ryzhov
>Priority: Major
> Labels: IEP-59, ise
>
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc?branch=%3Cdefault%3E&mode=builds#all-projects
> Log:
> {code:java}
> [2022-04-16
> 06:13:32,532][ERROR][async-runnable-runner-1][IgniteTestResources] Cdc error
> class org.apache.ignite.IgniteInterruptedException: Got interrupted
> while waiting for future to complete.
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:947)
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:945)
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1130)
> at org.apache.ignite.Ignition.start(Ignition.java:331)
> at
> org.apache.ignite.cdc.IgniteToIgniteCdcStreamer.start(IgniteToIgniteCdcStreamer.java:114)
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.start(WalRecordsConsumer.java:148)
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:283)
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:230)
> at
> org.apache.ignite.cdc.CdcIgniteToIgniteReplicationTest.lambda$igniteToIgnite$0(CdcIgniteToIgniteReplicationTest.java:83)
> at
> org.apache.ignite.testframework.GridTestUtils$RunnableX.run(GridTestUtils.java:2569)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$3(GridTestUtils.java:1161)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$4(GridTestUtils.java:1217)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1538)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:88)
> [2022-04-16
> 06:13:32,550][ERROR][async-runnable-runner-1][IgniteTestResources] Cdc error
> class org.apache.ignite.IgniteException: sleep interrupted
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:414)
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:286)
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:230)
> at
> org.apache.ignite.cdc.CdcIgniteToIgniteReplicationTest.lambda$igniteToIgnite$0(CdcIgniteToIgniteReplicationTest.java:83)
> at
> org.apache.ignite.testframework.GridTestUtils$RunnableX.run(GridTestUtils.java:2569)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$3(GridTestUtils.java:1161)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$4(GridTestUtils.java:1217)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1538)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:88)
> Caused by: class
> org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
> interrupted
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:8252)
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:410)
> ... 8 more
> Caused by: java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:8247)
> ... 9 more
> [2022-04-16
> 06:13:32,564][ERROR][async-runnable-runner-1][IgniteTestResources] Cdc error
> class org.apache.ignite.IgniteException: sleep interrupted
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:414)
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:286)
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:230)
> at
> org.apache.ignite.cdc.CdcIgniteToIgniteReplicationTest.lambda$igniteToIgnite$0(CdcIgniteToIgniteReplicationTest.java:83)
> at
> org.apache.ignite.testframework.GridTestUtils$RunnableX.run(GridTestUtils.java:2569)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$3(GridTestUtils.java:1161)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$4(GridTestUtils.java:1217)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1538)
> at
> org.apache.ignite.testframewo
[jira] [Updated] (IGNITE-16160) [ignite-extensions] Failed CdcKafkaReplicationTest.testActivePassiveReplication
[
https://issues.apache.org/jira/browse/IGNITE-16160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-16160:
---
Labels: IEP-59 ise (was: ise)
> [ignite-extensions] Failed
> CdcKafkaReplicationTest.testActivePassiveReplication
> ---
>
> Key: IGNITE-16160
> URL: https://issues.apache.org/jira/browse/IGNITE-16160
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Priority: Major
> Labels: IEP-59, ise
>
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc?branch=%3Cdefault%3E&mode=builds#all-projects
> Log:
> {code:java}
> [2022-04-16
> 06:13:32,532][ERROR][async-runnable-runner-1][IgniteTestResources] Cdc error
> class org.apache.ignite.IgniteInterruptedException: Got interrupted
> while waiting for future to complete.
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:947)
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:945)
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1130)
> at org.apache.ignite.Ignition.start(Ignition.java:331)
> at
> org.apache.ignite.cdc.IgniteToIgniteCdcStreamer.start(IgniteToIgniteCdcStreamer.java:114)
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.start(WalRecordsConsumer.java:148)
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:283)
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:230)
> at
> org.apache.ignite.cdc.CdcIgniteToIgniteReplicationTest.lambda$igniteToIgnite$0(CdcIgniteToIgniteReplicationTest.java:83)
> at
> org.apache.ignite.testframework.GridTestUtils$RunnableX.run(GridTestUtils.java:2569)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$3(GridTestUtils.java:1161)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$4(GridTestUtils.java:1217)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1538)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:88)
> [2022-04-16
> 06:13:32,550][ERROR][async-runnable-runner-1][IgniteTestResources] Cdc error
> class org.apache.ignite.IgniteException: sleep interrupted
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:414)
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:286)
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:230)
> at
> org.apache.ignite.cdc.CdcIgniteToIgniteReplicationTest.lambda$igniteToIgnite$0(CdcIgniteToIgniteReplicationTest.java:83)
> at
> org.apache.ignite.testframework.GridTestUtils$RunnableX.run(GridTestUtils.java:2569)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$3(GridTestUtils.java:1161)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$4(GridTestUtils.java:1217)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1538)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:88)
> Caused by: class
> org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
> interrupted
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:8252)
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:410)
> ... 8 more
> Caused by: java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:8247)
> ... 9 more
> [2022-04-16
> 06:13:32,564][ERROR][async-runnable-runner-1][IgniteTestResources] Cdc error
> class org.apache.ignite.IgniteException: sleep interrupted
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:414)
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:286)
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:230)
> at
> org.apache.ignite.cdc.CdcIgniteToIgniteReplicationTest.lambda$igniteToIgnite$0(CdcIgniteToIgniteReplicationTest.java:83)
> at
> org.apache.ignite.testframework.GridTestUtils$RunnableX.run(GridTestUtils.java:2569)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$3(GridTestUtils.java:1161)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$4(GridTestUtils.java:1217)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1538)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridT
[jira] [Commented] (IGNITE-18203) Redesign table/index creation to avoid dependency cycles
[
https://issues.apache.org/jira/browse/IGNITE-18203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678659#comment-17678659
]
Aleksandr Polovtcev commented on IGNITE-18203:
--
Changing the priority to "blocker" because after changes in IGNITE-18397 a lot
of tests started failing sporadically
> Redesign table/index creation to avoid dependency cycles
>
>
> Key: IGNITE-18203
> URL: https://issues.apache.org/jira/browse/IGNITE-18203
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, index depends on a table, while table depends on RAFT groups
> start, which may need to apply commands (including inserts), and inserts
> depend on indices of the table. There is a dependency cycle. This is just one
> example of such a cycle in the current design.
> One idea is to split 'Table' entity into 2: 'Table Structure' and 'Full
> Table'. Table structure would only comprise objects representing bare table
> information (no indices), something like current
> {{{}TableImpl{}}}/{{{}InternalTable{}}}. Then, the following dependencies
> could be created:
> # Table Structure depends on Configuration
> # Index depends on Configuration and Table Structure
> # Sql Schema depends on Table Structure and Index
> # Full Table depends on Table Structure, Index, Sql Schema
> This requires a redesign of how {{{}TableManager{}}}, {{{}IndexManager{}}},
> {{SqlSchemaManager}} interact, probably {{TableManager}} needs to be broken
> in 2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18203) Redesign table/index creation to avoid dependency cycles
[
https://issues.apache.org/jira/browse/IGNITE-18203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18203:
-
Priority: Blocker (was: Major)
> Redesign table/index creation to avoid dependency cycles
>
>
> Key: IGNITE-18203
> URL: https://issues.apache.org/jira/browse/IGNITE-18203
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, index depends on a table, while table depends on RAFT groups
> start, which may need to apply commands (including inserts), and inserts
> depend on indices of the table. There is a dependency cycle. This is just one
> example of such a cycle in the current design.
> One idea is to split 'Table' entity into 2: 'Table Structure' and 'Full
> Table'. Table structure would only comprise objects representing bare table
> information (no indices), something like current
> {{{}TableImpl{}}}/{{{}InternalTable{}}}. Then, the following dependencies
> could be created:
> # Table Structure depends on Configuration
> # Index depends on Configuration and Table Structure
> # Sql Schema depends on Table Structure and Index
> # Full Table depends on Table Structure, Index, Sql Schema
> This requires a redesign of how {{{}TableManager{}}}, {{{}IndexManager{}}},
> {{SqlSchemaManager}} interact, probably {{TableManager}} needs to be broken
> in 2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18585) Sql. Introduce cache for serialized RelNodes representation.
[ https://issues.apache.org/jira/browse/IGNITE-18585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678648#comment-17678648 ] Evgeny Stanilovsky commented on IGNITE-18585: - Benchmark[18585] Mode Cnt Score Error Units SqlBenchmark.selectAllSimple thrpt 10 3540.312 ± 373.380 ops/s Benchmark[main]Mode Cnt Score Error Units SqlBenchmark.selectAllSimple thrpt 10 3058.390 ± 231.728 ops/s > Sql. Introduce cache for serialized RelNodes representation. > > > Key: IGNITE-18585 > URL: https://issues.apache.org/jira/browse/IGNITE-18585 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite3-required, ignite-3 > > Check ExecutionServiceImpl#prepareFragment, seems it would be useful to cache > serialized rel nodes representation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-13150) Provide the ability to profile only specific operations
[
https://issues.apache.org/jira/browse/IGNITE-13150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-13150:
-
Labels: ise (was: )
> Provide the ability to profile only specific operations
> ---
>
> Key: IGNITE-13150
> URL: https://issues.apache.org/jira/browse/IGNITE-13150
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Major
> Labels: ise
>
> Provide the ability to profile only specific operations. For example:
> {noformat}
> startProfiling(CACHE_OPERATION, TRANSACTION)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18587) Provide the ability to rollover performance staticstics files
Nikolay Izhikov created IGNITE-18587: Summary: Provide the ability to rollover performance staticstics files Key: IGNITE-18587 URL: https://issues.apache.org/jira/browse/IGNITE-18587 Project: Ignite Issue Type: Sub-task Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov It will be convinient for the user to have ability rollover and study performance statistics files without turning off statistics collection. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18586) Add documentation to REST API
[ https://issues.apache.org/jira/browse/IGNITE-18586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-18586: --- Assignee: Igor Gusev > Add documentation to REST API > - > > Key: IGNITE-18586 > URL: https://issues.apache.org/jira/browse/IGNITE-18586 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > > Currently our REST API documentation is very minimal. We should provide at > least basic descriptions for all parameters and objects, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18586) Add documentation to REST API
Igor Gusev created IGNITE-18586: --- Summary: Add documentation to REST API Key: IGNITE-18586 URL: https://issues.apache.org/jira/browse/IGNITE-18586 Project: Ignite Issue Type: Task Reporter: Igor Gusev Currently our REST API documentation is very minimal. We should provide at least basic descriptions for all parameters and objects, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18236) Cache objects transformation
[
https://issues.apache.org/jira/browse/IGNITE-18236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678611#comment-17678611
]
Ignite TC Bot commented on IGNITE-18236:
{panel:title=Branch: [pull/10393/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10393/head] Base: [master] : New Tests
(27)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 13{color} [[tests
4|https://ci2.ignite.apache.org/viewLog.html?buildId=7004358]]
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationTest.testTransformable[mode=ATOMIC] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationTest.testUntransformable[mode=ATOMIC] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationTest.testTransformable[mode=TRANSACTIONAL] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationTest.testUntransformable[mode=TRANSACTIONAL] -
PASSED{color}
{color:#8b}Cache Objects Compression{color} [[tests
23|https://ci2.ignite.apache.org/viewLog.html?buildId=7004467]]
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testString[mode=THIN_CLIENT] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testIncompressible[mode=THIN_CLIENT] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedString[mode=THIN_CLIENT] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedStringArray[mode=THIN_CLIENT]
- PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedString[mode=PERSISTENT] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedStringArray[mode=PERSISTENT]
- PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedStringBinaryArray[mode=PERSISTENT]
- PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testStringArray[mode=THIN_CLIENT] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionEvolutionTest.test - PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testStringArray[mode=PERSISTENT] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testString[mode=PERSISTENT] -
PASSED{color}
... and 12 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7004461&buildTypeId=IgniteTests24Java8_RunAll]
> Cache objects transformation
>
>
> Key: IGNITE-18236
> URL: https://issues.apache.org/jira/browse/IGNITE-18236
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-97, ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18585) Sql. Introduce cache for serialized RelNodes representation.
Evgeny Stanilovsky created IGNITE-18585: --- Summary: Sql. Introduce cache for serialized RelNodes representation. Key: IGNITE-18585 URL: https://issues.apache.org/jira/browse/IGNITE-18585 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky Assignee: Evgeny Stanilovsky Check ExecutionServiceImpl#prepareFragment, seems it would be useful to cache serialized rel nodes representation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18584) Possible memory errors and corruptions because of insufficient size of compression buffer.
[
https://issues.apache.org/jira/browse/IGNITE-18584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-18584:
-
Affects Version/s: 2.14
> Possible memory errors and corruptions because of insufficient size of
> compression buffer.
> --
>
> Key: IGNITE-18584
> URL: https://issues.apache.org/jira/browse/IGNITE-18584
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Ivan Daschinsky
>Priority: Major
>
> {{org.apache.ignite.internal.processors.compress.CompressionProcessorImpl#compressBuf}}
> is initialized with 1024 extra space, that may be not enough for compressing.
> I.e. snappy requires 2762 extra space for 16K pages.
> The overhead must be calculated during the initialization with help of
> specialized methods, such as
> {{Snappy#maxCompressedLength}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18584) Possible memory errors and corruptions because of insufficient size of compression buffer.
Ivan Daschinsky created IGNITE-18584:
Summary: Possible memory errors and corruptions because of
insufficient size of compression buffer.
Key: IGNITE-18584
URL: https://issues.apache.org/jira/browse/IGNITE-18584
Project: Ignite
Issue Type: Bug
Reporter: Ivan Daschinsky
{{org.apache.ignite.internal.processors.compress.CompressionProcessorImpl#compressBuf}}
is initialized with 1024 extra space, that may be not enough for compressing.
I.e. snappy requires 2762 extra space for 16K pages.
The overhead must be calculated during the initialization with help of
specialized methods, such as
{{Snappy#maxCompressedLength}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18583) C++ 3.0: Add TC suite for C++ tests
Igor Sapego created IGNITE-18583: Summary: C++ 3.0: Add TC suite for C++ tests Key: IGNITE-18583 URL: https://issues.apache.org/jira/browse/IGNITE-18583 Project: Ignite Issue Type: Improvement Components: ignite-3, platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 3.0.0-beta2 We currently have C++ client and tests, but no suites on TC. Need to add TC suites for Windows and Linux (probably for both GCC and Clang). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18582) Bootstrap Configuration: REST should modify conf file
Mikhail Pochatkin created IGNITE-18582: -- Summary: Bootstrap Configuration: REST should modify conf file Key: IGNITE-18582 URL: https://issues.apache.org/jira/browse/IGNITE-18582 Project: Ignite Issue Type: New Feature Components: build Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18581) Bootstrap Configuration: don't save bootstrap configuration
Mikhail Pochatkin created IGNITE-18581: -- Summary: Bootstrap Configuration: don't save bootstrap configuration Key: IGNITE-18581 URL: https://issues.apache.org/jira/browse/IGNITE-18581 Project: Ignite Issue Type: New Feature Components: build Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18580) Sql. Redesign the Exchange to use a pull-based approach
[ https://issues.apache.org/jira/browse/IGNITE-18580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-18580: - Assignee: Konstantin Orlov > Sql. Redesign the Exchange to use a pull-based approach > --- > > Key: IGNITE-18580 > URL: https://issues.apache.org/jira/browse/IGNITE-18580 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Currently, Exchange uses push-based strategy to exchange batches between > different fragments. Such an approach works well for cases of scanning the > whole table, but may cause an unnecessary overhead in cases, where the > smaller amount of rows is expected. For example, for query "SELECT * FROM > table LIMIT 4", IO_BATCH_SIZE * IO_BATCH_COUNT * NODE_COUNT rows will be sent > over network in push-based approach, whereas only 4 * NODE_COUNT will be sent > in pull-based. > Let's redesign Exchange to gain more control over amount of data that is sent > over the network. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18580) Sql. Redesign the Exchange to use a pull-based approach
Konstantin Orlov created IGNITE-18580: - Summary: Sql. Redesign the Exchange to use a pull-based approach Key: IGNITE-18580 URL: https://issues.apache.org/jira/browse/IGNITE-18580 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov Currently, Exchange uses push-based strategy to exchange batches between different fragments. Such an approach works well for cases of scanning the whole table, but may cause an unnecessary overhead in cases, where the smaller amount of rows is expected. For example, for query "SELECT * FROM table LIMIT 4", IO_BATCH_SIZE * IO_BATCH_COUNT * NODE_COUNT rows will be sent over network in push-based approach, whereas only 4 * NODE_COUNT will be sent in pull-based. Let's redesign Exchange to gain more control over amount of data that is sent over the network. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18397) Rework Watches based on learners
[ https://issues.apache.org/jira/browse/IGNITE-18397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-18397: --- Reviewer: Ivan Bessonov > Rework Watches based on learners > > > Key: IGNITE-18397 > URL: https://issues.apache.org/jira/browse/IGNITE-18397 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Current pull-based MetaStorage Watch mechanism should be reworked: every node > in the cluster should be either a peer or a learner of the MetaStorage Raft > group, while listeners will be notified through Raft replication. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18573) DistributedProcess should have an option for waiting client nodes results
[
https://issues.apache.org/jira/browse/IGNITE-18573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678568#comment-17678568
]
Ignite TC Bot commented on IGNITE-18573:
{panel:title=Branch: [pull/10483/head] Base: [master] : Possible Blockers
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 TIMEOUT , Exit Code
, TC_SERVICE_MESSAGE
|https://ci2.ignite.apache.org/viewLog.html?buildId=7004307]]
{color:#d04437}Platform .NET (Windows){color} [[tests 0 TIMEOUT , Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=7004308]]
{color:#d04437}Cache 8{color} [[tests 1 TIMEOUT , Exit Code , Failure on metric
|https://ci2.ignite.apache.org/viewLog.html?buildId=7004246]]
* IgniteCacheTestSuite8: CacheMetricsEntitiesCountTest.testEnitiesCount - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Basic 4{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7004233]]
* IgniteBasicTestSuite2: IgniteDiagnosticMessagesTest.testDiagnosticMessages2 -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Disk Page Compressions 2{color} [[tests 0 JVM CRASH , Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=7004340]]
{panel}
{panel:title=Branch: [pull/10483/head] Base: [master] : New Tests
(28)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
5|https://ci2.ignite.apache.org/viewLog.html?buildId=7004230]]
* {color:#013220}IgniteBasicTestSuite:
DistributedProcessClientAwaitTest.testSkipWaitingFailedClient - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
DistributedProcessClientAwaitTest.testSkipClientResultsByDefault - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
DistributedProcessClientAwaitTest.testAwaitClientResults - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
DistributedProcessClientAwaitTest.testChangedCoordinatorAwaitsClientResult -
PASSED{color}
* {color:#013220}IgniteBasicTestSuite: GridFuncSelfTest.testMapEqNotOrdered -
PASSED{color}
{color:#8b}Disk Page Compressions 1{color} [[tests
11|https://ci2.ignite.apache.org/viewLog.html?buildId=7004339]]
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotTest.testIncrementalSnapshotFailsOnGroupedCacheDestroy[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotTest.testFailIfPreviousIncrementNotAvailable[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteClusterSnapshotWalRecordTest.testClusterSnapshotRecordIsWrittenToSnapshotMetadata[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotTest.testFailForUnknownBaseSnapshot[Encryption=false] -
PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotTest.testFailIfWalCompactionDisabled[Encryption=false] -
PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotTest.testFailIfSegmentNotFound[Encryption=false] -
PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotTest.testCreation[Encryption=false] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotTest.testIncrementalSnapshotFailsOnTopologyChange[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotTest.testIncrementalSnapshotFailsOnCacheDestroy[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotTest.testIncrementalSnapshotFailsOnCacheChange[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotTest.testIncrementalSnapshotFailOnDirtyDir[Encryption=false]
- PASSED{color}
... and 0 new tests
{color:#8b}Snapshots{color} [[tests
12|https://ci2.ignite.apache.org/viewLog.html?buildId=7004320]]
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotTest.testCreation[Encryption=false] - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotWalRecordTest.testClusterSnapshotRecordIsWrittenToSnapshotMetadata[Encryption=true]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotWalRecordTest.testClusterSnapshotRecordIsWrittenToSnapshotMetadata[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotTest.testIncrementalSnapshotFailsOnCacheDestroy[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotTest.testIncrementalSnapshotFailsOnCacheChange[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotTest.testIncrementalSnapshotFailOnDirtyDir[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotTest.testFailForUnk
[jira] [Updated] (IGNITE-17602) Trace identifier of an exception can be lost during transferring ReplicaRespone from replica node to ReplicaService
[
https://issues.apache.org/jira/browse/IGNITE-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17602:
-
Fix Version/s: 3.0.0-beta1
> Trace identifier of an exception can be lost during transferring
> ReplicaRespone from replica node to ReplicaService
> ---
>
> Key: IGNITE-17602
> URL: https://issues.apache.org/jira/browse/IGNITE-17602
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> Current implementation of processing _ReplicaResponse_ has the following
> drawbacks:
> - if sending _ReplicaRequest_ failed for some reason, _ReplicaService_ just
> throw new exception without preserving traceId if it exists
> {code:java}
> return messagingService.invoke(node.address(), req,
> RPC_TIMEOUT).handle((response, throwable) -> {
> if (throwable != null) {
> if (throwable instanceof TimeoutException) {
> throw new ReplicationTimeoutException(req.groupId());
> } else if (throwable instanceof PrimaryReplicaMissException) {
> throw (PrimaryReplicaMissException) throwable;
> }
> throw new ReplicationException(req.groupId(), throwable); <- original
> traceId will be lost
> {code}
> - _ErrorReplicaResponse_ explicitly transfer error code of an exception, its
> traceId etc. It seems to me, we can just transfer an exception (our messaging
> service properly marshal/unmarshal throwables)
> - _org.apache.ignite.internal.replicator.exception.ExceptionUtils_ does not
> care about _IgniteInternalChackedException_. For instance _LockException_
> (which is checked exception) is transformed to _IgniteInternalException_.
> In addition, _TransactionImpl_ does not properly handle _ExecutionException_:
> {code:java}
> @Override
> public void commit() throws TransactionException {
> try {
> commitAsync().get();
> } catch (ExecutionException e) {
> if (e.getCause() instanceof TransactionException) {
> throw (TransactionException) e.getCause();
> } else {
> throw new TransactionException(e.getCause());
> }
> } catch (Exception e) {
> throw new TransactionException(e);
> }
> }
> {code}
> We should not re-throw _e.getCause()_ because we will lost a stack frame
> related to _ExecutionException_, and therefore the resulting stack trace will
> not show a code path/method that called _commit()_.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18132) Introduce scale down scheduler
[
https://issues.apache.org/jira/browse/IGNITE-18132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-18132:
Assignee: Mirza Aliev
> Introduce scale down scheduler
> --
>
> Key: IGNITE-18132
> URL: https://issues.apache.org/jira/browse/IGNITE-18132
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Surprisingly it's a follow up of an Introduce scale up scheduler
> Following logic should be implemented
> |-1|start Node A;
> start Node B;
> start Node C;
> CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_{*}SCALE_UP{*} = 300,
> DATA_NODES_AUTO_ADJUST_{*}SCALE_DOWN{*}= 300_000;
> CREATE TABLE Accounts … WITH PRIMARY_ZONE = zone1 |User starts three Ignite
> nodes A, B, C and creates table Accounts specifying scale up auto adjust
> timeout as 300 seconds. Accounts table is created on current topology,
> meaning that .dataNodes = [A,B,C]|
> |0|start Node D ->
> Node D join/validation ->
> D enters logical topology ->
> logicalTopology.onNodeAdded(Node D) ->
> scale_up_auto_adjust(300) timer is
> scheduled for the table.|At time 0 seconds the user starts one
> more Ignite node D, that joins the cluster. On entering logical topology the
> onNodeAdded event is fired. This event, schedules a timer of 300 seconds for
> table Accounts after which the dataNodes of that table will be recalculated
> from [A,B,C] to [A,B,C,D]|
> |100|stop Node C ->
> scale_{*}down{*}_auto_adjust(300_000) timer
> is scheduled for the table.|At 100 seconds the user stops Node
> C (or it painfully dies). TableManager detects onNodeLeft(Node C) event and
> starts scale_down time for 300_000 seconds for table . Please pay
> attention that the node left doesn’t affect the scale_up timer.|
> |250|start Node E ->
> scale_up_auto_adjust(300) timer is
> {*}re-{*}scheduled for the table.|At 250 seconds Node E is
> added, that re-schedules scale_up_auto_adjust timer for another 300 seconds.
> The important part here is that adding the node doesn’t change scale_down
> time only scale_up one.|
> |550|scale_up_auto_adjust fired ->
> set table..dataNodes =
> [NodeA, NodeB, {*}NodeC{*}, Node D, Node E]|At 550 seconds scale_up_time
> is fired, that leads to dataNodes recalculation by attaching the
> nodes that were added to logical topology - Nodes D and E in the given
> example. Please pay attention that despite the fact there's no Node C in
> logical topology it still takes its place in .dataNodes. |
> |300100|*scale_down_auto_adjust fired* ->
> set table..dataNodes =
> [NodeA, NodeB, Node D, Node E]|At 300_100 seconds scale_down_auto_adjust
> timer is fired, that leads to removing Node C from .dataNodes.|
> h3. Definition of Done
> * DataNodes recalculation transitively triggered by node left event is
> delayed for dataNodesAutoAdjustScale{*}Down{*} value.
> * In case of new scale down toplogy event, existing scale down timers should
> be re-scheduled.
> * Scale up timers should not be affected.
> h3. Implementation Notes
> As as for scale up.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17817) Update ItTablePersistenceTest to use Replica layer with new transaction protocol
[ https://issues.apache.org/jira/browse/IGNITE-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-17817: Assignee: Denis Chudov > Update ItTablePersistenceTest to use Replica layer with new transaction > protocol > > > Key: IGNITE-17817 > URL: https://issues.apache.org/jira/browse/IGNITE-17817 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > The ItTablePersistenceTest is disabled. Need to update ItTablePersistenceTest > to use Replica layer with new transaction protocol. Now components (for > example TxStateTableStorage, ReplicaService) of InternalTableImpl and > TxManagerImpl are mocked or null. > Also ItTablePersistenceTest cannot be enabled because MvPartitionStorage > hasn't supported snapshots yet > https://issues.apache.org/jira/browse/IGNITE-16644 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18358) IGN-TX-5 on concurrent transactional single key load
[
https://issues.apache.org/jira/browse/IGNITE-18358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-18358:
--
Assignee: Vladislav Pyatkov
> IGN-TX-5 on concurrent transactional single key load
>
>
> Key: IGNITE-18358
> URL: https://issues.apache.org/jira/browse/IGNITE-18358
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0.0-beta1
>Reporter: Alexander Belyak
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> On a single node (embedded) cluster I get
>
> {noformat}
> java.util.concurrent.ExecutionException: java.lang.Exception:
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:3c65b23f-95ee-4226-a929-7f7aefd17e16 Failed to acquire a lock due to
> a conflict [txId=000e3ab5-de28--f1d3-67fae4082a69, waiter=WaiterImpl
> [txId=000e3ab5-de29--f1d3-67fae4082a69, upgraded=false,
> prevLockMode=null, lockMode=S, locked=true, isDone=true]] at
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
> at
> org.gridgain.poc.framework.starter.Ignite3StarterTest.test(Ignite3StarterTest.java:110)
> at
> org.gridgain.poc.framework.starter.Ignite3StarterTest.startSingleNodeTest(Ignite3StarterTest.java:65)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursiv
