[jira] [Updated] (IGNITE-18874) Add a JUnit extension for stopping all Ignites after test suite finishes
[ https://issues.apache.org/jira/browse/IGNITE-18874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-18874: --- Description: It would be nice to have an automatically-registered extension that would stop all Ignite nodes started by a test suite (but which were not stopped for some reason). This might make our builds more stable decreasing the probability of a process hanging forever after a build, impeding other builds (as ports remain busy). > Add a JUnit extension for stopping all Ignites after test suite finishes > > > Key: IGNITE-18874 > URL: https://issues.apache.org/jira/browse/IGNITE-18874 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > It would be nice to have an automatically-registered extension that would > stop all Ignite nodes started by a test suite (but which were not stopped for > some reason). This might make our builds more stable decreasing the > probability of a process hanging forever after a build, impeding other builds > (as ports remain busy). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18947) Unify integration tests in runner module
Roman Puchkovskiy created IGNITE-18947:
--
Summary: Unify integration tests in runner module
Key: IGNITE-18947
URL: https://issues.apache.org/jira/browse/IGNITE-18947
Project: Ignite
Issue Type: Improvement
Reporter: Roman Puchkovskiy
Fix For: 3.0.0-beta2
We want to make sure that all Ignite instances started by a test get stopped
after the test stuite stops, regardless of the tests outcome.
IGNITE-18874 introduces a JUnit extension that performs such a cleanup. We want
to make sure that any integration test (running Ignite instances) in the runner
module gets executed with this extension. The current approach of IGNITE-18874
is to make this extension register automatically, but such an automatic
registration brings a problem: WorkDirectoryExtension's after/after-all methods
remove directories before the cleanup extension stops Ignite instances, which
is weird.
The best thing would be to make sure that we always register this extension
explicitly (declaratively) for each test that needs it.
It is suggested to add one (or a couple) of base classes registering the
extension, so that each integration test class in the runner module extends one
of them.
# IGNITE-18874 already introduces {{TestStartingIgnites}} that is used as a
base of most of the mentioned tests
# We should migrate tests extending {{IgniteAbstractTest}} to the same
approach (make {{IgniteAbstractTest}} one of the base classes mentioned above,
or make it extend one of these classes, or...)
# Make sure that every single test class that can start ignites in the runner
module extends one of the mentioned base classes
# Make sure that build fails if there is such non-complying test classes (not
clear yet how do achieve this)
# Maybe it makes sense to unify how we write test classes in the runner
module. Currently, there seems to be 2 approaches: in one, a shared cluster is
started for all tests; in another, a cluster is started per test. Both
approaches have pros and cons. Maybe we should leave both of them (in
IGNITE-18874, the corresponding base classes are renamed to reflect this
shared/per-test distinction).
We should also probably think whether we should leave the automatic
registration of the cleanup extension after the measures described in this
issue. Probably we should, just in case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18723) ClientArchTest should check client dependencies
[ https://issues.apache.org/jira/browse/IGNITE-18723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-18723: -- Fix Version/s: 3.0.0-beta2 > ClientArchTest should check client dependencies > --- > > Key: IGNITE-18723 > URL: https://issues.apache.org/jira/browse/IGNITE-18723 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > ClientArchTest should check not only client source code but also all depended > Ignite modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18723) ClientArchTest should check client dependencies
[ https://issues.apache.org/jira/browse/IGNITE-18723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-18723: -- Ignite Flags: (was: Docs Required,Release Notes Required) > ClientArchTest should check client dependencies > --- > > Key: IGNITE-18723 > URL: https://issues.apache.org/jira/browse/IGNITE-18723 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > ClientArchTest should check not only client source code but also all depended > Ignite modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18946) Fix 'REFRESH' command about statistics in the ddl doc
[ https://issues.apache.org/jira/browse/IGNITE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696027#comment-17696027 ] Chenjian commented on IGNITE-18946: --- noted,thanks Aleksey Plekhanov (Jira) 于2023年3月3日 周五下午2:05写道： > Fix 'REFRESH' command about statistics in the ddl doc > - > > Key: IGNITE-18946 > URL: https://issues.apache.org/jira/browse/IGNITE-18946 > Project: Ignite > Issue Type: Bug >Reporter: Chenjian >Assignee: Chenjian >Priority: Trivial > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Fix doc about the 'REFRESH' command about the STATISTICS, > see [https://ignite.apache.org/docs/2.14.0/sql-reference/ddl#refresh] > the command should be 'REFRESH STATISTICS' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18946) Fix 'REFRESH' command about statistics in the ddl doc
[ https://issues.apache.org/jira/browse/IGNITE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chenjian updated IGNITE-18946: -- Summary: Fix 'REFRESH' command about statistics in the ddl doc (was: Fix 'REFRESH' command demos in the ddl doc) > Fix 'REFRESH' command about statistics in the ddl doc > - > > Key: IGNITE-18946 > URL: https://issues.apache.org/jira/browse/IGNITE-18946 > Project: Ignite > Issue Type: Bug >Reporter: Chenjian >Assignee: Chenjian >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > Fix doc about the 'REFRESH' command about the STATISTICS, > see [https://ignite.apache.org/docs/2.14.0/sql-reference/ddl#refresh] > the command should be 'REFRESH STATISTICS' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18388) Ignite drop then add same column has the wrong sematic
[ https://issues.apache.org/jira/browse/IGNITE-18388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chenjian updated IGNITE-18388: -- Priority: Minor (was: Major) > Ignite drop then add same column has the wrong sematic > --- > > Key: IGNITE-18388 > URL: https://issues.apache.org/jira/browse/IGNITE-18388 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.9, 2.10, 2.11, 2.12, 2.13, 2.14 >Reporter: Chenjian >Assignee: Chenjian >Priority: Minor > Attachments: image-2022-12-13-15-43-58-095.png > > > Dropped the column then added the column with the same name, the value about > the column backend which should not. > Steps to reproduce: > * create table t(id int primary key, x int, y int) > * insert into t values (1, 2, 3) > * select * from t. The result shows as expected 1, 2, 3 > * alter table drop column x. > * select * from t. The result shows as expected 1,3 > * alter table add column x int. > * select * from t. *The result shows NOT as expected 1,3,2. which should > 1,3,NULL.* > > !image-2022-12-13-15-43-58-095.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18946) Fix 'REFRESH' command demos in the ddl doc
Chenjian created IGNITE-18946: - Summary: Fix 'REFRESH' command demos in the ddl doc Key: IGNITE-18946 URL: https://issues.apache.org/jira/browse/IGNITE-18946 Project: Ignite Issue Type: Bug Reporter: Chenjian Fix doc about the 'REFRESH' command about the STATISTICS, see [https://ignite.apache.org/docs/2.14.0/sql-reference/ddl#refresh] the command should be 'REFRESH STATISTICS' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18946) Fix 'REFRESH' command demos in the ddl doc
[ https://issues.apache.org/jira/browse/IGNITE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chenjian updated IGNITE-18946: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Fix 'REFRESH' command demos in the ddl doc > -- > > Key: IGNITE-18946 > URL: https://issues.apache.org/jira/browse/IGNITE-18946 > Project: Ignite > Issue Type: Bug >Reporter: Chenjian >Priority: Trivial > > Fix doc about the 'REFRESH' command about the STATISTICS, > see [https://ignite.apache.org/docs/2.14.0/sql-reference/ddl#refresh] > the command should be 'REFRESH STATISTICS' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18946) Fix 'REFRESH' command demos in the ddl doc
[ https://issues.apache.org/jira/browse/IGNITE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chenjian reassigned IGNITE-18946: - Assignee: Chenjian > Fix 'REFRESH' command demos in the ddl doc > -- > > Key: IGNITE-18946 > URL: https://issues.apache.org/jira/browse/IGNITE-18946 > Project: Ignite > Issue Type: Bug >Reporter: Chenjian >Assignee: Chenjian >Priority: Trivial > > Fix doc about the 'REFRESH' command about the STATISTICS, > see [https://ignite.apache.org/docs/2.14.0/sql-reference/ddl#refresh] > the command should be 'REFRESH STATISTICS' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18546) Add cache clear command to control.sh
[ https://issues.apache.org/jira/browse/IGNITE-18546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18546: Fix Version/s: 2.15 > Add cache clear command to control.sh > -- > > Key: IGNITE-18546 > URL: https://issues.apache.org/jira/browse/IGNITE-18546 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.15 > > > IgniteCache provides a functionality for clearing cache (IgniteCache#clear). > Users might want clear cache for test purposes by remote job (Jenkins, etc.). > Then it will be useful to provide opportunity to clean cache by control.sh > util. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18546) Add cache clear command to control.sh
[ https://issues.apache.org/jira/browse/IGNITE-18546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18546: Description: IgniteCache provides a functionality for clearing cache (IgniteCache#clear). Users might want clear cache for test purposes by remote job (Jenkins, etc.). Then it will be useful to provide opportunity to clean cache by control.sh util. was: IgniteCache provides a functionality for cleaning cache (IgniteCache#clean). Users might want clear cache for test purposes by remote job (Jenkins, etc.). Then it will be useful to provide opportunity to clean cache by control.sh util. > Add cache clear command to control.sh > -- > > Key: IGNITE-18546 > URL: https://issues.apache.org/jira/browse/IGNITE-18546 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > > IgniteCache provides a functionality for clearing cache (IgniteCache#clear). > Users might want clear cache for test purposes by remote job (Jenkins, etc.). > Then it will be useful to provide opportunity to clean cache by control.sh > util. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18546) Add cache clear command to control.sh
[ https://issues.apache.org/jira/browse/IGNITE-18546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18546: Summary: Add cache clear command to control.sh (was: Cache clean control.sh command ) > Add cache clear command to control.sh > -- > > Key: IGNITE-18546 > URL: https://issues.apache.org/jira/browse/IGNITE-18546 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > > IgniteCache provides a functionality for cleaning cache (IgniteCache#clean). > Users might want clear cache for test purposes by remote job (Jenkins, etc.). > Then it will be useful to provide opportunity to clean cache by control.sh > util. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18945) Add an ability to extend control-utility without modification of Ignite code
[ https://issues.apache.org/jira/browse/IGNITE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18945: --- Description: Currently, control.sh utility can't be extended with the new commands without modification of Ignite code. It's required sometimes to have an additional tools for cluster management. It will be useful if user has an ability to extend control-utility with the new commands instead of creating own tools with boilerplate code. was: Currently, control.sh utility can't be extended with new commands without modification of Ignite code. It's required sometimes to have an additional tools for cluster management. It will be useful if user has an ability to extend control-utility with the new commands instead of creating own tools with boilerplate code. > Add an ability to extend control-utility without modification of Ignite code > > > Key: IGNITE-18945 > URL: https://issues.apache.org/jira/browse/IGNITE-18945 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > Currently, control.sh utility can't be extended with the new commands without > modification of Ignite code. > It's required sometimes to have an additional tools for cluster management. > It will be useful if user has an ability to extend control-utility with the > new commands instead of creating own tools with boilerplate code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18945) Add an ability to extend control-utility without modification of Ignite code
[ https://issues.apache.org/jira/browse/IGNITE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18945: --- Summary: Add an ability to extend control-utility without modification of Ignite code (was: Add ability to extend control-utility without modification of Ignite code) > Add an ability to extend control-utility without modification of Ignite code > > > Key: IGNITE-18945 > URL: https://issues.apache.org/jira/browse/IGNITE-18945 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > Currently, control.sh utility can't be extended with new commands without > modification of Ignite code. > It's required sometimes to have an additional tools for cluster management. > It will be useful if user has an ability to extend control-utility with the > new commands instead of creating own tools with boilerplate code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18945) Add ability to extend control-utility without modification of Ignite code
Aleksey Plekhanov created IGNITE-18945: -- Summary: Add ability to extend control-utility without modification of Ignite code Key: IGNITE-18945 URL: https://issues.apache.org/jira/browse/IGNITE-18945 Project: Ignite Issue Type: Improvement Components: control.sh Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currently, control.sh utility can't be extended with new commands without modification of Ignite code. It's required sometimes to have an additional tools for cluster management. It will be useful if user has an ability to extend control-utility with the new commands instead of creating own tools with boilerplate code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18754) Sql. Jdbc. ItJdbcResultSetSelfTest#testTimestamp fails locally but works on CI
[
https://issues.apache.org/jira/browse/IGNITE-18754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18754:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Jdbc. ItJdbcResultSetSelfTest#testTimestamp fails locally but works on CI
> --
>
> Key: IGNITE-18754
> URL: https://issues.apache.org/jira/browse/IGNITE-18754
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> 2023-02-02 20:06:47:409 +0400 [INFO][Test worker][ItJdbcResultSetSelfTest]
> >>> Stopping test: ItJdbcResultSetSelfTest#testTimestamp, displayName:
> testTimestamp(), cost: 58ms.
> expected: <-1080> but was: <-1440>
> Expected :-1080
> Actual :-1440
> at
> app//org.apache.ignite.jdbc.ItJdbcResultSetSelfTest.testTimestamp(ItJdbcResultSetSelfTest.java:551)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18754) Sql. Jdbc. ItJdbcResultSetSelfTest#testTimestamp fails locally but works on CI
[
https://issues.apache.org/jira/browse/IGNITE-18754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev reassigned IGNITE-18754:
Assignee: Aleksandr Polovtcev
> Sql. Jdbc. ItJdbcResultSetSelfTest#testTimestamp fails locally but works on CI
> --
>
> Key: IGNITE-18754
> URL: https://issues.apache.org/jira/browse/IGNITE-18754
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> 2023-02-02 20:06:47:409 +0400 [INFO][Test worker][ItJdbcResultSetSelfTest]
> >>> Stopping test: ItJdbcResultSetSelfTest#testTimestamp, displayName:
> testTimestamp(), cost: 58ms.
> expected: <-1080> but was: <-1440>
> Expected :-1080
> Actual :-1440
> at
> app//org.apache.ignite.jdbc.ItJdbcResultSetSelfTest.testTimestamp(ItJdbcResultSetSelfTest.java:551)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18944) Authentication provider names should be autogenerated
Ivan Gagarkin created IGNITE-18944: -- Summary: Authentication provider names should be autogenerated Key: IGNITE-18944 URL: https://issues.apache.org/jira/browse/IGNITE-18944 Project: Ignite Issue Type: Improvement Reporter: Ivan Gagarkin Currently, there is no way to auto-generate names for @NamedConfigValue. It's worth creating a such mechanism and using it for AuthenticationProviderConfigurationSchema -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18943) Block REST calls till the authentication is enabled
Ivan Gagarkin created IGNITE-18943: -- Summary: Block REST calls till the authentication is enabled Key: IGNITE-18943 URL: https://issues.apache.org/jira/browse/IGNITE-18943 Project: Ignite Issue Type: Task Components: rest Reporter: Ivan Gagarkin The authentication will be enabled after the cluster initialization. It's the async process and it can be delayed. We need to think about how we can block all REST calls till that moment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18936) [ducktests] Fix parse of the control.sh --baseline output
[ https://issues.apache.org/jira/browse/IGNITE-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov reassigned IGNITE-18936: Assignee: Sergey Korotkov > [ducktests] Fix parse of the control.sh --baseline output > - > > Key: IGNITE-18936 > URL: https://issues.apache.org/jira/browse/IGNITE-18936 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Time Spent: 10m > Remaining Estimate: 0h > > Currently the output of the control.sh --baseline is parsed in a wrong way. > In particular the baseline node state can not be obtained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18942) Reactor library version conflict
[ https://issues.apache.org/jira/browse/IGNITE-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18942: --- Description: Scalecube and Micraonaut use different versions of the Reactor library - 3.5.0 and 3.4.9. Right now gradle uses the new one. But maybe it's worth shadowing one of them to avoid that conflict. We have to think and resolve it till the GA. https://lists.apache.org/thread/msh2q0g121lhcxmvdx15ks353dv03j4r was: Scalecube and Micraonaut use different versions of the Reactor library - 3.5.0 and 3.4.9. Right now gradle uses the new one. But maybe it's worth shadowing one of them to avoid that conflict. We have to think and resolve it till the GA. https://lists.apache.org/list.html?d...@ignite.apache.org > Reactor library version conflict > > > Key: IGNITE-18942 > URL: https://issues.apache.org/jira/browse/IGNITE-18942 > Project: Ignite > Issue Type: Task > Components: rest >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Scalecube and Micraonaut use different versions of the Reactor library - > 3.5.0 and 3.4.9. > Right now gradle uses the new one. > But maybe it's worth shadowing one of them to avoid that conflict. > We have to think and resolve it till the GA. > https://lists.apache.org/thread/msh2q0g121lhcxmvdx15ks353dv03j4r -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18942) Reactor library version conflict
[ https://issues.apache.org/jira/browse/IGNITE-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18942: --- Component/s: rest > Reactor library version conflict > > > Key: IGNITE-18942 > URL: https://issues.apache.org/jira/browse/IGNITE-18942 > Project: Ignite > Issue Type: Task > Components: rest >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Scalecube and Micraonaut use different versions of the Reactor library - > 3.5.0 and 3.4.9. > Right now gradle uses the new one. > But maybe it's worth shadowing one of them to avoid that conflict. > We have to think and resolve it till the GA. > https://lists.apache.org/list.html?d...@ignite.apache.org -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18942) Reactor library version conflict
[ https://issues.apache.org/jira/browse/IGNITE-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18942: --- Description: Scalecube and Micraonaut use different versions of the Reactor library - 3.5.0 and 3.4.9. Right now gradle uses the new one. But maybe it's worth shadowing one of them to avoid that conflict. We have to think and resolve it till the GA. https://lists.apache.org/list.html?d...@ignite.apache.org was: Scalecube and Micraonaut use different versions of the Reactor library - 3.5.0 and 3.4.9. Right now gradle uses the new one. But maybe it's worth shadowing one of them to avoid that conflict. We have to think and resolve it till the GA. > Reactor library version conflict > > > Key: IGNITE-18942 > URL: https://issues.apache.org/jira/browse/IGNITE-18942 > Project: Ignite > Issue Type: Task >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Scalecube and Micraonaut use different versions of the Reactor library - > 3.5.0 and 3.4.9. > Right now gradle uses the new one. > But maybe it's worth shadowing one of them to avoid that conflict. > We have to think and resolve it till the GA. > https://lists.apache.org/list.html?d...@ignite.apache.org -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18942) Reactor library version conflict
Ivan Gagarkin created IGNITE-18942: -- Summary: Reactor library version conflict Key: IGNITE-18942 URL: https://issues.apache.org/jira/browse/IGNITE-18942 Project: Ignite Issue Type: Task Reporter: Ivan Gagarkin Scalecube and Micraonaut use different versions of the Reactor library - 3.5.0 and 3.4.9. Right now gradle uses the new one. But maybe it's worth shadowing one of them to avoid that conflict. We have to think and resolve it till the GA. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18731) CLI command for deployment units
[ https://issues.apache.org/jira/browse/IGNITE-18731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-18731: -- Assignee: Aleksandr > CLI command for deployment units > > > Key: IGNITE-18731 > URL: https://issues.apache.org/jira/browse/IGNITE-18731 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18674) Introduce UI thread to CLI
[ https://issues.apache.org/jira/browse/IGNITE-18674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695751#comment-17695751 ] Aleksandr commented on IGNITE-18674: merged into main: d8885b22d05231af53996ace5bbf9fb0564bedc9 > Introduce UI thread to CLI > -- > > Key: IGNITE-18674 > URL: https://issues.apache.org/jira/browse/IGNITE-18674 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Time Spent: 1h > Remaining Estimate: 0h > > The current SQL query completion process may obstruct the UI thread and > result in CLI hang-ups when Ignite 3 node fails to respond. > To prevent this issue, we need to implement a separate UI thread for all > user-facing operations with a maximum block time of 5-10 seconds. The CLI > must be protected from indefinite hang-ups at all times, regardless of Ignite > 3 node behavior. To accomplish this, we should adopt a single UI thread and > worker pool design with asynchronous communication, allowing the UI thread to > receive notifications without being blocked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18069) Check incremental snapshot meta
[
https://issues.apache.org/jira/browse/IGNITE-18069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695749#comment-17695749
]
Ignite TC Bot commented on IGNITE-18069:
{panel:title=Branch: [pull/10364/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7043030]]
* DotNetCore: ThickExamplesTest.TestThickExample(Services) - Test has low fail
rate in base branch 1,6% and is not flaky
{panel}
{panel:title=Branch: [pull/10364/head] Base: [master] : New Tests
(20)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Snapshots{color} [[tests
10|https://ci2.ignite.apache.org/viewLog.html?buildId=7043040]]
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testIncrementalIndexMismatch[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testIntermediateWalSegmentNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testNoFullSnapshotMetaNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testFirstWalSegmentNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testNonExistentIncrementalSnapshot[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testNoIncrementalSnapshotMetaNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testCheckCorrectIncrementalSnapshot[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testWalSegmentsNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testLastWalSegmentNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testIntermediateSnapshotNotFound[Encryption=false]
- PASSED{color}
{color:#8b}Disk Page Compressions 1{color} [[tests
10|https://ci2.ignite.apache.org/viewLog.html?buildId=7043036]]
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testIncrementalIndexMismatch[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testIntermediateWalSegmentNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testNoFullSnapshotMetaNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testFirstWalSegmentNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testNonExistentIncrementalSnapshot[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testNoIncrementalSnapshotMetaNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testCheckCorrectIncrementalSnapshot[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testWalSegmentsNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testLastWalSegmentNotFound[Encryption=false]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotCheckBeforeRestoreTest.testIntermediateSnapshotNotFound[Encryption=false]
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7041843buildTypeId=IgniteTests24Java8_RunAll]
> Check incremental snapshot meta
> ---
>
> Key: IGNITE-18069
> URL: https://issues.apache.org/jira/browse/IGNITE-18069
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-89
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Incremental snapshot must be checked before restoring:
> # IS matches base snapshot (checks meta files).
> # All previous incremental snapshot exists.
> # All WAL segments are present.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18069) Check incremental snapshot meta
[ https://issues.apache.org/jira/browse/IGNITE-18069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18069: Summary: Check incremental snapshot meta (was: Check incremental snapshot before restoring it) > Check incremental snapshot meta > --- > > Key: IGNITE-18069 > URL: https://issues.apache.org/jira/browse/IGNITE-18069 > Project: Ignite > Issue Type: Sub-task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89 > Time Spent: 10m > Remaining Estimate: 0h > > Incremental snapshot must be checked before restoring: > # IS matches base snapshot (checks meta files). > # All previous incremental snapshot exists. > # All WAL segments are present. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18882) Fix tombstone is stored if it is the first entry of version chain
[
https://issues.apache.org/jira/browse/IGNITE-18882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695689#comment-17695689
]
Kirill Tkalenko commented on IGNITE-18882:
--
Looks good!
> Fix tombstone is stored if it is the first entry of version chain
> -
>
> Key: IGNITE-18882
> URL: https://issues.apache.org/jira/browse/IGNITE-18882
> Project: Ignite
> Issue Type: Bug
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This test in AbstractMvPartitionStorageGcTest should pass
> {code:java}
> void testTombstoneFirst() {
> addAndCommit(null);
> addAndCommit(TABLE_ROW);
> addAndCommit(TABLE_ROW2);
> BinaryRowAndRowId row = pollForVacuum(HybridTimestamp.MAX_VALUE);
> assertRowMatches(row.binaryRow(), TABLE_ROW);
> }
> {code}
> At this moment, storages will store the tombstone if it is the first
> committed value which disrupts the GC flow.
> addWrite with null argument as a first version of row is valid, for example:
> {code:sql}
> CREATE TABLE test (
> id INT
> );
> BEGIN;
> INSERT INTO test VALUES(1);
> DELETE from test where id = 1;
> COMMIT;
> {code}
> is ok, but tombstone should not be stored (so the operation should be no-op)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18851) .NET: Thin 3.0: TestReconnectAfterFullClusterRestart is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695681#comment-17695681
]
Pavel Tupitsyn commented on IGNITE-18851:
-
Merged to main: 3f9f532e8f6e2a59b98e58bac62def51904b51bf
> .NET: Thin 3.0: TestReconnectAfterFullClusterRestart is flaky
> -
>
> Key: IGNITE-18851
> URL: https://issues.apache.org/jira/browse/IGNITE-18851
> 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
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> Condition not reached after 00:00:03.0086244
>at Apache.Ignite.Tests.TestUtils.WaitForCondition(Func`1 condition, Int32
> timeoutMs, Func`1 messageFactory) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/TestUtils.cs:line
> 62
>at
> Apache.Ignite.Tests.ReconnectTests.TestReconnectAfterFullClusterRestart() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/ReconnectTests.cs:line
> 156
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Execution.SimpleWorkItem.<>c__DisplayClass4_0.b__0()
>at
> NUnit.Framework.Internal.ContextUtils.<>c__DisplayClass1_0`1.b__0(Object
> _)
> 1)at Apache.Ignite.Tests.TestUtils.WaitForCondition(Func`1 condition,
> Int32 timeoutMs, Func`1 messageFactory) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/TestUtils.cs:line
> 62
>at
> Apache.Ignite.Tests.ReconnectTests.TestReconnectAfterFullClusterRestart() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/ReconnectTests.cs:line
> 156
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7088557?hideProblemsFromDependencies=false=false=true=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18851) .NET: Thin 3.0: TestReconnectAfterFullClusterRestart is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695680#comment-17695680
]
Igor Sapego commented on IGNITE-18851:
--
[~ptupitsyn] Looks good to me.
> .NET: Thin 3.0: TestReconnectAfterFullClusterRestart is flaky
> -
>
> Key: IGNITE-18851
> URL: https://issues.apache.org/jira/browse/IGNITE-18851
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> Condition not reached after 00:00:03.0086244
>at Apache.Ignite.Tests.TestUtils.WaitForCondition(Func`1 condition, Int32
> timeoutMs, Func`1 messageFactory) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/TestUtils.cs:line
> 62
>at
> Apache.Ignite.Tests.ReconnectTests.TestReconnectAfterFullClusterRestart() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/ReconnectTests.cs:line
> 156
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Execution.SimpleWorkItem.<>c__DisplayClass4_0.b__0()
>at
> NUnit.Framework.Internal.ContextUtils.<>c__DisplayClass1_0`1.b__0(Object
> _)
> 1)at Apache.Ignite.Tests.TestUtils.WaitForCondition(Func`1 condition,
> Int32 timeoutMs, Func`1 messageFactory) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/TestUtils.cs:line
> 62
>at
> Apache.Ignite.Tests.ReconnectTests.TestReconnectAfterFullClusterRestart() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/ReconnectTests.cs:line
> 156
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7088557?hideProblemsFromDependencies=false=false=true=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18941) .NET: Thin 3.0: Implement IgniteDeployment APIs
Pavel Tupitsyn created IGNITE-18941: --- Summary: .NET: Thin 3.0: Implement IgniteDeployment APIs Key: IGNITE-18941 URL: https://issues.apache.org/jira/browse/IGNITE-18941 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Implement IgniteDeployment APIs in .NET client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18940) Java thin 3.0: Implement IgniteDeployment APIs
[ https://issues.apache.org/jira/browse/IGNITE-18940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18940: Component/s: thin client > Java thin 3.0: Implement IgniteDeployment APIs > -- > > Key: IGNITE-18940 > URL: https://issues.apache.org/jira/browse/IGNITE-18940 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Implement *IgniteDeployment* interface in Java client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18940) Java thin 3.0: Implement IgniteDeployment APIs
Pavel Tupitsyn created IGNITE-18940: --- Summary: Java thin 3.0: Implement IgniteDeployment APIs Key: IGNITE-18940 URL: https://issues.apache.org/jira/browse/IGNITE-18940 Project: Ignite Issue Type: Improvement Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Implement *IgniteDeployment* interface in Java client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18882) Fix tombstone is stored if it is the first entry of version chain
[
https://issues.apache.org/jira/browse/IGNITE-18882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-18882:
-
Reviewer: Kirill Tkalenko
> Fix tombstone is stored if it is the first entry of version chain
> -
>
> Key: IGNITE-18882
> URL: https://issues.apache.org/jira/browse/IGNITE-18882
> Project: Ignite
> Issue Type: Bug
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This test in AbstractMvPartitionStorageGcTest should pass
> {code:java}
> void testTombstoneFirst() {
> addAndCommit(null);
> addAndCommit(TABLE_ROW);
> addAndCommit(TABLE_ROW2);
> BinaryRowAndRowId row = pollForVacuum(HybridTimestamp.MAX_VALUE);
> assertRowMatches(row.binaryRow(), TABLE_ROW);
> }
> {code}
> At this moment, storages will store the tombstone if it is the first
> committed value which disrupts the GC flow.
> addWrite with null argument as a first version of row is valid, for example:
> {code:sql}
> CREATE TABLE test (
> id INT
> );
> BEGIN;
> INSERT INTO test VALUES(1);
> DELETE from test where id = 1;
> COMMIT;
> {code}
> is ok, but tombstone should not be stored (so the operation should be no-op)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18935) Late stopping of TTL workers during deactivation leads to corrupted PDS
[
https://issues.apache.org/jira/browse/IGNITE-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-18935:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Late stopping of TTL workers during deactivation leads to corrupted PDS
> ---
>
> Key: IGNITE-18935
> URL: https://issues.apache.org/jira/browse/IGNITE-18935
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Step to reproduce
> 1. Reduce wal history size and wal segment size to 16MB and 8MB respectively,
> set checkpoint frequency to 1
> 2. Perform heavy load with a lot of entries with TTL 5000 and with eager ttl
> enabled
> 3. Perform deactivation of cluster, stop grid and restart, provided that an
> expiration process is active during the process of restart.
> {code}
> [15:11:58,022][SEVERE][ttl-cleanup-worker-#52%None%][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [groupId=-459905951, pageIds=[], msg=Runtime failure on bounds:
> [lower=null, upper=PendingRow []
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [groupId=-459905951, pageIds=[], msg=Runtime failure on
> bounds: [lower=null, upper=PendingRow []]]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:6434)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1294)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1249)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1237)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1232)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:3061)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:3010)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:1213)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:246)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:199)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:198)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:750)
> Caused by:
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTreeRuntimeException:
>
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTreeRuntimeException:
> java.lang.IllegalStateException: Item not found: 24
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findLowerUnbounded(BPlusTree.java:1216)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1276)
> ... 12 more
> Caused by:
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTreeRuntimeException:
> java.lang.IllegalStateException: Item not found: 24
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.doInitFromLink(CacheDataRowAdapter.java:345)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:165)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:136)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:123)
> at
>
[jira] [Updated] (IGNITE-18939) Partition storages should be created once and not lazy
[ https://issues.apache.org/jira/browse/IGNITE-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-18939: - Summary: Partition storages should be created once and not lazy (was: Parties storage should be created once and not lazy) > Partition storages should be created once and not lazy > -- > > Key: IGNITE-18939 > URL: https://issues.apache.org/jira/browse/IGNITE-18939 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > It was found that the > *org.apache.ignite.internal.table.distributed.TableManager#getOrCreatePartitionStorages* > can be called several times from the > *org.apache.ignite.internal.table.distributed.TableManager#updateAssignmentInternal*, > which is not correct, we must create partition storage facilities once. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18939) Parties storage should be created once and not lazy
Kirill Tkalenko created IGNITE-18939: Summary: Parties storage should be created once and not lazy Key: IGNITE-18939 URL: https://issues.apache.org/jira/browse/IGNITE-18939 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Fix For: 3.0.0-beta2 It was found that the *org.apache.ignite.internal.table.distributed.TableManager#getOrCreatePartitionStorages* can be called several times from the *org.apache.ignite.internal.table.distributed.TableManager#updateAssignmentInternal*, which is not correct, we must create partition storage facilities once. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18852) Create metrics for incremental snapshot
[
https://issues.apache.org/jira/browse/IGNITE-18852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695616#comment-17695616
]
Ignite TC Bot commented on IGNITE-18852:
{panel:title=Branch: [pull/10569/head] Base: [master] : Possible Blockers
(7)|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=7072204]]
{color:#d04437}Queries 1 (lazy=true){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7072207]]
* IgniteBinaryCacheQueryLazyTestSuite:
DynamicIndexServerCoordinatorBasicSelfTest.testCreateIndexNoColumnPartitionedAtomic
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Snapshots{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7072217]]
* IgniteSnapshotTestSuite:
EncryptedSnapshotTest.testSnapshotRestoringFailsWithOtherMasterKey[Encryption
is enabled.] - Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Disk Page Compressions 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7072236]]
* IgnitePdsCompressionTestSuite:
IgniteIncrementalSnapshotRestoreWithIndexingTest.testRestoredIndexes - History
for base branch is absent.
{color:#d04437}Open Census{color} [[tests 0 TIMEOUT , Exit Code , Failure on
metric |https://ci2.ignite.apache.org/viewLog.html?buildId=7072189]]
{color:#d04437}Compute (Grid){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7072162]]
* IgniteBinaryObjectsComputeGridTestSuite:
ComputeJobStatusTest.testFinishedTasks - Test has low fail rate in base branch
0,0% and is not flaky
{color:#d04437}Snapshots With Indexes{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7072218]]
* IgniteSnapshotWithIndexingTestSuite:
IgniteIncrementalSnapshotRestoreWithIndexingTest.testRestoredIndexes - History
for base branch is absent.
{panel}
{panel:title=Branch: [pull/10569/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Snapshots{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7072217]]
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotMetricTest.testCreateIncrementalSnapshotMetrics -
PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IncrementalSnapshotMetricTest.testRestoreIncrementalSnapshotMetrics -
PASSED{color}
{color:#8b}Disk Page Compressions 1{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7072236]]
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotMetricTest.testCreateIncrementalSnapshotMetrics -
PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IncrementalSnapshotMetricTest.testRestoreIncrementalSnapshotMetrics -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7072239buildTypeId=IgniteTests24Java8_RunAll]
> Create metrics for incremental snapshot
> ---
>
> Key: IGNITE-18852
> URL: https://issues.apache.org/jira/browse/IGNITE-18852
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-89, ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The metrics should be similar to full snapshot:
> # Create metrics - should include incremental index of last created snapshot.
> # Restore metrics - should include progress of restoring snapshot (current
> segment, current applied entries).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18938) SSL integration tests fail on Windows
[
https://issues.apache.org/jira/browse/IGNITE-18938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev updated IGNITE-18938:
--
Component/s: rest
> SSL integration tests fail on Windows
> -
>
> Key: IGNITE-18938
> URL: https://issues.apache.org/jira/browse/IGNITE-18938
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Integration tests using
> {{org.apache.ignite.internal.rest.ssl.RestNode#bootstrapCfg}} fail on Windows.
> Micronaut file path properties like {{micronaut.server.ssl.key-store.path}}
> expect the "file:" prefix, but they don't use proper handling and simply cut
> the prefix, so on Windows the property should look like {{file:C:\tmp}}
> instead of {{file:/C:/tmp}}.
> Also the config file parser expect escaped strings, so the backslashes should
> be escaped and the whole string should be quoted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18938) SSL integration tests fail on Windows
[
https://issues.apache.org/jira/browse/IGNITE-18938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev updated IGNITE-18938:
--
Labels: ignite-3 (was: )
> SSL integration tests fail on Windows
> -
>
> Key: IGNITE-18938
> URL: https://issues.apache.org/jira/browse/IGNITE-18938
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Integration tests using
> {{org.apache.ignite.internal.rest.ssl.RestNode#bootstrapCfg}} fail on Windows.
> Micronaut file path properties like {{micronaut.server.ssl.key-store.path}}
> expect the "file:" prefix, but they don't use proper handling and simply cut
> the prefix, so on Windows the property should look like {{file:C:\tmp}}
> instead of {{file:/C:/tmp}}.
> Also the config file parser expect escaped strings, so the backslashes should
> be escaped and the whole string should be quoted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18938) SSL integration tests fail on Windows
Vadim Pakhnushev created IGNITE-18938:
-
Summary: SSL integration tests fail on Windows
Key: IGNITE-18938
URL: https://issues.apache.org/jira/browse/IGNITE-18938
Project: Ignite
Issue Type: Bug
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
Integration tests using
{{org.apache.ignite.internal.rest.ssl.RestNode#bootstrapCfg}} fail on Windows.
Micronaut file path properties like {{micronaut.server.ssl.key-store.path}}
expect the "file:" prefix, but they don't use proper handling and simply cut
the prefix, so on Windows the property should look like {{file:C:\tmp}} instead
of {{file:/C:/tmp}}.
Also the config file parser expect escaped strings, so the backslashes should
be escaped and the whole string should be quoted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18225) Sql. Pushdown MODIFY to data node
[
https://issues.apache.org/jira/browse/IGNITE-18225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-18225:
-
Assignee: Maksim Zhuravkov
> Sql. Pushdown MODIFY to data node
> -
>
> Key: IGNITE-18225
> URL: https://issues.apache.org/jira/browse/IGNITE-18225
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Currently, ModifyNode can only have distribution "single". This means that
> this node will be executed on a single node, and the input should be gathered
> at one place. Assume the following query: UPDATE t SET a = a + 1. Such a
> query will be executed in 2 steps: first we select the rows to update and
> then do the update. Having a ModifyNode as "single" will result in sending
> all rows of table T to the reducer, and then send updated version of rows
> back to the data nodes.
> We could eliminate this round trip by pushing down the ModifyNode (i.e.
> allowing this node to have distribution matching the distribution of
> modifying table).
> Two approaches come to my mind:
> * as with aggregates, we can introduce 2 physical version of a logical
> modify: SingleModify (NB: not colocated!) and Map- + ReduceModify (I hope the
> rest of the necessary changes are clear)
> * make the ModifyNode to have the same distribution as modifying table. In
> that case we need to put SUM aggregate on top of ModifyNode to reduce an
> outcome.
> Personally, I would prefer to stick with the second option, because in that
> case we can get rid of {{FragmentMapping#updatingTableAssignments()}} which
> was introduced more like a hack.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18937) Sql. Join of big number of table function takes unreasonable amount of time
Konstantin Orlov created IGNITE-18937:
-
Summary: Sql. Join of big number of table function takes
unreasonable amount of time
Key: IGNITE-18937
URL: https://issues.apache.org/jira/browse/IGNITE-18937
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Konstantin Orlov
The test
{{org.apache.ignite.internal.sql.engine.planner.JoinCommutePlannerTest#commuteIsDisabledForBigJoinsOfTableFunctions}}
takes too much time to finish (don't know actual timing, just killed the test
after a minute), whereas the similar one but with tables (instead of table
function) takes only a few seconds. Let's investigate this problem and fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18936) [ducktests] Fix parse of the control.sh --baseline output
[ https://issues.apache.org/jira/browse/IGNITE-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-18936: - Labels: ducktests (was: ) > [ducktests] Fix parse of the control.sh --baseline output > - > > Key: IGNITE-18936 > URL: https://issues.apache.org/jira/browse/IGNITE-18936 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Priority: Minor > Labels: ducktests > > Currently the output of the control.sh --baseline is parsed in a wrong way. > In particular the baseline node state can not be obtained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18936) [ducktests] Fix parse of the control.sh --baseline output
Sergey Korotkov created IGNITE-18936: Summary: [ducktests] Fix parse of the control.sh --baseline output Key: IGNITE-18936 URL: https://issues.apache.org/jira/browse/IGNITE-18936 Project: Ignite Issue Type: Test Reporter: Sergey Korotkov Currently the output of the control.sh --baseline is parsed in a wrong way. In particular the baseline node state can not be obtained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
