[jira] [Assigned] (IGNITE-18172) Raft learners rebalance
[
https://issues.apache.org/jira/browse/IGNITE-18172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev reassigned IGNITE-18172:
Assignee: Aleksandr Polovtcev
> Raft learners rebalance
> ---
>
> Key: IGNITE-18172
> URL: https://issues.apache.org/jira/browse/IGNITE-18172
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Currently, the Rebalance protocol only applies to Raft followers. We would
> like to extend it to be applicable to rebalancing Raft learners as well. The
> following should be done:
> # {{partition.assignments.*}} Metastorage keys should store followers'
> assignments as well as learners' assignments. I propose adding a flag to the
> corresponding entries (i.e. {{isFollower}}).
> # When reacting to changes in Metastorage entries, call a new version of
> `changePeersAsync` (see IGNITE-18155) that will provide new followers and
> learners.
> Concrete applications of learners rebalance and actual learner assignments
> are subject of further design (e.g. it can be used in Metastorage and
> Replicated Tables).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18167) SQL: incorrect NULLIF behavior
[
https://issues.apache.org/jira/browse/IGNITE-18167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-18167:
---
Labels: calcite calcite3-required (was: calcite calcite2-required
calcite3-required)
> SQL: incorrect NULLIF behavior
> --
>
> Key: IGNITE-18167
> URL: https://issues.apache.org/jira/browse/IGNITE-18167
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: calcite, calcite3-required
>
> A SQL spec says the following:
> ??NULLIF (V1 , V2) is equivalent to the following : CASE
> WHEN V1 = V2 THEN NULL ELSE V1 END??
> When I try to run it, the rule above is true only for the simplest cases.
> {code:sql}
> select NULLIF(25, 25); --> null(OK)
> select NULLIF(24, 25); --> 24 (OK)
> select NULLIF('test', 'abc'); --> 'test' (OK)
> select NULLIF('test', 'test'); --> '' (should be null!)
> select NULLIF(24 + 1, 26 - 1); --> error IGN-SQL-27(should be null!)
> {code}
> Probably, there are two defects: one is for wrong return value in case of
> textual data, and another one is for error when expression within NULLIF is
> used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18167) SQL: incorrect NULLIF behavior
[
https://issues.apache.org/jira/browse/IGNITE-18167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635711#comment-17635711
]
Aleksey Plekhanov commented on IGNITE-18167:
I've tried these examples with Ignite-2 Calcite SQL engine and it works as
expected. Perhaps some Ignite-3 only issue.
> SQL: incorrect NULLIF behavior
> --
>
> Key: IGNITE-18167
> URL: https://issues.apache.org/jira/browse/IGNITE-18167
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> A SQL spec says the following:
> ??NULLIF (V1 , V2) is equivalent to the following : CASE
> WHEN V1 = V2 THEN NULL ELSE V1 END??
> When I try to run it, the rule above is true only for the simplest cases.
> {code:sql}
> select NULLIF(25, 25); --> null(OK)
> select NULLIF(24, 25); --> 24 (OK)
> select NULLIF('test', 'abc'); --> 'test' (OK)
> select NULLIF('test', 'test'); --> '' (should be null!)
> select NULLIF(24 + 1, 26 - 1); --> error IGN-SQL-27(should be null!)
> {code}
> Probably, there are two defects: one is for wrong return value in case of
> textual data, and another one is for error when expression within NULLIF is
> used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18075) Improve snapshot creation check of the streaming updates.
[ https://issues.apache.org/jira/browse/IGNITE-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-18075: - Fix Version/s: 2.15 > Improve snapshot creation check of the streaming updates. > - > > Key: IGNITE-18075 > URL: https://issues.apache.org/jira/browse/IGNITE-18075 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > The snapshot warning of concurrent DataStreamer updates might be extended > with quick partitions checking (like counters and size) to cover the case > when streamer failed or canceled before the snapshot creation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18075) Improve snapshot creation check of the streaming updates.
[
https://issues.apache.org/jira/browse/IGNITE-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635706#comment-17635706
]
Ignite TC Bot commented on IGNITE-18075:
{panel:title=Branch: [pull/10363/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10363/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Snapshots{color} [[tests
4|https://ci2.ignite.apache.org/viewLog.html?buildId=6912824]]
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testStreamerFailsLongAgoDefault[Encryption=true]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testStreamerFailsLongAgoDefault[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testStreamerFailsLongAgoOverwriting[Encryption=true]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testStreamerFailsLongAgoOverwriting[Encryption=false]
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6912820buildTypeId=IgniteTests24Java8_RunAll]
> Improve snapshot creation check of the streaming updates.
> -
>
> Key: IGNITE-18075
> URL: https://issues.apache.org/jira/browse/IGNITE-18075
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> The snapshot warning of concurrent DataStreamer updates might be extended
> with quick partitions checking (like counters and size) to cover the case
> when streamer failed or canceled before the snapshot creation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18173) SQL: implement EVERY and SOME aggregate functions
[
https://issues.apache.org/jira/browse/IGNITE-18173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-18173:
--
Assignee: Aleksey Plekhanov
> SQL: implement EVERY and SOME aggregate functions
> -
>
> Key: IGNITE-18173
> URL: https://issues.apache.org/jira/browse/IGNITE-18173
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Khitrin
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> Aggregate functions EVERY and SOME are part of SQL standard. Unfortunately,
> they're not implemented in AI3 beta1 yet. Could you please implement them?
> In AI2, they work in the following manner:
> {code:sql}
> create table tmp_table_age_name_wage (key_field INT PRIMARY KEY,AGE
> INT,field1 VARCHAR,field2 INT);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (1,
> 42,'John',10);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (2,
> 43,'Jack',5);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (3,
> 42,'Jen',3);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (4,
> 42,'Jim',7);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (5,
> 41,'Jess',3);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (6,
> 50,'Joe',4);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (7,
> 43,'Jeff',2);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (8,
> 32,'Joel',8);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (9,
> 33,'Joe',3);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (10,
> 41,'Jill',9);
> SELECT EVERY(AGE > 20) FROM tmp_table_age_name_wage;--> true
> SELECT EVERY(AGE > 40) FROM tmp_table_age_name_wage;--> false
> SELECT SOME(field2 = 9) FROM tmp_table_age_name_wage; --> true
> SELECT SOME(field2 <> 9) FROM tmp_table_age_name_wage; --> true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18190) Small 3 node Desktop demonstration cluster fails to shut down gracefully
Jeremy McMillan created IGNITE-18190: Summary: Small 3 node Desktop demonstration cluster fails to shut down gracefully Key: IGNITE-18190 URL: https://issues.apache.org/jira/browse/IGNITE-18190 Project: Ignite Issue Type: Bug Environment: Environment description is provided in example start script, attached in a zip file with logs. Later I will reproduce this issue with debug logs for Windows 11, MacOS Monterey, and Ubuntu Jellyfish. Primary example: MacOS 12.6 Apple M1 Chip 16GB RAM AArch64 OpenJDK-17 JDK apache-ignite-2.14.0-bin To reproduce: # set up components # start 3 node cluster locally # load ApacheIgniteChinookDB.sql # CTRL-C in node2 window to shut down node2 # CTRL-C in node1 window to shut down node1 # CTRL-C in node0 window to experience this behavior Reporter: Jeremy McMillan Attachments: MacDesktopIgniteClusterShutdownGlitch.zip Ignite 2.14 binary distribution running on openjdk-17 on Windows 11 and MacOS Monterey both fail to shut down the last of 3 nodes running with a default configuration after loading Chinook example data. This is not 100% reliable, but is more than 50% repeatable on Mac and Windows. I was unable to reproduce this issue on Linux using Ubuntu Jellyfish. The signal handler routine appears to be ineffective as the final remaining java process must be killed with SIGKILL. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18189) Merge ignite-spark 3.2 and 2.4 extensions into a single module
Alexandr Shapkin created IGNITE-18189: - Summary: Merge ignite-spark 3.2 and 2.4 extensions into a single module Key: IGNITE-18189 URL: https://issues.apache.org/jira/browse/IGNITE-18189 Project: Ignite Issue Type: Task Components: extensions Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin We need to do the following a) release ignite-spark 1.0.0 extension b) merge ignite-spark and ignite-spark-3.2 modules c) release ignite-spark 2.0.0 extension (with spark 3.2) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18076) Store snapshot creation warnings.
[ https://issues.apache.org/jira/browse/IGNITE-18076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-18076: - Assignee: Vladimir Steshin > Store snapshot creation warnings. > - > > Key: IGNITE-18076 > URL: https://issues.apache.org/jira/browse/IGNITE-18076 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > We could store warnings of snapshot creation process (probably in the > snapshot metals) and show them at snapshot validation/restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18075) Improve snapshot creation check of the streaming updates.
[ https://issues.apache.org/jira/browse/IGNITE-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-18075: - Assignee: Vladimir Steshin > Improve snapshot creation check of the streaming updates. > - > > Key: IGNITE-18075 > URL: https://issues.apache.org/jira/browse/IGNITE-18075 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > > The snapshot warning of concurrent DataStreamer updates might be extended > with quick partitions checking (like counters and size) to cover the case > when streamer failed or canceled before the snapshot creation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18188) Design and develop e2e tests for cli
[ https://issues.apache.org/jira/browse/IGNITE-18188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-18188: --- Epic Link: IGNITE-18143 > Design and develop e2e tests for cli > > > Key: IGNITE-18188 > URL: https://issues.apache.org/jira/browse/IGNITE-18188 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Now we do not have a clear API to develop e2e tests for CLI. By e2e I mean > that we do not use internal pipocli classes but send commands directly as a > terminal command. Also, those tests should be applicable for interactive > mode. Take into account that the user journey with interactive mode might > look like this: ignite3, say to the connect question, and run any command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18188) Design and develop e2e tests for cli
Aleksandr created IGNITE-18188: -- Summary: Design and develop e2e tests for cli Key: IGNITE-18188 URL: https://issues.apache.org/jira/browse/IGNITE-18188 Project: Ignite Issue Type: Task Components: cli Reporter: Aleksandr Now we do not have a clear API to develop e2e tests for CLI. By e2e I mean that we do not use internal pipocli classes but send commands directly as a terminal command. Also, those tests should be applicable for interactive mode. Take into account that the user journey with interactive mode might look like this: ignite3, say to the connect question, and run any command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18187) Check if the wrong version of java used on client env
Aleksandr created IGNITE-18187: -- Summary: Check if the wrong version of java used on client env Key: IGNITE-18187 URL: https://issues.apache.org/jira/browse/IGNITE-18187 Project: Ignite Issue Type: Task Components: build Reporter: Aleksandr Now if the user runs ignite cli or ignite db from the environment where the wrong java version, say java 8, is installed then there is no clear message what went wrong. We have to check java version in start scripts and if the version is lower than 11 display the meaningful message. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18186) Calcite engine. Not correlated condition is not pushed to table scan if there is also correlated condition in the filter
Aleksey Plekhanov created IGNITE-18186:
--
Summary: Calcite engine. Not correlated condition is not pushed to
table scan if there is also correlated condition in the filter
Key: IGNITE-18186
URL: https://issues.apache.org/jira/browse/IGNITE-18186
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Not correlated condition cannot be pushed to table scan if there is also
correlated condition in the filter.
For example, in this query:
{code:java}
SELECT (SELECT id FROM tbl AS t2 WHERE t2.id < 50 AND t2.id = t1.id) FROM tbl
AS t1 {code}
Condition {{t2.id < 50}} can be pushed to table scan and condition {{t2.id =
t1.id}} can be used as hash spool search row, but currently filter can't be
splitted and plan uses table spool instead of hash spool and become very
ineffective:
{noformat}
IgniteProject(EXPR$0=[$1])
IgniteCorrelatedNestedLoopJoin(condition=[true], joinType=[left],
variablesSet=[[$cor0]], correlationVariables=[[$cor0]])
IgniteExchange(distribution=[single])
IgniteTableScan(table=[[PUBLIC, TBL]])
IgniteColocatedHashAggregate(group=[{}], agg#0=[SINGLE_VALUE($0)])
IgniteFilter(condition=[AND(<($0, 50), =($0, $cor0.ID))])
IgniteTableSpool(readType=[LAZY], writeType=[EAGER])
IgniteExchange(distribution=[single])
IgniteTableScan(table=[[PUBLIC, TBL]]){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18183) Rest endpoint for all node metrics
[
https://issues.apache.org/jira/browse/IGNITE-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635407#comment-17635407
]
Stanislav Lukyanov commented on IGNITE-18183:
-
This is not specific to metrics. The same is applicable to any endpoint working
per node: config, version, etc.
It seems that all of the `/node/` endpoints need to have "flavors" of access -
getting data locally and getting data from one or multiple nodes in the cluster.
I guess it means re-writing all of these `/node/` handlers in a way that
supports sending remote requests. Ignite 2 does that all the time via compute
jobs, I guess Ignite 3 would do the same.
Also, seems like it might need to be `/nodes/` (plural). I like Elastic's
structure a lot.
> Rest endpoint for all node metrics
> --
>
> Key: IGNITE-18183
> URL: https://issues.apache.org/jira/browse/IGNITE-18183
> Project: Ignite
> Issue Type: Task
> Components: ignite-3
>Reporter: Stepachev Maksim
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
>
> *The problem:*
> The ignite 3 rest of clusters will usually be hided behind a load balancer,
> as result we aren't able to get a particular node metrics. In this task is
> required to develop an endpoint at your discretion that will extract metrics
> from all nodes by one call.
> *Possible path at your wish:*
> * /all-nodes/metrics
> * {{/node/all/metrics}} - query all nodes (like {{all-nodes}} above)
> * {{/node/12345678-1234-1234-1234-12345678/metrics}} - query that particular
> node even if we happen to connect to a different one{{{}{}}}
> * {{/node/local/metrics}} - query the node we connected to
> *Please look at these examples of other databases:*
> *
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html]
> *
> [https://docs.spring.io/spring-boot/docs/current/actuator-api/htmlsingle/#metrics]
> * [https://micronaut-projects.github.io/micronaut-micrometer/latest/guide/]
> * Etc.
> It would be good if we could add filters to get specific sets of metrics.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18152) Fix creds reading in repository deploy build
[ https://issues.apache.org/jira/browse/IGNITE-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-18152: -- Assignee: Mikhail Pochatkin > Fix creds reading in repository deploy build > > > Key: IGNITE-18152 > URL: https://issues.apache.org/jira/browse/IGNITE-18152 > Project: Ignite > Issue Type: Bug > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > > Currently, in buildscripts/publishing-repos.gradle script creds reading made > via gradle.properties and release manager should define username\password in > local gradle.properties file, but it doesn't work now, only with direct creds > definition in script is working. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18171) Descibe nodes start/stop scenarios
[ https://issues.apache.org/jira/browse/IGNITE-18171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634803#comment-17634803 ] Andrey Mashenkov edited comment on IGNITE-18171 at 11/17/22 1:56 PM: - As node may participate is several groups, let's consider next possible roles and their combinations. Node roles: * *CMG* (Cluster Management Group) is a subset of cluster nodes hosting a Raft group. CMG leader is responsible for orchestrating the node join process. * *MSG* (Meta Storage Group) is a subset of cluster nodes hosting a Raft group responsible for storing a master copy of cluster metadata. * *DNG* (Data Node Group) is a subset of cluster nodes hosting a Raft group responsible for storing a master copy of user tables. Node types: A = [CMG] B = [MSG] C = [DNG] D = [CMG, MSG] E = [CMG, DNG] F = [MSG, DNG] G = [CMG, MSG, DNG] was (Author: amashenkov): As node may participate is several groups, let's consider next possible roles and their combinations. Node roles: * *CMG* (Cluster Management Group) is a subset of cluster nodes hosting a Raft group. CMG leader is responsible for orchestrating the node join process. * *MSG* (Meta Storage Group) is a subset of cluster nodes hosting a Raft group responsible for storing a master copy of cluster metadata. * *DNG* (Data Node Group) is a subset of cluster nodes hosting a Raft group responsible for storing a master copy of user tables. Node types: A = [] B = [CMG] C = [MSG] D = [DNG] E = [CMG, MSG] F = [CMG, DNG] G = [MSG, DNG] H = [CMG, MSG, DNG] > Descibe nodes start/stop scenarios > -- > > Key: IGNITE-18171 > URL: https://issues.apache.org/jira/browse/IGNITE-18171 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > h2. Definitions. > We can distinguish next cluster node groups, see below. Each node may be part > of one or more groups. > * Cluster Management Group (CMG), that control new nodes join process. > * MetaStorage group (MSG), that hosts meta storage. > * Data node group (DNG), that just hosts tables partitions. > The components (CMG, meta storage, tables components) are depends on each > other, but may resides on different (even disjoint) node subsets. So, some > components may become temporary unavailable, and dependant components must be > aware of such issues and handle them (wait, retry, throw exception or > whatever) in expected way, which has to be documented also. > [See IEP for > details|https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization+for+Ignite+3] > h2. Motivation. > As of now, the correct way to start the grid (after it was stopped) is: start > CMG nodes, then Meta Storage nodes, then Data nodes. And in backward order > for correct stop. Other scenarios are not tested and may lead to unexpected > behaviour. > Let's describe all possible scenarios, expected behaviour for each of them > and extend test coverage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18185) .NET: Thin 3.0: Automate NuGet publish process
[
https://issues.apache.org/jira/browse/IGNITE-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-18185:
---
Component/s: build
Labels: .NET buid ignite-3 (was: .NET ignite-3)
> .NET: Thin 3.0: Automate NuGet publish process
> --
>
> Key: IGNITE-18185
> URL: https://issues.apache.org/jira/browse/IGNITE-18185
> Project: Ignite
> Issue Type: Improvement
> Components: build, platforms
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, buid, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Described below is the process to push nupkg/snupkg packages to nuget.org.
> *Prerequisites*
> * .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
> *Process*
> * For every file in *apache-ignite-VER-nuget.zip*:
> {code}
> dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
> {code}
> The API_KEY can be found at
> https://svn.apache.org/repos/private/pmc/ignite/credentials/nuget.org (PMC
> only, requires Apache credentials).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18185) .NET: Thin 3.0: Automate NuGet publish process
[
https://issues.apache.org/jira/browse/IGNITE-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18185:
Description:
Described below is the process to push nupkg/snupkg packages to nuget.org.
*Prerequisites*
* .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
*Process*
For every file in *apache-ignite-VER-nuget.zip*:
{code}
dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
{code}
The API_KEY can be found at
https://svn.apache.org/repos/private/pmc/ignite/credentials/nuget.org (PMC
only, requires Apache credentials).
was:
Described below is the process to push nupkg/snupkg packages to nuget.org.
*Prerequisites*
* .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
*Process*
For every file in *apache-ignite-VER-nuget.zip*:
{code}
dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
{code}
> .NET: Thin 3.0: Automate NuGet publish process
> --
>
> Key: IGNITE-18185
> URL: https://issues.apache.org/jira/browse/IGNITE-18185
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Described below is the process to push nupkg/snupkg packages to nuget.org.
> *Prerequisites*
> * .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
> *Process*
> For every file in *apache-ignite-VER-nuget.zip*:
> {code}
> dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
> {code}
> The API_KEY can be found at
> https://svn.apache.org/repos/private/pmc/ignite/credentials/nuget.org (PMC
> only, requires Apache credentials).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18185) .NET: Thin 3.0: Automate NuGet publish process
[
https://issues.apache.org/jira/browse/IGNITE-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18185:
Description:
Described below is the process to push nupkg/snupkg packages to nuget.org.
*Prerequisites*
* .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
*Process*
* For every file in *apache-ignite-VER-nuget.zip*:
{code}
dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
{code}
The API_KEY can be found at
https://svn.apache.org/repos/private/pmc/ignite/credentials/nuget.org (PMC
only, requires Apache credentials).
was:
Described below is the process to push nupkg/snupkg packages to nuget.org.
*Prerequisites*
* .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
*Process*
For every file in *apache-ignite-VER-nuget.zip*:
{code}
dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
{code}
The API_KEY can be found at
https://svn.apache.org/repos/private/pmc/ignite/credentials/nuget.org (PMC
only, requires Apache credentials).
> .NET: Thin 3.0: Automate NuGet publish process
> --
>
> Key: IGNITE-18185
> URL: https://issues.apache.org/jira/browse/IGNITE-18185
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Described below is the process to push nupkg/snupkg packages to nuget.org.
> *Prerequisites*
> * .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
> *Process*
> * For every file in *apache-ignite-VER-nuget.zip*:
> {code}
> dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
> {code}
> The API_KEY can be found at
> https://svn.apache.org/repos/private/pmc/ignite/credentials/nuget.org (PMC
> only, requires Apache credentials).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18182) Release Apache Ignite 3 Beta Documentation
[ https://issues.apache.org/jira/browse/IGNITE-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635352#comment-17635352 ] Vyacheslav Koptilin commented on IGNITE-18182: -- Hello [~igusev], The docs look good to me. Merged to the master branch. Thank you for your contribution! > Release Apache Ignite 3 Beta Documentation > -- > > Key: IGNITE-18182 > URL: https://issues.apache.org/jira/browse/IGNITE-18182 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > We need to release the docs for AI3 beta. To do this, publish the updated > files to the documentation-website repo. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18185) .NET: Thin 3.0: Automate NuGet publish process
[
https://issues.apache.org/jira/browse/IGNITE-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18185:
Description:
Described below is the process to push nupkg/snupkg packages to nuget.org.
*Prerequisites*
* .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
*Process*
For every file in *apache-ignite-VER-nuget.zip*:
{code}
dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
{code}
was:
Described below is the process to push nupkg/snupkg packages to nuget.org.
*Prerequisites*
* .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
*Process*
For every file in *apache-ignite-{version}-nuget.zip*:
{code}
dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
{code}
> .NET: Thin 3.0: Automate NuGet publish process
> --
>
> Key: IGNITE-18185
> URL: https://issues.apache.org/jira/browse/IGNITE-18185
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Described below is the process to push nupkg/snupkg packages to nuget.org.
> *Prerequisites*
> * .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
> *Process*
> For every file in *apache-ignite-VER-nuget.zip*:
> {code}
> dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18185) .NET: Thin 3.0: Automate NuGet publish process
[
https://issues.apache.org/jira/browse/IGNITE-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18185:
Description:
Described below is the process to push nupkg/snupkg packages to nuget.org.
*Prerequisites*
* .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
*Process*
For every file in *apache-ignite-{version}-nuget.zip*:
{code}
dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
{code}
> .NET: Thin 3.0: Automate NuGet publish process
> --
>
> Key: IGNITE-18185
> URL: https://issues.apache.org/jira/browse/IGNITE-18185
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Described below is the process to push nupkg/snupkg packages to nuget.org.
> *Prerequisites*
> * .NET SDK 6 https://dotnet.microsoft.com/en-us/download/dotnet/6.0
> *Process*
> For every file in *apache-ignite-{version}-nuget.zip*:
> {code}
> dotnet nuget push $FILE --api-key $API_KEY --source "https://nuget.org/;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18182) Release Apache Ignite 3 Beta Documentation
[ https://issues.apache.org/jira/browse/IGNITE-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-18182: --- Assignee: Igor Gusev > Release Apache Ignite 3 Beta Documentation > -- > > Key: IGNITE-18182 > URL: https://issues.apache.org/jira/browse/IGNITE-18182 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > > We need to release the docs for AI3 beta. To do this, publish the updated > files to the documentation-website repo. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18185) .NET: Thin 3.0: Automate NuGet publish process
Pavel Tupitsyn created IGNITE-18185: --- Summary: .NET: Thin 3.0: Automate NuGet publish process Key: IGNITE-18185 URL: https://issues.apache.org/jira/browse/IGNITE-18185 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18184) .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635347#comment-17635347
]
Pavel Tupitsyn commented on IGNITE-18184:
-
Merged to main: a98b7439d2ee9e401501f067609e957a8ed9969c
> .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
>
>
> Key: IGNITE-18184
> URL: https://issues.apache.org/jira/browse/IGNITE-18184
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunNetTests/6916396?buildTab=overview=false=false=true=true=true
> {code}
> Expected: 1773
> But was: 1774
> TearDown : NUnit.Framework.AssertionException : Expected: 1773
> But was: 1774
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> --TearDown
>at NUnit.Framework.Assert.ReportFailure(String message)
>at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
> message, Object[] args)
>at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
> expression, String message, Object[] args)
>at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> {code}
> Same problem as in IGNITE-17993 - we forgot to fix TearDown check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18184) .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635342#comment-17635342
]
Igor Sapego commented on IGNITE-18184:
--
[~ptupitsyn] looks good to me.
> .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
>
>
> Key: IGNITE-18184
> URL: https://issues.apache.org/jira/browse/IGNITE-18184
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunNetTests/6916396?buildTab=overview=false=false=true=true=true
> {code}
> Expected: 1773
> But was: 1774
> TearDown : NUnit.Framework.AssertionException : Expected: 1773
> But was: 1774
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> --TearDown
>at NUnit.Framework.Assert.ReportFailure(String message)
>at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
> message, Object[] args)
>at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
> expression, String message, Object[] args)
>at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> {code}
> Same problem as in IGNITE-17993 - we forgot to fix TearDown check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18184) .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18184:
Labels: .NET ignite-3 (was: ignite-3)
> .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
>
>
> Key: IGNITE-18184
> URL: https://issues.apache.org/jira/browse/IGNITE-18184
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunNetTests/6916396?buildTab=overview=false=false=true=true=true
> {code}
> Expected: 1773
> But was: 1774
> TearDown : NUnit.Framework.AssertionException : Expected: 1773
> But was: 1774
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> --TearDown
>at NUnit.Framework.Assert.ReportFailure(String message)
>at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
> message, Object[] args)
>at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
> expression, String message, Object[] args)
>at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> {code}
> Same problem as in IGNITE-17993 - we forgot to fix TearDown check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18184) .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18184:
Issue Type: Bug (was: Improvement)
> .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
>
>
> Key: IGNITE-18184
> URL: https://issues.apache.org/jira/browse/IGNITE-18184
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 3.0.0-beta2
>
>
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunNetTests/6916396?buildTab=overview=false=false=true=true=true
> {code}
> Expected: 1773
> But was: 1774
> TearDown : NUnit.Framework.AssertionException : Expected: 1773
> But was: 1774
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> --TearDown
>at NUnit.Framework.Assert.ReportFailure(String message)
>at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
> message, Object[] args)
>at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
> expression, String message, Object[] args)
>at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> {code}
> Same problem as in IGNITE-17993 - we forgot to fix TearDown check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18184) .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18184:
Labels: ignite-3 (was: )
> .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
>
>
> Key: IGNITE-18184
> URL: https://issues.apache.org/jira/browse/IGNITE-18184
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunNetTests/6916396?buildTab=overview=false=false=true=true=true
> {code}
> Expected: 1773
> But was: 1774
> TearDown : NUnit.Framework.AssertionException : Expected: 1773
> But was: 1774
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> --TearDown
>at NUnit.Framework.Assert.ReportFailure(String message)
>at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
> message, Object[] args)
>at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
> expression, String message, Object[] args)
>at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> {code}
> Same problem as in IGNITE-17993 - we forgot to fix TearDown check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18184) .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18184:
Ignite Flags: (was: Docs Required,Release Notes Required)
> .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
>
>
> Key: IGNITE-18184
> URL: https://issues.apache.org/jira/browse/IGNITE-18184
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunNetTests/6916396?buildTab=overview=false=false=true=true=true
> {code}
> Expected: 1773
> But was: 1774
> TearDown : NUnit.Framework.AssertionException : Expected: 1773
> But was: 1774
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> --TearDown
>at NUnit.Framework.Assert.ReportFailure(String message)
>at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
> message, Object[] args)
>at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
> expression, String message, Object[] args)
>at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> {code}
> Same problem as in IGNITE-17993 - we forgot to fix TearDown check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18184) .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18184:
Description:
{code}
Expected: 1773
But was: 1774
TearDown : NUnit.Framework.AssertionException : Expected: 1773
But was: 1774
at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
115
--TearDown
at NUnit.Framework.Assert.ReportFailure(String message)
at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
message, Object[] args)
at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
expression, String message, Object[] args)
at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
115
{code}
> .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
>
>
> Key: IGNITE-18184
> URL: https://issues.apache.org/jira/browse/IGNITE-18184
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 3.0.0-beta2
>
>
> {code}
> Expected: 1773
> But was: 1774
> TearDown : NUnit.Framework.AssertionException : Expected: 1773
> But was: 1774
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> --TearDown
>at NUnit.Framework.Assert.ReportFailure(String message)
>at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
> message, Object[] args)
>at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
> expression, String message, Object[] args)
>at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18184) .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18184:
Description:
https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunNetTests/6916396?buildTab=overview=false=false=true=true=true
{code}
Expected: 1773
But was: 1774
TearDown : NUnit.Framework.AssertionException : Expected: 1773
But was: 1774
at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
115
--TearDown
at NUnit.Framework.Assert.ReportFailure(String message)
at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
message, Object[] args)
at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
expression, String message, Object[] args)
at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
115
{code}
Same problem as in IGNITE-17993 - we forgot to fix TearDown check.
was:
{code}
Expected: 1773
But was: 1774
TearDown : NUnit.Framework.AssertionException : Expected: 1773
But was: 1774
at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
115
--TearDown
at NUnit.Framework.Assert.ReportFailure(String message)
at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
message, Object[] args)
at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
expression, String message, Object[] args)
at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
115
{code}
> .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
>
>
> Key: IGNITE-18184
> URL: https://issues.apache.org/jira/browse/IGNITE-18184
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 3.0.0-beta2
>
>
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunNetTests/6916396?buildTab=overview=false=false=true=true=true
> {code}
> Expected: 1773
> But was: 1774
> TearDown : NUnit.Framework.AssertionException : Expected: 1773
> But was: 1774
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> --TearDown
>at NUnit.Framework.Assert.ReportFailure(String message)
>at NUnit.Framework.Assert.ReportFailure(ConstraintResult result, String
> message, Object[] args)
>at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
> expression, String message, Object[] args)
>at NUnit.Framework.Assert.AreEqual(Object expected, Object actual)
>at Apache.Ignite.Tests.IgniteTestsBase.TearDown() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteTestsBase.cs:line
> 115
> {code}
> Same problem as in IGNITE-17993 - we forgot to fix TearDown check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18184) .NET: Thin 3.0: TestExecuteOnRandomNode is flaky
Pavel Tupitsyn created IGNITE-18184: --- Summary: .NET: Thin 3.0: TestExecuteOnRandomNode is flaky Key: IGNITE-18184 URL: https://issues.apache.org/jira/browse/IGNITE-18184 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18183) Rest endpoint for all node metrics
Stepachev Maksim created IGNITE-18183:
-
Summary: Rest endpoint for all node metrics
Key: IGNITE-18183
URL: https://issues.apache.org/jira/browse/IGNITE-18183
Project: Ignite
Issue Type: Task
Components: ignite-3
Reporter: Stepachev Maksim
*The problem:*
The ignite 3 rest of clusters will usually be hided behind a load balancer, as
result we aren't able to get a particular node metrics. In this task is
required to develop an endpoint at your discretion that will extract metrics
from all nodes by one call.
*Possible path at your wish:*
* /all-nodes/metrics
* {{/node/all/metrics}} - query all nodes (like {{all-nodes}} above)
* {{/node/12345678-1234-1234-1234-12345678/metrics}} - query that particular
node even if we happen to connect to a different one{{{}{}}}
* {{/node/local/metrics}} - query the node we connected to
*Please look at these examples of other databases:*
*
[https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html]
*
[https://docs.spring.io/spring-boot/docs/current/actuator-api/htmlsingle/#metrics]
* [https://micronaut-projects.github.io/micronaut-micrometer/latest/guide/]
* Etc.
It would be good if we could add filters to get specific sets of metrics.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635282#comment-17635282
]
Ignite TC Bot commented on IGNITE-17383:
{panel:title=Branch: [pull/10328/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10328/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6841400]]
* {color:#013220}IgnitePdsTestSuite2:
IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6841329buildTypeId=IgniteTests24Java8_RunAll]
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
>
[jira] [Updated] (IGNITE-17990) Download RAFT snapshot without deleting original partition data
[
https://issues.apache.org/jira/browse/IGNITE-17990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-17990:
---
Description:
h3. Note
This is an umbrella issue. Most
h3. Description
In first design, full rebalance is implemented this way:
* we drop partition data
* we download partition data from the leader
* we're done
There's a problem with this approach - if download part failed, we lost one
follower. This is bad, because technically new leader may have more data in the
log and it could have uploaded it the follower, but now it makes no sense.
Not only can it lead to hard-to-catch errors and introducing custom work-around
code to JRaft, it's also an unconditional data deletion without neither
explicit user approval nor a copy of the data preserved durably.
Such implementation is fine for POC and some tests, but it cannot be allowed in
the release version of the product.
h3. New proposed solution
As trivial as it may seem, new solution is to _not deleting data_ before
snapshot is fully downloaded and ready for swap. Why is it trivial? Because
this is literally what RAFT demands to be done.
Of course, there's a {*}but{*}. Snapshot application, when it's downloaded,
should be {{O(1)}} when it comes to the number of rows in the partition and a
number of transactions in a tx state store. This may not be fully achievable,
depending on the implementation that we chose, more on that later.
Following sections will describe all my concerns and possible implementations.
Some sections can be skipped while reading. For example, if you're not
interested in a specific storage engine, but want to read everything else.
h3. TX state storage
There's one really good thing about TX state storage. It has no storage engine,
there's only a single RocksDB-based implementation. This makes possible the
following approach:
* when we stream data, we can write it into a SST file, almost like in
snapshots of meta-storage and CMG storages
* once snapshot is downloaded, we ingest it into a storage
What I like about this solution is that it's very simple. But, there are
concerns:
* ingesting leads to additional implicit data flush. Maybe it can be avoided,
more on that later
* it's not clear whether RocksDB creates a copy of SST file or not. I would
assume that it does, because the file might be in other folder or on another
device, for example. Although copying files is fast, it still takes time. Add
to this a time required for the flush and we see a problem - operation may
become unnecessarily long
For these reasons, I don't think that such solution should be implemented. The
point of this description was to show, that I thought about this alternative
and consciously decided to use another one.
I believe that TX state storage should use the same approach as a RocksDB-based
partition storage. Its description can be found later in this issue.
h3. MV storage - Test engine
Test uses concurrent skip-list map for MV data and a bunch of other maps for
indexes. While snapshots is being downloaded, we should insert all data into
new maps, that have the same structure. In the end, we should have two versions
of the partition: old and new.
{{onSnapshotLoad}} should just swap all objects. After that, old partition data
can be cleaned by the garbage collector.
This is a good place to start implementation. I assume that some new API will
be introduced. I have thoughts about it as well, they are described later in
*API* section.
h3. MV storage - RocksDB engine
SST-based approach is described in a *TX state storage* section. There I
describe why I don't think that this is a good solution. Same reasoning can be
applied here just as effectively. This means that we should write data in the
same RocksDB instance. This is a little bit tricky.
The reason is that all stored data is merged together, and Columns Families are
shared between different partitions. This makes it harder to find a place to
write partition data while old partition data persists. As a reminder and an
example, let's take a look at how data is stored in row storage:
{code:java}
+---+-+---+
|Partition 0| ... | Partition MAX |
+---+-+---+
| Row1 | ... | RowN | ... | Row1 | ... | RowN |
+---+-+---+{code}
Logically, CF is split into a different "blocks", and each block represents a
partition. Currently, each partition block is associated with an 2-bytes
identifier that matches a partition number in Big Endian.
We could add new CF with similar structure and write snapshot data in it, but
then the snapshot load operation would require us to move data from one CF to
another. The only option that I know of, that can do this, is SST ingestion.
And I already explained why I don't like it.
This leaves us with the
[jira] [Updated] (IGNITE-17990) Download RAFT snapshot without deleting original partition data
[
https://issues.apache.org/jira/browse/IGNITE-17990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-17990:
---
Description:
h3. Note
This is an umbrella issue. It's split into several smaller issues.
h3. Description
In first design, full rebalance is implemented this way:
* we drop partition data
* we download partition data from the leader
* we're done
There's a problem with this approach - if download part failed, we lost one
follower. This is bad, because technically new leader may have more data in the
log and it could have uploaded it the follower, but now it makes no sense.
Not only can it lead to hard-to-catch errors and introducing custom work-around
code to JRaft, it's also an unconditional data deletion without neither
explicit user approval nor a copy of the data preserved durably.
Such implementation is fine for POC and some tests, but it cannot be allowed in
the release version of the product.
h3. New proposed solution
As trivial as it may seem, new solution is to _not deleting data_ before
snapshot is fully downloaded and ready for swap. Why is it trivial? Because
this is literally what RAFT demands to be done.
Of course, there's a {*}but{*}. Snapshot application, when it's downloaded,
should be {{O(1)}} when it comes to the number of rows in the partition and a
number of transactions in a tx state store. This may not be fully achievable,
depending on the implementation that we chose, more on that later.
Following sections will describe all my concerns and possible implementations.
Some sections can be skipped while reading. For example, if you're not
interested in a specific storage engine, but want to read everything else.
h3. TX state storage
There's one really good thing about TX state storage. It has no storage engine,
there's only a single RocksDB-based implementation. This makes possible the
following approach:
* when we stream data, we can write it into a SST file, almost like in
snapshots of meta-storage and CMG storages
* once snapshot is downloaded, we ingest it into a storage
What I like about this solution is that it's very simple. But, there are
concerns:
* ingesting leads to additional implicit data flush. Maybe it can be avoided,
more on that later
* it's not clear whether RocksDB creates a copy of SST file or not. I would
assume that it does, because the file might be in other folder or on another
device, for example. Although copying files is fast, it still takes time. Add
to this a time required for the flush and we see a problem - operation may
become unnecessarily long
For these reasons, I don't think that such solution should be implemented. The
point of this description was to show, that I thought about this alternative
and consciously decided to use another one.
I believe that TX state storage should use the same approach as a RocksDB-based
partition storage. Its description can be found later in this issue.
h3. MV storage - Test engine
Test uses concurrent skip-list map for MV data and a bunch of other maps for
indexes. While snapshots is being downloaded, we should insert all data into
new maps, that have the same structure. In the end, we should have two versions
of the partition: old and new.
{{onSnapshotLoad}} should just swap all objects. After that, old partition data
can be cleaned by the garbage collector.
This is a good place to start implementation. I assume that some new API will
be introduced. I have thoughts about it as well, they are described later in
*API* section.
h3. MV storage - RocksDB engine
SST-based approach is described in a *TX state storage* section. There I
describe why I don't think that this is a good solution. Same reasoning can be
applied here just as effectively. This means that we should write data in the
same RocksDB instance. This is a little bit tricky.
The reason is that all stored data is merged together, and Columns Families are
shared between different partitions. This makes it harder to find a place to
write partition data while old partition data persists. As a reminder and an
example, let's take a look at how data is stored in row storage:
{code:java}
+---+-+---+
|Partition 0| ... | Partition MAX |
+---+-+---+
| Row1 | ... | RowN | ... | Row1 | ... | RowN |
+---+-+---+{code}
Logically, CF is split into a different "blocks", and each block represents a
partition. Currently, each partition block is associated with an 2-bytes
identifier that matches a partition number in Big Endian.
We could add new CF with similar structure and write snapshot data in it, but
then the snapshot load operation would require us to move data from one CF to
another. The only option that I know of, that can do this, is SST ingestion.
And I already explained why I don't
[jira] [Updated] (IGNITE-18180) Implement partition destruction for RocksDB
[ https://issues.apache.org/jira/browse/IGNITE-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-18180: --- Summary: Implement partition destruction for RocksDB (was: Implement partition destruction for RocsDB) > Implement partition destruction for RocksDB > --- > > Key: IGNITE-18180 > URL: https://issues.apache.org/jira/browse/IGNITE-18180 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment, the destruction of the partition does not work quite > correctly, what are the problems: > # On > *org.apache.ignite.internal.storage.rocksdb.RocksDbTableStorage#destroyPartition* > call we don't destroy indexes; > # If the node falls after the call to destroy the partition and before > flushing, then the partition will continue to exist, which may lead to > negative consequences. > Also important: > # Write appropriate tests; > # On the destruction of the partition, we must not give the opportunity to > read data from the partition and indexes and close all existing cursors for > the partition and indexes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18181) Race during table creation
[
https://issues.apache.org/jira/browse/IGNITE-18181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635255#comment-17635255
]
Roman Puchkovskiy commented on IGNITE-18181:
Thanks!
> Race during table creation
> --
>
> Key: IGNITE-18181
> URL: https://issues.apache.org/jira/browse/IGNITE-18181
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{tablesByIdVV.update()}} inside {{TableManager#updateAssignments}} initiates
> async RAFT groups' start, but its future supplier returns
> {{{}completedFuture(null){}}}, so there is no causal dependency between
> completion of what {{update()}} returned and the futures that start RAFT
> groups; hence, there is no causal dependency between completing 'table
> created' future and RAFT groups start.
> While {{updateAssignmentsInternal}} is fully synchronous, this is not a
> problem. But in IGNITE-18170 we make it async, and here the race starts
> manifesting itself.
> Probably, update supplier should return a future depending on RAFT group
> start future and not just a completed future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18181) Race during table creation
[
https://issues.apache.org/jira/browse/IGNITE-18181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635237#comment-17635237
]
Vladislav Pyatkov commented on IGNITE-18181:
Merged 3afbef50768d5b4858498f2fc20c4743675fa669
[~rpuch] Thank you for contribution.
> Race during table creation
> --
>
> Key: IGNITE-18181
> URL: https://issues.apache.org/jira/browse/IGNITE-18181
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{tablesByIdVV.update()}} inside {{TableManager#updateAssignments}} initiates
> async RAFT groups' start, but its future supplier returns
> {{{}completedFuture(null){}}}, so there is no causal dependency between
> completion of what {{update()}} returned and the futures that start RAFT
> groups; hence, there is no causal dependency between completing 'table
> created' future and RAFT groups start.
> While {{updateAssignmentsInternal}} is fully synchronous, this is not a
> problem. But in IGNITE-18170 we make it async, and here the race starts
> manifesting itself.
> Probably, update supplier should return a future depending on RAFT group
> start future and not just a completed future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18181) Race during table creation
[
https://issues.apache.org/jira/browse/IGNITE-18181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635236#comment-17635236
]
Vladislav Pyatkov commented on IGNITE-18181:
LGTM
> Race during table creation
> --
>
> Key: IGNITE-18181
> URL: https://issues.apache.org/jira/browse/IGNITE-18181
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{tablesByIdVV.update()}} inside {{TableManager#updateAssignments}} initiates
> async RAFT groups' start, but its future supplier returns
> {{{}completedFuture(null){}}}, so there is no causal dependency between
> completion of what {{update()}} returned and the futures that start RAFT
> groups; hence, there is no causal dependency between completing 'table
> created' future and RAFT groups start.
> While {{updateAssignmentsInternal}} is fully synchronous, this is not a
> problem. But in IGNITE-18170 we make it async, and here the race starts
> manifesting itself.
> Probably, update supplier should return a future depending on RAFT group
> start future and not just a completed future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18182) Release Apache Ignite 3 Beta Documentation
Igor Gusev created IGNITE-18182: --- Summary: Release Apache Ignite 3 Beta Documentation Key: IGNITE-18182 URL: https://issues.apache.org/jira/browse/IGNITE-18182 Project: Ignite Issue Type: Task Reporter: Igor Gusev We need to release the docs for AI3 beta. To do this, publish the updated files to the documentation-website repo. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18182) Release Apache Ignite 3 Beta Documentation
[ https://issues.apache.org/jira/browse/IGNITE-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev updated IGNITE-18182: Labels: ignite-3 (was: ) > Release Apache Ignite 3 Beta Documentation > -- > > Key: IGNITE-18182 > URL: https://issues.apache.org/jira/browse/IGNITE-18182 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Priority: Major > Labels: ignite-3 > > We need to release the docs for AI3 beta. To do this, publish the updated > files to the documentation-website repo. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18170) Deadlock in TableManager#updateAssignmentInternal()
[
https://issues.apache.org/jira/browse/IGNITE-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-18170:
---
Description:
Currently, {{TableManager#updateAssignmentsInternal}} is fully synchronous. The
scenario is as follows:
# {{updateAssignmentsInternal}} starts a RAFT group for a partition
# {{FSMCallerImpl}} finds out that its applied index is below the group
committed index, so it starts to apply the missing log entries in its
{{init()}} method (this is still done synchronously)
# While doing so, it invokes {{{}PartitionListener{}}}, which tries to execute
an insert
# To make an insert, a PK is needed, so it the insertion code tries to obtain
a PK from its future like this: {{pkFuture.join()}}
# That future is completed from {{{}IndexManager#createIndexLocally(){}}},
which is invoked by {{ConfigurationNotifier}} later than
{{updateassignmentsInternal}} in the same thread
# As a result, the PK future cannot be completed before the sync
{{updateAssignmentsInternal}} finishes its job and returns, and it cannot
finish its job before the PK future is completed
We should make {{updateAssignmentsInternal}} async.
was:TBD
> Deadlock in TableManager#updateAssignmentInternal()
> ---
>
> Key: IGNITE-18170
> URL: https://issues.apache.org/jira/browse/IGNITE-18170
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, {{TableManager#updateAssignmentsInternal}} is fully synchronous.
> The scenario is as follows:
> # {{updateAssignmentsInternal}} starts a RAFT group for a partition
> # {{FSMCallerImpl}} finds out that its applied index is below the group
> committed index, so it starts to apply the missing log entries in its
> {{init()}} method (this is still done synchronously)
> # While doing so, it invokes {{{}PartitionListener{}}}, which tries to
> execute an insert
> # To make an insert, a PK is needed, so it the insertion code tries to
> obtain a PK from its future like this: {{pkFuture.join()}}
> # That future is completed from {{{}IndexManager#createIndexLocally(){}}},
> which is invoked by {{ConfigurationNotifier}} later than
> {{updateassignmentsInternal}} in the same thread
> # As a result, the PK future cannot be completed before the sync
> {{updateAssignmentsInternal}} finishes its job and returns, and it cannot
> finish its job before the PK future is completed
> We should make {{updateAssignmentsInternal}} async.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18181) Race during table creation
[
https://issues.apache.org/jira/browse/IGNITE-18181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-18181:
---
Description:
{{tablesByIdVV.update()}} inside {{TableManager#updateAssignments}} initiates
async RAFT groups' start, but its future supplier returns
{{{}completedFuture(null){}}}, so there is no causal dependency between
completion of what {{update()}} returned and the futures that start RAFT
groups; hence, there is no causal dependency between completing 'table created'
future and RAFT groups start.
While {{updateAssignmentsInternal}} is fully synchronous, this is not a
problem. But in IGNITE-18170 we make it async, and here the race starts
manifesting itself.
Probably, update supplier should return a future depending on RAFT group start
future and not just a completed future.
was:TBD
> Race during table creation
> --
>
> Key: IGNITE-18181
> URL: https://issues.apache.org/jira/browse/IGNITE-18181
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{tablesByIdVV.update()}} inside {{TableManager#updateAssignments}} initiates
> async RAFT groups' start, but its future supplier returns
> {{{}completedFuture(null){}}}, so there is no causal dependency between
> completion of what {{update()}} returned and the futures that start RAFT
> groups; hence, there is no causal dependency between completing 'table
> created' future and RAFT groups start.
> While {{updateAssignmentsInternal}} is fully synchronous, this is not a
> problem. But in IGNITE-18170 we make it async, and here the race starts
> manifesting itself.
> Probably, update supplier should return a future depending on RAFT group
> start future and not just a completed future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18176) Update documentation for Apache Ignite 3 introduction
[ https://issues.apache.org/jira/browse/IGNITE-18176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18176: Labels: ignite-3 (was: ) > Update documentation for Apache Ignite 3 introduction > - > > Key: IGNITE-18176 > URL: https://issues.apache.org/jira/browse/IGNITE-18176 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently our introduction page is designed for alpha. We should fix it for > beta, providing a new list of features and limitations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18176) Update documentation for Apache Ignite 3 introduction
[ https://issues.apache.org/jira/browse/IGNITE-18176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-18176: --- Assignee: Igor Gusev (was: Pavel Tupitsyn) > Update documentation for Apache Ignite 3 introduction > - > > Key: IGNITE-18176 > URL: https://issues.apache.org/jira/browse/IGNITE-18176 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently our introduction page is designed for alpha. We should fix it for > beta, providing a new list of features and limitations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18176) Update documentation for Apache Ignite 3 introduction
[ https://issues.apache.org/jira/browse/IGNITE-18176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635205#comment-17635205 ] Pavel Tupitsyn commented on IGNITE-18176: - Merged to main: 96b8bba33c322a0f7ca6277de6b2a2e27a5083fe > Update documentation for Apache Ignite 3 introduction > - > > Key: IGNITE-18176 > URL: https://issues.apache.org/jira/browse/IGNITE-18176 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Pavel Tupitsyn >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently our introduction page is designed for alpha. We should fix it for > beta, providing a new list of features and limitations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18176) Update documentation for Apache Ignite 3 introduction
[ https://issues.apache.org/jira/browse/IGNITE-18176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-18176. - Resolution: Fixed > Update documentation for Apache Ignite 3 introduction > - > > Key: IGNITE-18176 > URL: https://issues.apache.org/jira/browse/IGNITE-18176 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently our introduction page is designed for alpha. We should fix it for > beta, providing a new list of features and limitations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18176) Update documentation for Apache Ignite 3 introduction
[ https://issues.apache.org/jira/browse/IGNITE-18176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18176: Fix Version/s: 3.0.0-beta2 > Update documentation for Apache Ignite 3 introduction > - > > Key: IGNITE-18176 > URL: https://issues.apache.org/jira/browse/IGNITE-18176 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently our introduction page is designed for alpha. We should fix it for > beta, providing a new list of features and limitations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18176) Update documentation for Apache Ignite 3 introduction
[ https://issues.apache.org/jira/browse/IGNITE-18176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18176: Component/s: documentation > Update documentation for Apache Ignite 3 introduction > - > > Key: IGNITE-18176 > URL: https://issues.apache.org/jira/browse/IGNITE-18176 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently our introduction page is designed for alpha. We should fix it for > beta, providing a new list of features and limitations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18176) Update documentation for Apache Ignite 3 introduction
[ https://issues.apache.org/jira/browse/IGNITE-18176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18176: Ignite Flags: (was: Docs Required,Release Notes Required) > Update documentation for Apache Ignite 3 introduction > - > > Key: IGNITE-18176 > URL: https://issues.apache.org/jira/browse/IGNITE-18176 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently our introduction page is designed for alpha. We should fix it for > beta, providing a new list of features and limitations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18176) Update documentation for Apache Ignite 3 introduction
[ https://issues.apache.org/jira/browse/IGNITE-18176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-18176: --- Assignee: Pavel Tupitsyn > Update documentation for Apache Ignite 3 introduction > - > > Key: IGNITE-18176 > URL: https://issues.apache.org/jira/browse/IGNITE-18176 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Pavel Tupitsyn >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently our introduction page is designed for alpha. We should fix it for > beta, providing a new list of features and limitations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18178) .NET: Add support for Native AOT publish
[
https://issues.apache.org/jira/browse/IGNITE-18178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635204#comment-17635204
]
Pavel Tupitsyn commented on IGNITE-18178:
-
Merged to master: 6ad8d4085b48f0bd667f478df7a1b91e521c97c3
> .NET: Add support for Native AOT publish
>
>
> Key: IGNITE-18178
> URL: https://issues.apache.org/jira/browse/IGNITE-18178
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> .NET 7 provides Native AOT capabilities, where the app is published as native
> code without dependencies:
> https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/
> However, if we try to use Ignite.NET in such a scenario, the following error
> is produced (both for thin and thick APIs):
> {code}
> Unhandled Exception: System.TypeInitializationException: A type initializer
> threw an exception. To determine which type, inspect the InnerException's
> StackTrace property.
> ---> System.InvalidOperationException: Unable to get memory copy function
> delegate.
>at Apache.Ignite.Core.Impl.Memory.PlatformMemoryUtils..cctor() + 0x163
>at
> System.Runtime.CompilerServices.ClassConstructorRunner.EnsureClassConstructorRun(StaticClassConstructionContext*)
> + 0xb9
>--- End of inner exception stack trace ---
>at
> System.Runtime.CompilerServices.ClassConstructorRunner.EnsureClassConstructorRun(StaticClassConstructionContext*)
> + 0x153
>at
> System.Runtime.CompilerServices.ClassConstructorRunner.CheckStaticClassConstructionReturnNonGCStaticBase(StaticClassConstructionContext*,
> IntPtr) + 0x9
>at Apache.Ignite.Core.Impl.Memory.PlatformMemoryUtils.AllocatePool() + 0x9
>at Apache.Ignite.Core.Impl.Memory.PlatformMemoryPool..ctor() + 0x20
>at Apache.Ignite.Core.Impl.Memory.PlatformMemoryManager.Pool() + 0x36
>at Apache.Ignite.Core.IgniteConfiguration..ctor(IgniteConfiguration) + 0x32
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration) + 0x54
>at Program.$(String[]) + 0x73
>at Apache.Ignite!+0xfd04bb
> Aborted
> {code}
> * Get rid of unnecessary reflection in *PlatformMemoryUtils* to enable native
> AOT in user apps.
> * Review other cases of reflection usage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18178) .NET: Add support for Native AOT publish
[
https://issues.apache.org/jira/browse/IGNITE-18178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635201#comment-17635201
]
Igor Sapego commented on IGNITE-18178:
--
[~ptupitsyn] looks good to me.
> .NET: Add support for Native AOT publish
>
>
> Key: IGNITE-18178
> URL: https://issues.apache.org/jira/browse/IGNITE-18178
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
>
> .NET 7 provides Native AOT capabilities, where the app is published as native
> code without dependencies:
> https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/
> However, if we try to use Ignite.NET in such a scenario, the following error
> is produced (both for thin and thick APIs):
> {code}
> Unhandled Exception: System.TypeInitializationException: A type initializer
> threw an exception. To determine which type, inspect the InnerException's
> StackTrace property.
> ---> System.InvalidOperationException: Unable to get memory copy function
> delegate.
>at Apache.Ignite.Core.Impl.Memory.PlatformMemoryUtils..cctor() + 0x163
>at
> System.Runtime.CompilerServices.ClassConstructorRunner.EnsureClassConstructorRun(StaticClassConstructionContext*)
> + 0xb9
>--- End of inner exception stack trace ---
>at
> System.Runtime.CompilerServices.ClassConstructorRunner.EnsureClassConstructorRun(StaticClassConstructionContext*)
> + 0x153
>at
> System.Runtime.CompilerServices.ClassConstructorRunner.CheckStaticClassConstructionReturnNonGCStaticBase(StaticClassConstructionContext*,
> IntPtr) + 0x9
>at Apache.Ignite.Core.Impl.Memory.PlatformMemoryUtils.AllocatePool() + 0x9
>at Apache.Ignite.Core.Impl.Memory.PlatformMemoryPool..ctor() + 0x20
>at Apache.Ignite.Core.Impl.Memory.PlatformMemoryManager.Pool() + 0x36
>at Apache.Ignite.Core.IgniteConfiguration..ctor(IgniteConfiguration) + 0x32
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration) + 0x54
>at Program.$(String[]) + 0x73
>at Apache.Ignite!+0xfd04bb
> Aborted
> {code}
> * Get rid of unnecessary reflection in *PlatformMemoryUtils* to enable native
> AOT in user apps.
> * Review other cases of reflection usage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18181) Race during table creation
Roman Puchkovskiy created IGNITE-18181: -- Summary: Race during table creation Key: IGNITE-18181 URL: https://issues.apache.org/jira/browse/IGNITE-18181 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18160) Delete physical data after a Raft Group is stopped
[
https://issues.apache.org/jira/browse/IGNITE-18160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635188#comment-17635188
]
Aleksandr Polovtcev commented on IGNITE-18160:
--
RocksDb variant: IGNITE-18180
> Delete physical data after a Raft Group is stopped
> --
>
> Key: IGNITE-18160
> URL: https://issues.apache.org/jira/browse/IGNITE-18160
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> After a Raft Group is stopped on a node as a consequence of partition
> reassignment, we need to remove the partition data and the corresponding Raft
> log. This implies that for every storage a {{destroy}} method should be
> implemented with the following behaviour: it should return control to the
> caller as soon as possible, i.e. be asynchronous. Ideally this method should
> perform some minimal actions to pose failover guarantees and not wait for the
> data to be removed.
> We need to check that every storage type supports this method and add
> corresponding tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
