[jira] [Assigned] (IGNITE-22567) Add containsAll to RecordView and KeyValueView
[
https://issues.apache.org/jira/browse/IGNITE-22567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov reassigned IGNITE-22567:
Assignee: Mikhail Efremov
> Add containsAll to RecordView and KeyValueView
> --
>
> Key: IGNITE-22567
> URL: https://issues.apache.org/jira/browse/IGNITE-22567
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Ignite 2.x has *containsKeys*, and there is nothing similar in Ignite 3 - we
> are missing a method to check if all specified keys exist in a table.
> Add *containsAll* method to *RecordView* and *KeyValueView*:
> {code:java}
> public interface RecordView {
> boolean containsAll(@Nullable Transaction tx, Collection keyRecs);
> }
> {code}
> {code:java}
> public interface KeyValueView {
> boolean containsAll(@Nullable Transaction tx, Collection keys);
> }
> {code}
> * Include corresponding async methods too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
[
https://issues.apache.org/jira/browse/IGNITE-22315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856838#comment-17856838
]
Mikhail Efremov commented on IGNITE-22315:
--
Actual PR link: https://github.com/apache/ignite-3/pull/3956
> Make raft-client starting only once and only with raft-client and replica
> together
> --
>
> Key: IGNITE-22315
> URL: https://issues.apache.org/jira/browse/IGNITE-22315
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Description*
> The goal is to make sure that when partition starting on an ignite-node, if
> the node in assignments, then there should be only ones raft-node,
> raft-client and replica and no any started entities otherwise.
> *Motivation*
> Now on the one hand in {{TableManager}} there is a path when raft-node and
> replica didn't start, but raft-client is:
> In {{TableManager#startPartitionAndStartClient}} there is a place where
> {{startGroupFut}} returns {{{}false{}}}:\{{ localMemberAssignment}} is
> {{null}} or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns
> {{{}false{}}}. Then, raft-node and replica will not be started, but
> regardless of {{startGroupFut}} result raft client will be started:
> {code:java}
> startGroupFut
> .thenComposeAsync(v -> inBusyLock(busyLock, () -> {
> TableRaftService tableRaftService =
> table.internalTable().tableRaftService();
> try {
> // Return existing service if it's already started.
> return completedFuture(
> (TopologyAwareRaftGroupService)
> tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
> );
> } catch (IgniteInternalException e) {
> // We use "IgniteInternalException" in accordance with the
> javadoc of "partitionRaftGroupService" method.
> try {
> // TODO IGNITE-19614 This procedure takes 10 seconds if
> there's no majority online.
> return raftMgr
> .startRaftGroupService(replicaGrpId,
> newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
> } catch (NodeStoppingException ex) {
> return failedFuture(ex);
> }
> }
> }), ioExecutor)
> .thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, ()
> -> {
> ((InternalTableImpl) internalTbl).tableRaftService()
> .updateInternalTableRaftGroupService(partId,
> updatedRaftGroupService);
> boolean startedRaftNode = startGroupFut.join();
> if (localMemberAssignment == null || !startedRaftNode ||
> replicaMgr.isReplicaStarted(replicaGrpId)) {
> return;
> } {code}
> the code shows that {{v}} argument ({{{}startGroupFut{}}}'s result) in the
> lambda doesn't affect on raft-client's starting, and also the client is put
> into {{TableRaftService}} then regardless of replica's starting.
> On the other hand, there is a place that rely on raft-client creation on
> every node with table's ID in {{TableManager#tables}} map: inside
> {{TableManager#handleChangePendingAssignmentEvent}} there are two calls:
> # the same name method
> {{{}TableManager#handleChangePendingAssignmentEvent{}}}}}{}}}
> # {{TableManager#changePeersOnRebalance}}
> Both are asking for internal table's
> {{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no
> any checks about is the local node is suitable for raft-entities and replica
> starting or they are already started.
>
> Then, when we would try to fix instant raft-client starting it will lead to
> instant {{IgniteInternalException}} with _"No such partition P in table T"_
> from {{{}TableRaftService#{}}}{{{}partitionRaftGroupService{}}}. This is a
> problem that should be solved.
> {color:#383838}*Definition of done*{color}
> # {color:#383838}Raft-client must be started only together with raft-node
> and replica or shouldn't be started otherwise.{color}
> # {color:#383838}{{TableRaftService}} shouldn't be requested for raft-client
> if the local node isn't in a raft group.{color}
> # {color:#383838}Some tests may rely on described behavior, then failed
> tests should be investigated and, probably fixed.{color}
> # {color:#383838}New tests that check single starting of raft-node,
> raft-client and replica together are required{color}
> {color:#0f54d6} {color}
> {color:#383838} {color}
> {color:#00855f} {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22388) TableManagerTest revision
[
https://issues.apache.org/jira/browse/IGNITE-22388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22388:
-
Description:
*Description*
During IGNITE-22315 we found that tests
{{TableManagerTest#tableManagerStopTest*}} are failed and after investigations
there was clear that several static mocks aren't in use in tests that leads to
actually unworked tests. The special case was fixed in IGNITE-22355, but there
are more issued places, especially described below. The main goal of the ticket
is to revise the test class and rewrite it in accordings to its purpose without
any excessive, unused code lines.
*Motivation*
There will be provided 3 examples with problematic code the was found in
{{TableManagerTable#tableManagerStopTest*}} but not limited.
The first code smell is the name of the tests:
{{{}TableManagerTable#tableManagerStopTest1-4{}}}. The names doesn't tell how
1st and 4th are different.
The second is another (except that in IGNITE-22355) static mock
{{schemaServiceMock}} in try-with-resources block that shouldn't work outside
the block:
{code:java}
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
String consistentId = "node0";
// ...
when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
UUID.randomUUID().toString(),
consistentId,
new NetworkAddress("localhost", 47500)
));
try (MockedStatic schemaServiceMock =
mockStatic(SchemaUtils.class)) {
schemaServiceMock.when(() -> SchemaUtils.prepareSchemaDescriptor(any()))
.thenReturn(mock(SchemaDescriptor.class));
}
try (MockedStatic affinityServiceMock =
mockStatic(AffinityUtils.class)) {
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityServiceMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(), anyInt()))
.thenReturn(assignment);
}
//...
{code}
In the test class there are only two such mocks and {{affinityServiceMock}} is
removed in IGNITE-22355, but {{schemaServiceMock}} still requires reworking.
The third issue in the code above: the problem is that {{ts}} isn't really
uses: {{ts}} is topology service field in the test class, but for
{{TableManager}} creation topology service arrives from a mocked cluster
service:
{code:java}
private TableManager createTableManager(/*...*/) {
TableManager tableManager = new TableManager(
// ...
clusterService.topologyService(),
//...
{code}
{{topologyService}} is mocked in {{before}} with another mock:
{code:java}
@BeforeEach
void before() throws NodeStoppingException {
// ...
TopologyService topologyService = mock(TopologyService.class);
when(clusterService.topologyService()).thenReturn(topologyService);
// ...
{code}
That means, that {{ts}} field isn't in use and the code above is just for
nothing.
There only 3 arguments, but they shows drastical problems with the test class
and the ticket calls for the class reworking.
*Definition of done*
# Tests' names should have meaningful names that differs one from another.
# Tests shouldn't contain unused and meaningless code.
was:
*Description*
During IGNITE-22315 we found that tests
{{TableManagerTable#tableManagerStopTest*}} are failed and after investigations
there was clear that several static mocks aren't in use in tests that leads to
actually unworked tests. The special case was fixed in IGNITE-22355, but there
are more issued places, especially described below. The main goal of the ticket
is to revise the test class and rewrite it in accordings to its purpose without
any excessive, unused code lines.
*Motivation*
There will be provided 3 examples with problematic code the was found in
{{TableManagerTable#tableManagerStopTest*}} but not limited.
The first code smell is the name of the tests:
{{{}TableManagerTable#tableManagerStopTest1-4{}}}. The names doesn't tell how
1st and 4th are different.
The second is another (except that in IGNITE-22355) static mock
{{schemaServiceMock}} in try-with-resources block that shouldn't work outside
the block:
{code:java}
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
String consistentId = "node0";
// ...
when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
UUID.randomUUID().toString(),
consistentId,
new NetworkAddress("localhost", 47500)
));
try (MockedStatic schemaServiceMock =
[jira] [Updated] (IGNITE-22388) TableManagerTest revision
[
https://issues.apache.org/jira/browse/IGNITE-22388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22388:
-
Description:
*Description*
During IGNITE-22315 we found that tests
{{TableManagerTable#tableManagerStopTest*}} are failed and after investigations
there was clear that several static mocks aren't in use in tests that leads to
actually unworked tests. The special case was fixed in IGNITE-22355, but there
are more issued places, especially described below. The main goal of the ticket
is to revise the test class and rewrite it in accordings to its purpose without
any excessive, unused code lines.
*Motivation*
There will be provided 3 examples with problematic code the was found in
{{TableManagerTable#tableManagerStopTest*}} but not limited.
The first code smell is the name of the tests:
{{{}TableManagerTable#tableManagerStopTest1-4{}}}. The names doesn't tell how
1st and 4th are different.
The second is another (except that in IGNITE-22355) static mock
{{schemaServiceMock}} in try-with-resources block that shouldn't work outside
the block:
{code:java}
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
String consistentId = "node0";
// ...
when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
UUID.randomUUID().toString(),
consistentId,
new NetworkAddress("localhost", 47500)
));
try (MockedStatic schemaServiceMock =
mockStatic(SchemaUtils.class)) {
schemaServiceMock.when(() -> SchemaUtils.prepareSchemaDescriptor(any()))
.thenReturn(mock(SchemaDescriptor.class));
}
try (MockedStatic affinityServiceMock =
mockStatic(AffinityUtils.class)) {
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityServiceMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(), anyInt()))
.thenReturn(assignment);
}
//...
{code}
In the test class there are only two such mocks and {{affinityServiceMock}} is
removed in IGNITE-22355, but {{schemaServiceMock}} still requires reworking.
The third issue in the code above: the problem is that {{ts}} isn't really
uses: {{ts}} is topology service field in the test class, but for
{{TableManager}} creation topology service arrives from a mocked cluster
service:
{code:java}
private TableManager createTableManager(/*...*/) {
TableManager tableManager = new TableManager(
// ...
clusterService.topologyService(),
//...
{code}
{{topologyService}} is mocked in {{before}} with another mock:
{code:java}
@BeforeEach
void before() throws NodeStoppingException {
// ...
TopologyService topologyService = mock(TopologyService.class);
when(clusterService.topologyService()).thenReturn(topologyService);
// ...
{code}
That means, that {{ts}} field isn't in use and the code above is just for
nothing.
There only 3 arguments, but they shows drastical problems with the test class
and the ticket calls for the class reworking.
*Definition of done*
# Tests' names should have meaningful names that differs one from another.
# Tests shouldn't contain unused and meaningless code.
was:
*Description*
During IGNITE-22315 we found that tests
{{TableManagerTable#tableManagerStopTest*}} are failed and after investigations
there was clear that several static mocks aren't in use in tests that leads to
actually unworked tests. The special case was fixed in IGNITE-22355, but there
are more issued places, especially described below. The main goal of the ticket
is to revise the test class and rewrite it in accordings to its purpose without
any excessive, unused code lines.
*Motivation*
There will be provided 3 examples with problematic code the was found in
{{TableManagerTable#tableManagerStopTest*}} but not limited.
The first code smell is the name of the tests:
{{TableManagerTable#tableManagerStopTest1-4}}. The names doesn't tell how 1st
and 4th are different.
The second is another (except that in IGNITE-22355) static mock
{{schemaServiceMock}} in try-with-resources block that shouldn't work outside
the block:
{code:title=|language=java|collapse=false}private TableViewInternal
mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
String consistentId = "node0";
when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
UUID.randomUUID().toString(),
consistentId,
new NetworkAddress("localhost", 47500)
));
try (MockedStatic
[jira] [Created] (IGNITE-22388) TableManagerTest revision
Mikhail Efremov created IGNITE-22388:
Summary: TableManagerTest revision
Key: IGNITE-22388
URL: https://issues.apache.org/jira/browse/IGNITE-22388
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
*Description*
During IGNITE-22315 we found that tests
{{TableManagerTable#tableManagerStopTest*}} are failed and after investigations
there was clear that several static mocks aren't in use in tests that leads to
actually unworked tests. The special case was fixed in IGNITE-22355, but there
are more issued places, especially described below. The main goal of the ticket
is to revise the test class and rewrite it in accordings to its purpose without
any excessive, unused code lines.
*Motivation*
There will be provided 3 examples with problematic code the was found in
{{TableManagerTable#tableManagerStopTest*}} but not limited.
The first code smell is the name of the tests:
{{TableManagerTable#tableManagerStopTest1-4}}. The names doesn't tell how 1st
and 4th are different.
The second is another (except that in IGNITE-22355) static mock
{{schemaServiceMock}} in try-with-resources block that shouldn't work outside
the block:
{code:title=|language=java|collapse=false}private TableViewInternal
mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
String consistentId = "node0";
when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
UUID.randomUUID().toString(),
consistentId,
new NetworkAddress("localhost", 47500)
));
try (MockedStatic schemaServiceMock =
mockStatic(SchemaUtils.class)) {
schemaServiceMock.when(() -> SchemaUtils.prepareSchemaDescriptor(any()))
.thenReturn(mock(SchemaDescriptor.class));
}
try (MockedStatic affinityServiceMock =
mockStatic(AffinityUtils.class)) {
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityServiceMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(), anyInt()))
.thenReturn(assignment);
}
//...
{code}
In the test class there are only two such mocks and {{affinityServiceMock}} is
removed in IGNITE-22355, but {{schemaServiceMock}} still requires reworking.
The third issue in the code above is {{String consistentId = "node0"}} for mock
{{when(ts.getByConsistentId(any()))}}. The problem is that {{ts}} isn't really
uses: {{ts}} is topology service field in the test class, but for
{{TableManager}} creation topology service arrives from a mocked cluster
service:
{code:title=|language=java|collapse=false}private TableManager
createTableManager(/*...*/) {
TableManager tableManager = new TableManager(
// ...
clusterService.topologyService(),
//...
{code}
{{topologyService}} is mocked in {{before}} with another mock:
{code:title=|language=java|collapse=false}@BeforeEach
void before() throws NodeStoppingException {
// ...
TopologyService topologyService = mock(TopologyService.class);
when(clusterService.topologyService()).thenReturn(topologyService);
// ...
{code}
That means, that {{ts}} field isn't in use and the code above is just for
nothing.
There only 3 arguments, but they shows drastical problems with the test class
and the ticket calls for the class reworking.
*Definition of done*
# Tests' names should have meaningful names that differs one from another.
# Tests shouldn't contain unused and meaningless code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22355) TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay don't work properly
[
https://issues.apache.org/jira/browse/IGNITE-22355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850479#comment-17850479
]
Mikhail Efremov edited comment on IGNITE-22355 at 5/29/24 8:03 PM:
---
Due to [https://github.com/mockito/mockito/issues/2142] static mocks aren't
accessible from a different threads. I tired to use static mock as a field:
{code:java}
private MockedStatic affinityUtilsStaticMock;
@BeforeEach
void before() throws NodeStoppingException {
affinityUtilsStaticMock = mockStatic(AffinityUtils.class);
// ...
}
// ...
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
// ...
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityUtilsStaticMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(),
anyInt())).thenReturn(assignment);
TableManager tableManager = createTableManager(tblManagerFut);
// ...
}
// ...
void after() throws Exception {
ComponentContext componentContext = new ComponentContext();
closeAll(
// ...
affinityUtilsStaticMock
);
}
{code}
But inside inside {{TableManager#getOrCreateAssignments}} it didn't works, the
place:
{code:java}
assignmentsFuture = distributionZoneManager.dataNodes(causalityToken,
catalogVersion, zoneDescriptor.id())
.thenApply(dataNodes -> AffinityUtils.calculateAssignments(
dataNodes,
zoneDescriptor.partitions(),
zoneDescriptor.replicas()
)//...
{code}
returns a list with size {{zoneDescriptor.partitions()}} of empty node set as
the ticket describes as problem. In debug we can check is the mocking still
works with:
{code:java}
Mockito.mockingDetails(AffinityUtils.class).isMock()
{code}
and it returns {{false}}. In oppisite, we can check that after {{.when}}
statement the same check returns {{true}}.
The temporal solution is to mock {{DistributionZoneManager#dataNodes}} with
non-empty set with {{node1}} inside:
{code:java}
when(distributionZoneManager.dataNodes(anyLong(), anyInt(), anyInt()))
.thenReturn(completedFuture(Set.of(NODE_NAME)));
{code}
where {{NODE_NAME}} is {{node1}}.
Then, non-mocked {{AffinityUtils#calculateAssignments}} returns a list with
size {{zoneDescriptor.partitions()}} (in the case partitions equals 32) of
non-empty node set with {{node1}} inside as desired.
The test class demands rewriting, the related ticket must be created.
was (Author: JIRAUSER303791):
Due to [https://github.com/mockito/mockito/issues/2142] static mocks aren't
accessible from a different threads. I tired to use static mock as a field:
{code:java}
private MockedStatic affinityUtilsStaticMock;
@BeforeEach
void before() throws NodeStoppingException {
affinityUtilsStaticMock = mockStatic(AffinityUtils.class);
// ...
}
// ...
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
// ...
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityUtilsStaticMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(),
anyInt())).thenReturn(assignment);
TableManager tableManager = createTableManager(tblManagerFut);
// ...
}
// ...
void after() throws Exception {
ComponentContext componentContext = new ComponentContext();
closeAll(
// ...
affinityUtilsStaticMock
);
}
{code}
But inside inside {{TableManager#getOrCreateAssignments}} it didn't works, the
place:
{code:java}
assignmentsFuture = distributionZoneManager.dataNodes(causalityToken,
catalogVersion, zoneDescriptor.id())
.thenApply(dataNodes -> AffinityUtils.calculateAssignments(
dataNodes,
zoneDescriptor.partitions(),
zoneDescriptor.replicas()
)//...
{code}
returns a list with size {{zoneDescriptor.partitions()}} of empty node set as
the ticket describes as problem. In debug we can check is the mocking still
works with:
{code:java}
Mockito.mockingDetails(AffinityUtils.class).isMock()
{code}
and it returns {{false}}. In oppisite, we can check that after {{.when}}
statement the same check returns {{true}}.
The temporal solution is to mock {{DistributionZoneManager#dataNodes}} with
non-empty set with {{node1}} inside:
{code:java}
when(distributionZoneManager.dataNodes(anyLong(), anyInt(), anyInt()))
.thenReturn(completedFuture(Set.of(NODE_NAME)));
[jira] [Comment Edited] (IGNITE-22355) TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay don't work properly
[
https://issues.apache.org/jira/browse/IGNITE-22355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850479#comment-17850479
]
Mikhail Efremov edited comment on IGNITE-22355 at 5/29/24 7:34 PM:
---
Due to [https://github.com/mockito/mockito/issues/2142] static mocks aren't
accessible from a different threads. I tired to use static mock as a field:
{code:java}
private MockedStatic affinityUtilsStaticMock;
@BeforeEach
void before() throws NodeStoppingException {
affinityUtilsStaticMock = mockStatic(AffinityUtils.class);
// ...
}
// ...
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
// ...
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityUtilsStaticMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(),
anyInt())).thenReturn(assignment);
TableManager tableManager = createTableManager(tblManagerFut);
// ...
}
// ...
void after() throws Exception {
ComponentContext componentContext = new ComponentContext();
closeAll(
// ...
affinityUtilsStaticMock
);
}
{code}
But inside inside {{TableManager#getOrCreateAssignments}} it didn't works, the
place:
{code:java}
assignmentsFuture = distributionZoneManager.dataNodes(causalityToken,
catalogVersion, zoneDescriptor.id())
.thenApply(dataNodes -> AffinityUtils.calculateAssignments(
dataNodes,
zoneDescriptor.partitions(),
zoneDescriptor.replicas()
)//...
{code}
returns a list with size {{zoneDescriptor.partitions()}} of empty node set as
the ticket describes as problem. In debug we can check is the mocking still
works with:
{code:java}
Mockito.mockingDetails(AffinityUtils.class).isMock()
{code}
and it returns {{false}}. In oppisite, we can check that after {{.when}}
statement the same check returns {{true}}.
The temporal solution is to mock {{DistributionZoneManager#dataNodes}} with
non-empty set with {{node1}} inside:
{code:java}
when(distributionZoneManager.dataNodes(anyLong(), anyInt(), anyInt()))
.thenReturn(completedFuture(Set.of(NODE_NAME)));
{code}
where {{NODE_NAME}} is {{node1}}.
Then, non-mocked {{AffinityUtils#calculateAssignments}} returns a list with
size {{zoneDescriptor.partitions()}} (in the case partitions equals 32) of
non-empty node set with {{node1} inside as desired.
The test class demands rewriting, the related ticket must be created.
was (Author: JIRAUSER303791):
Due to [https://github.com/mockito/mockito/issues/2142] static mocks aren't
accessible from a different threads. I tired to use static mock as a field:
{code:java}
private MockedStatic affinityUtilsStaticMock;
@BeforeEach
void before() throws NodeStoppingException {
affinityUtilsStaticMock = mockStatic(AffinityUtils.class);
// ...
}
// ...
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
// ...
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityUtilsStaticMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(),
anyInt())).thenReturn(assignment);
TableManager tableManager = createTableManager(tblManagerFut);
// ...
}
// ...
void after() throws Exception {
ComponentContext componentContext = new ComponentContext();
closeAll(
// ...
affinityUtilsStaticMock
);
}
{code}
But inside inside {{TableManager#getOrCreateAssignments}} it didn't works, the
place:
{code:java}
assignmentsFuture = distributionZoneManager.dataNodes(causalityToken,
catalogVersion, zoneDescriptor.id())
.thenApply(dataNodes -> AffinityUtils.calculateAssignments(
dataNodes,
zoneDescriptor.partitions(),
zoneDescriptor.replicas()
)//...
{code}
returns a list with size {{zoneDescriptor.partitions()}} of empty node set as
the ticket describes as problem. In debug we can check is the mocking still
works with:
{code:java}
Mockito.mockingDetails(AffinityUtils.class).isMock()
{code}
and it returns {{false}}. In oppisite, we can check that after {{.when}}
statement the same check returns {{true}}.
The temporal solution is to mock {{DistributionZoneManager#dataNodes}} with
non-empty set with {{node1}} inside. Then, non-mocked
{{AffinityUtils#calculateAssignments}} returns a list with size
{{zoneDescriptor.partitions()}} (in the case partitions equals 32)
[jira] [Comment Edited] (IGNITE-22355) TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay don't work properly
[
https://issues.apache.org/jira/browse/IGNITE-22355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850479#comment-17850479
]
Mikhail Efremov edited comment on IGNITE-22355 at 5/29/24 7:26 PM:
---
Due to [https://github.com/mockito/mockito/issues/2142] static mocks aren't
accessible from a different threads. I tired to use static mock as a field:
{code:java}
private MockedStatic affinityUtilsStaticMock;
@BeforeEach
void before() throws NodeStoppingException {
affinityUtilsStaticMock = mockStatic(AffinityUtils.class);
// ...
}
// ...
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
// ...
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityUtilsStaticMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(),
anyInt())).thenReturn(assignment);
TableManager tableManager = createTableManager(tblManagerFut);
// ...
}
// ...
void after() throws Exception {
ComponentContext componentContext = new ComponentContext();
closeAll(
// ...
affinityUtilsStaticMock
);
}
{code}
But inside inside {{TableManager#getOrCreateAssignments}} it didn't works, the
place:
{code:java}
assignmentsFuture = distributionZoneManager.dataNodes(causalityToken,
catalogVersion, zoneDescriptor.id())
.thenApply(dataNodes -> AffinityUtils.calculateAssignments(
dataNodes,
zoneDescriptor.partitions(),
zoneDescriptor.replicas()
)//...
{code}
returns a list with size {{zoneDescriptor.partitions()}} of empty node set as
the ticket describes as problem. In debug we can check is the mocking still
works with:
{code:java}
Mockito.mockingDetails(AffinityUtils.class).isMock()
{code}
and it returns {{false}}. In oppisite, we can check that after {{.when}}
statement the same check returns {{true}}.
The temporal solution is to mock {{DistributionZoneManager#dataNodes}} with
non-empty set with {{node1}} inside. Then, non-mocked
{{AffinityUtils#calculateAssignments}} returns a list with size
{{zoneDescriptor.partitions()}} (in the case partitions equals 32) of non-empty
node set with {{node1} inside as desired.
The test class demands rewriting, the related ticket must be created.
was (Author: JIRAUSER303791):
Due to [https://github.com/mockito/mockito/issues/2142] static mocks aren't
accessible from a different threads. I tired to use static mock as a field:
{code:java}
private MockedStatic affinityUtilsStaticMock;
@BeforeEach
void before() throws NodeStoppingException {
affinityUtilsStaticMock = mockStatic(AffinityUtils.class);
// ...
}
// ...
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
// ...
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityUtilsStaticMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(),
anyInt())).thenReturn(assignment);
TableManager tableManager = createTableManager(tblManagerFut);
// ...
}
// ...
void after() throws Exception {
ComponentContext componentContext = new ComponentContext();
closeAll(
// ...
affinityUtilsStaticMock
);
}
{code}
But inside inside {{TableManager#getOrCreateAssignments}} it didn't works, the
place:
{code:java}
assignmentsFuture = distributionZoneManager.dataNodes(causalityToken,
catalogVersion, zoneDescriptor.id())
.thenApply(dataNodes -> AffinityUtils.calculateAssignments(
dataNodes,
zoneDescriptor.partitions(),
zoneDescriptor.replicas()
)//...
{code}
returns a list with size {{zoneDescriptor.partitions()}} of empty node set as
the ticket describes as problem. In debug we can check is the mocking still
works with:
{code:java}
Mockito.mockingDetails(AffinityUtils.class).isMock()
{code}
and it returns {{false}}. In oppisite, we can check that after {{.when}}
statement the same check returns {{true}}.
The temporal solution is to mock {{DistributionZoneManager#dataNodes}} with
non-empty set with {{node1}} inside. Then, non-mocked
{{AffinityUtils#calculateAssignments}} returns a list with size
{{zoneDescriptor.partitions()}} (in the case partitions equals 32) of non-empty
node set with {{node1} inside as desired.
The test class demands rewriting, the related ticket must be created.
> TableManagerTest's static mocks from
[jira] [Commented] (IGNITE-22355) TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay don't work properly
[
https://issues.apache.org/jira/browse/IGNITE-22355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850479#comment-17850479
]
Mikhail Efremov commented on IGNITE-22355:
--
Due to [https://github.com/mockito/mockito/issues/2142] static mocks aren't
accessible from a different threads. I tired to use static mock as a field:
{code:java}
private MockedStatic affinityUtilsStaticMock;
@BeforeEach
void before() throws NodeStoppingException {
affinityUtilsStaticMock = mockStatic(AffinityUtils.class);
// ...
}
// ...
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
// ...
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityUtilsStaticMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(),
anyInt())).thenReturn(assignment);
TableManager tableManager = createTableManager(tblManagerFut);
// ...
}
// ...
void after() throws Exception {
ComponentContext componentContext = new ComponentContext();
closeAll(
// ...
affinityUtilsStaticMock
);
}
{code}
But inside inside {{TableManager#getOrCreateAssignments}} it didn't works, the
place:
{code:java}
assignmentsFuture = distributionZoneManager.dataNodes(causalityToken,
catalogVersion, zoneDescriptor.id())
.thenApply(dataNodes -> AffinityUtils.calculateAssignments(
dataNodes,
zoneDescriptor.partitions(),
zoneDescriptor.replicas()
)//...
{code}
returns a list with size {{zoneDescriptor.partitions()}} of empty node set as
the ticket describes as problem. In debug we can check is the mocking still
works with:
{code:java}
Mockito.mockingDetails(AffinityUtils.class).isMock()
{code}
and it returns {{false}}. In oppisite, we can check that after {{.when}}
statement the same check returns {{true}}.
The temporal solution is to mock {{DistributionZoneManager#dataNodes}} with
non-empty set with {{node1}} inside. Then, non-mocked
{{AffinityUtils#calculateAssignments}} returns a list with size
{{zoneDescriptor.partitions()}} (in the case partitions equals 32) of non-empty
node set with {{node1} inside as desired.
The test class demands rewriting, the related ticket must be created.
> TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay
> don't work properly
> -
>
> Key: IGNITE-22355
> URL: https://issues.apache.org/jira/browse/IGNITE-22355
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> In tests table creation method there is code like below:
>
> {code:java}
> try (MockedStatic affinityServiceMock =
> mockStatic(AffinityUtils.class)) {
> ArrayList> assignment = new ArrayList<>(PARTITIONS);
> for (int part = 0; part < PARTITIONS; part++) {
> assignment.add(new ArrayList<>(Collections.singleton(node)));
> }
> affinityServiceMock.when(() -> AffinityUtils.calculateAssignments(any(),
> anyInt(), anyInt()))
> .thenReturn(assignment);
> }{code}
> As the result {{AffinityUtils#calculateAssignments}} calls outside of
> try-with-resources returns List of empty sets, but desired behavior is list
> of sets with the given {{{}node{}}}.
> *Definition of done*
> {{AffinityUtils#calculateAssignments}} call inside
> {{TableManager#getOrCreateAssignments}} must returns list of non-empty sets
> with single node.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22355) TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay don't work properly
[
https://issues.apache.org/jira/browse/IGNITE-22355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850479#comment-17850479
]
Mikhail Efremov edited comment on IGNITE-22355 at 5/29/24 7:25 PM:
---
Due to [https://github.com/mockito/mockito/issues/2142] static mocks aren't
accessible from a different threads. I tired to use static mock as a field:
{code:java}
private MockedStatic affinityUtilsStaticMock;
@BeforeEach
void before() throws NodeStoppingException {
affinityUtilsStaticMock = mockStatic(AffinityUtils.class);
// ...
}
// ...
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
// ...
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityUtilsStaticMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(),
anyInt())).thenReturn(assignment);
TableManager tableManager = createTableManager(tblManagerFut);
// ...
}
// ...
void after() throws Exception {
ComponentContext componentContext = new ComponentContext();
closeAll(
// ...
affinityUtilsStaticMock
);
}
{code}
But inside inside {{TableManager#getOrCreateAssignments}} it didn't works, the
place:
{code:java}
assignmentsFuture = distributionZoneManager.dataNodes(causalityToken,
catalogVersion, zoneDescriptor.id())
.thenApply(dataNodes -> AffinityUtils.calculateAssignments(
dataNodes,
zoneDescriptor.partitions(),
zoneDescriptor.replicas()
)//...
{code}
returns a list with size {{zoneDescriptor.partitions()}} of empty node set as
the ticket describes as problem. In debug we can check is the mocking still
works with:
{code:java}
Mockito.mockingDetails(AffinityUtils.class).isMock()
{code}
and it returns {{false}}. In oppisite, we can check that after {{.when}}
statement the same check returns {{true}}.
The temporal solution is to mock {{DistributionZoneManager#dataNodes}} with
non-empty set with {{node1}} inside. Then, non-mocked
{{AffinityUtils#calculateAssignments}} returns a list with size
{{zoneDescriptor.partitions()}} (in the case partitions equals 32) of non-empty
node set with {{node1} inside as desired.
The test class demands rewriting, the related ticket must be created.
was (Author: JIRAUSER303791):
Due to [https://github.com/mockito/mockito/issues/2142] static mocks aren't
accessible from a different threads. I tired to use static mock as a field:
{code:java}
private MockedStatic affinityUtilsStaticMock;
@BeforeEach
void before() throws NodeStoppingException {
affinityUtilsStaticMock = mockStatic(AffinityUtils.class);
// ...
}
// ...
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
// ...
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityUtilsStaticMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(),
anyInt())).thenReturn(assignment);
TableManager tableManager = createTableManager(tblManagerFut);
// ...
}
// ...
void after() throws Exception {
ComponentContext componentContext = new ComponentContext();
closeAll(
// ...
affinityUtilsStaticMock
);
}
{code}
But inside inside {{TableManager#getOrCreateAssignments}} it didn't works, the
place:
{code:java}
assignmentsFuture = distributionZoneManager.dataNodes(causalityToken,
catalogVersion, zoneDescriptor.id())
.thenApply(dataNodes -> AffinityUtils.calculateAssignments(
dataNodes,
zoneDescriptor.partitions(),
zoneDescriptor.replicas()
)//...
{code}
returns a list with size {{zoneDescriptor.partitions()}} of empty node set as
the ticket describes as problem. In debug we can check is the mocking still
works with:
{code:java}
Mockito.mockingDetails(AffinityUtils.class).isMock()
{code}
and it returns {{false}}. In oppisite, we can check that after {{.when}}
statement the same check returns {{true}}.
The temporal solution is to mock {{DistributionZoneManager#dataNodes}} with
non-empty set with {{node1}} inside. Then, non-mocked
{{AffinityUtils#calculateAssignments}} returns a list with size
{{zoneDescriptor.partitions()}} (in the case partitions equals 32) of non-empty
node set with {{node1} inside as desired.
The test class demands rewriting, the related ticket must be created.
> TableManagerTest's static mocks from
[jira] [Created] (IGNITE-22373) Delete startReplica overloadings from ReplicaManager
Mikhail Efremov created IGNITE-22373:
Summary: Delete startReplica overloadings from ReplicaManager
Key: IGNITE-22373
URL: https://issues.apache.org/jira/browse/IGNITE-22373
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
*Description*
After IGNITE-21805 there are still 2 redundant {{Replica#startReplica}}
overloads:
{code:java}
public CompletableFuture startReplica(
ReplicationGroupId replicaGrpId,
PeersAndLearners newConfiguration,
Consumer updateTableRaftService,
Function createListener,
PendingComparableValuesTracker storageIndexTracker,
CompletableFuture newRaftClientFut
) { ... }
{code}
{code:java}
public CompletableFuture startReplica(
ReplicationGroupId replicaGrpId,
PendingComparableValuesTracker storageIndexTracker,
CompletableFuture newReplicaListenerFut
) { ... }
{code}
They are marked now as {{@VisibleForTesting}} and {{@Deprecated}} both and
their only purpose is to be used in tests.
The main goal of this ticket is to delete them or make them private.
*Motivation*
There should the only one public {{Replica#startReplica}} method for
replication group creation.
*Definition of Done*
1. Both provided above overloads of {{Replica#startReplica}} should be deleted
or be private.
2. All tests that called the overloaded methods should be fixed in favor of the
single {{Replica#startReplica}} method which is called now in {{TableManager}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22372) Moving RaftManager into Replica
[
https://issues.apache.org/jira/browse/IGNITE-22372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22372:
-
Description:
*Description*
The main goal is to move {{RaftManager}} into {{Replica}} through it's
constructor and starting raft-node and raft-client in {{Replica}} and stopping
on {{Replica}}'s shutdown process inside a corresponding replica.
*Motivation*
After IGNITE-21805 {{RaftManager}} was moved from {{TableManager}} into
{{ReplicaManager}}. Therefore raft-nodes and raft-replicas are starting and
stopping inside {{ReplicaManager}}. The main idea of previous ticket is to hide
all RAFT-related entities as far as possible into Replica itself. Then,
{{RaftManager}} and related usages should be moved into {{ReplicaManager.}}
*Definition of Done*
# {{RaftManager}} component is moved to {{Replica}}.
# {{Loza#startRaftGroupNode}} and {{RaftManager#stopRaftNodes}} should be
called inside {{Replica}}.
*Current issues*
There no of determination how to handle this code: {{((Loza)
raftManager).volatileRaft().logStorage().value();}} In theory, the only purpose
is to create raft options and pass them into {{Loza#startRaftGroupNode}} and
critical challenges shouldn't arise there. But the attention is here.
was:
*Description*
The main goal is to move {{RaftManager}} into {{Replica}} through it's
constructor and starting raft-node and raft-client in {{Replica}} and stopping
on {{Replica}}'s shutdown process inside a corresponding replica.
*Motivation*
After IGNITE-21805 {{RaftManager}} was moved from {{TableManager}} into
{{ReplicaManager}}. Therefore raft-nodes and raft-replicas are starting and
stopping inside {{ReplicaManager}}. The main idea of previous ticket is to hide
all RAFT-related entities as far as possible into Replica itself. Then,
{{RaftManager}} and related usages should be moved into {{ReplicaManager.}}
*Definition of Done*
# {{RaftManager}} component is moved to {{Replica}}.
# {{Loza#startRaftGroupNode}} and {{RaftManager#stopRaftNodes}} should be
called inside {{Replica}}.
> Moving RaftManager into Replica
> ---
>
> Key: IGNITE-22372
> URL: https://issues.apache.org/jira/browse/IGNITE-22372
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The main goal is to move {{RaftManager}} into {{Replica}} through it's
> constructor and starting raft-node and raft-client in {{Replica}} and
> stopping on {{Replica}}'s shutdown process inside a corresponding replica.
> *Motivation*
> After IGNITE-21805 {{RaftManager}} was moved from {{TableManager}} into
> {{ReplicaManager}}. Therefore raft-nodes and raft-replicas are starting and
> stopping inside {{ReplicaManager}}. The main idea of previous ticket is to
> hide all RAFT-related entities as far as possible into Replica itself. Then,
> {{RaftManager}} and related usages should be moved into {{ReplicaManager.}}
> *Definition of Done*
> # {{RaftManager}} component is moved to {{Replica}}.
> # {{Loza#startRaftGroupNode}} and {{RaftManager#stopRaftNodes}} should be
> called inside {{Replica}}.
> *Current issues*
> There no of determination how to handle this code: {{((Loza)
> raftManager).volatileRaft().logStorage().value();}} In theory, the only
> purpose is to create raft options and pass them into
> {{Loza#startRaftGroupNode}} and critical challenges shouldn't arise there.
> But the attention is here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22372) Moving RaftManager into Replica
Mikhail Efremov created IGNITE-22372:
Summary: Moving RaftManager into Replica
Key: IGNITE-22372
URL: https://issues.apache.org/jira/browse/IGNITE-22372
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
*Description*
The main goal is to move {{RaftManager}} into {{Replica}} through it's
constructor and starting raft-node and raft-client in {{Replica}} and stopping
on {{Replica}}'s shutdown process inside a corresponding replica.
*Motivation*
After IGNITE-21805 {{RaftManager}} was moved from {{TableManager}} into
{{ReplicaManager}}. Therefore raft-nodes and raft-replicas are starting and
stopping inside {{ReplicaManager}}. The main idea of previous ticket is to hide
all RAFT-related entities as far as possible into Replica itself. Then,
{{RaftManager}} and related usages should be moved into {{ReplicaManager.}}
*Definition of Done*
# {{RaftManager}} component is moved to {{Replica}}.
# {{Loza#startRaftGroupNode}} and {{RaftManager#stopRaftNodes}} should be
called inside {{Replica}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22355) TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay don't work properly
[
https://issues.apache.org/jira/browse/IGNITE-22355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22355:
-
Summary: TableManagerTest's static mocks from
#mockManagersAndCreateTableWithDelay don't work properly (was: TableManager's
static mocks from #mockManagersAndCreateTableWithDelay don't work)
> TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay
> don't work properly
> -
>
> Key: IGNITE-22355
> URL: https://issues.apache.org/jira/browse/IGNITE-22355
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> In tests table creation method there is code like below:
>
> {code:java}
> try (MockedStatic affinityServiceMock =
> mockStatic(AffinityUtils.class)) {
> ArrayList> assignment = new ArrayList<>(PARTITIONS);
> for (int part = 0; part < PARTITIONS; part++) {
> assignment.add(new ArrayList<>(Collections.singleton(node)));
> }
> affinityServiceMock.when(() -> AffinityUtils.calculateAssignments(any(),
> anyInt(), anyInt()))
> .thenReturn(assignment);
> }{code}
> As the result {{AffinityUtils#calculateAssignments}} calls outside of
> try-with-resources returns List of empty sets, but desired behavior is list
> of sets with the given {{{}node{}}}.
> *Definition of done*
> {{AffinityUtils#calculateAssignments}} call inside
> {{TableManager#getOrCreateAssignments}} must returns list of non-empty sets
> with single node.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22355) TableManager's static mocks from #mockManagersAndCreateTableWithDelay don't work
Mikhail Efremov created IGNITE-22355:
Summary: TableManager's static mocks from
#mockManagersAndCreateTableWithDelay don't work
Key: IGNITE-22355
URL: https://issues.apache.org/jira/browse/IGNITE-22355
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
*Description*
In tests table creation method there is code like below:
{code:java}
try (MockedStatic affinityServiceMock =
mockStatic(AffinityUtils.class)) {
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityServiceMock.when(() -> AffinityUtils.calculateAssignments(any(),
anyInt(), anyInt()))
.thenReturn(assignment);
}{code}
As the result {{AffinityUtils#calculateAssignments}} calls outside of
try-with-resources returns List of empty sets, but desired behavior is list of
sets with the given {{{}node{}}}.
*Definition of done*
{{AffinityUtils#calculateAssignments}} call inside
{{TableManager#getOrCreateAssignments}} must returns list of non-empty sets
with single node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21805) Refactor TableManager and move all RAFT related pieces to Replica
[
https://issues.apache.org/jira/browse/IGNITE-21805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849819#comment-17849819
]
Mikhail Efremov edited comment on IGNITE-21805 at 5/27/24 8:12 PM:
---
*Done work*
# {{RaftManager}} is moved into {{ReplicaManager}} completely.
# Almost all calls from {{RaftManager}} are made as internal
{{ReplicaManager}}'s calls.
# {{ReplicaManager#replica()}} method is created and it returns a future
replica by given replication group ID; the method allows to get access to
raft-clients outside replication layer, but through it.
# The follow RAFT-related entities are moved into {{ReplicaManager}}:
{{RaftGroupOptions}}, {{RaftGroupEventsListener}}
({{RebalanceRaftGroupEventsListener}}), {{PartitionMover}},
{{TopologyAwareRaftGroupServiceFactory}}, {{LogStorageFactoryCreator}}.
# The creation place of raft-client in {{TableManager}} through
{{ReplicaManager#startRaftClient}} is localized now and will be removed in
IGNITE-22315
*Next related tickets*
# IGNITE-22315 is about making code to a state where if a node is related in
assignments, then and only then there will be created only one raft-node, only
one raft-client and only one replica. {{ReplicaManager#startRaftClient}} will
be removed as it's single call.
# IGNITE-22218 is about {{TableRaftService}} removing from the code and it's
calls for raft-clients will be replaced with a chains like
{{replicaMgr.replica(replicaGrpId).thenApply(Replica::raftClient).thenCompose(raftClient
-> ...)}}.
# IGNITE-22292 is about {{ReplicaManager#getLogSyncer}} removal.
was (Author: JIRAUSER303791):
*Done work*
# {{RaftManager}} is moved into {{ReplicaManager}} completely.
# Almost all calls from {{RaftManager}} are made as internal
{{{}ReplicaManager{}}}'s calls.
# {{ReplicaManager#replica()}} method is created and it returns a future
replica by given replication group ID; the method allows to get access to
raft-clients outside replication layer, but through it.
# The follow RAFT-related entities are moved into {{{}ReplicaManager{}}}:
{{{}RaftGroupOptions{}}}, {{RaftGroupEventsListener}}
({{{}RebalanceRaftGroupEventsListener{}}}), {{{}PartitionMover{}}},
{{{}TopologyAwareRaftGroupServiceFactory{}}}, {{{}LogStorageFactoryCreator{}}}.
# The creation place of raft-client in {{TableManager}} through
{{ReplicaManager#startRaftClient}} is localized now and will be removed in
IGNITE-22315
*Next related tickets*
# IGNITE-22315 is about making code to a state where if a node is related in
assignments, then and only then there will be created only one raft-node, only
one raft-client and only one replica. {{ReplicaManager#startRaftClient}} will
be removed as it's single call.
# IGNITE-22218 is about {{TableRaftService}} removing from the code and it's
calls for raft-clients will be replaced with a chains like
{{{}replicaMgr.replica(replicaGrpId).thenApply(Replica::raftClient).thenCompose(raftClient
-> ...){}}}.
# IGNITE-22292 is about {{ReplicaManager#getLogSyncer}} removal.
> Refactor TableManager and move all RAFT related pieces to Replica
> -
>
> Key: IGNITE-21805
> URL: https://issues.apache.org/jira/browse/IGNITE-21805
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Motivation*
> At the moment we have some places inside the TableManager, which:
> * Use RaftManager to start/stop RAFT nodes
> (handleChangePendingAssignmentEvent/handleChangeStableAssignmentEvent)
> * Use RaftGroupService through
> table.internalTable().tableRaftService().partitionRaftGroupService calls
> This fact prevents us on the track of zone-based collocation. The further
> collocation steps will be easier, if we will move the whole RAFT connected
> operation to the Replica class. Moreover, it should be there semantically
> *Definition of done*
> * All code inside the handleChangePendingAssignmentEvent connected with the
> start of raft groups (PartitionListener/RebalanceRaftGroupEventsListener) and
> raft clients must be moved to the start of the Replica itself
> * The same about handleChangeStableAssignmentEvent - the stop of Replica
> must stop appropriate raft node
> * All calls for
> table.internalTable().tableRaftService().partitionRaftGroupService must be
> replaced by the replicaMgr.replica(replicaGrpdId).raftClient()
> *Implementation notes*
> * The new temporary methods must be implemented and remove after IGNITE-22036
> ** ReplicaManager.replica(ReplicationGroupId replicaGrpId) - which returns
> the appropriate Replica by group id
> ** Replica.raftClient() - which return replica's
[jira] [Comment Edited] (IGNITE-21805) Refactor TableManager and move all RAFT related pieces to Replica
[
https://issues.apache.org/jira/browse/IGNITE-21805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849819#comment-17849819
]
Mikhail Efremov edited comment on IGNITE-21805 at 5/27/24 8:11 PM:
---
*Done work*
# {{RaftManager}} is moved into {{ReplicaManager}} completely.
# Almost all calls from {{RaftManager}} are made as internal
{{{}ReplicaManager{}}}'s calls.
# {{ReplicaManager#replica()}} method is created and it returns a future
replica by given replication group ID; the method allows to get access to
raft-clients outside replication layer, but through it.
# The follow RAFT-related entities are moved into {{{}ReplicaManager{}}}:
{{{}RaftGroupOptions{}}}, {{RaftGroupEventsListener}}
({{{}RebalanceRaftGroupEventsListener{}}}), {{{}PartitionMover{}}},
{{{}TopologyAwareRaftGroupServiceFactory{}}}, {{{}LogStorageFactoryCreator{}}}.
# The creation place of raft-client in {{TableManager}} through
{{ReplicaManager#startRaftClient}} is localized now and will be removed in
IGNITE-22315
*Next related tickets*
# IGNITE-22315 is about making code to a state where if a node is related in
assignments, then and only then there will be created only one raft-node, only
one raft-client and only one replica. {{ReplicaManager#startRaftClient}} will
be removed as it's single call.
# IGNITE-22218 is about {{TableRaftService}} removing from the code and it's
calls for raft-clients will be replaced with a chains like
{{{}replicaMgr.replica(replicaGrpId).thenApply(Replica::raftClient).thenCompose(raftClient
-> ...){}}}.
# IGNITE-22292 is about {{ReplicaManager#getLogSyncer}} removal.
was (Author: JIRAUSER303791):
*Done work*
# {{RaftManager}} is moved into {{ReplicaManager}} completely.
# Almost all calls from {{RaftManager}} are made as internal
{{{}ReplicaManager{}}}'s calls.
# {{ReplicaManager#replica()}} method is created and it returns a future
replica by given replication group ID; the method allows to get access to
raft-clients outside replication layer, but through it.
# The follow RAFT-related entities are moved into {{{}ReplicaManager{}}}:
{{{}RaftGroupOptions{}}}, {{RaftGroupEventsListener}}
({{{}RebalanceRaftGroupEventsListener{}}}), {{{}PartitionMover{}}},
{{{}TopologyAwareRaftGroupServiceFactory{}}}, {{{}LogStorageFactoryCreator{}}}.
# The creation place of raft-client in {{TableManager}} through
{{ReplicaManager#startRaftClient}} is localized now and will be removed in
IGNITE-22315
*Related next tickets*
# IGNITE-22315 is about making code to a state where if a node is related in
assignments, then and only then there will be created only one raft-node, only
one raft-client and only one replica. {{ReplicaManager#startRaftClient}} will
be removed as it's single call.
# IGNITE-22218 is about {{TableRaftService}} removing from the code and it's
calls for raft-clients will be replaced with a chains like
{{{}replicaMgr.replica(replicaGrpId).thenApply(Replica::raftClient).thenCompose(raftClient
-> ...){}}}.
# IGNITE-22292 is about {{ReplicaManager#getLogSyncer}} removal.
> Refactor TableManager and move all RAFT related pieces to Replica
> -
>
> Key: IGNITE-21805
> URL: https://issues.apache.org/jira/browse/IGNITE-21805
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Motivation*
> At the moment we have some places inside the TableManager, which:
> * Use RaftManager to start/stop RAFT nodes
> (handleChangePendingAssignmentEvent/handleChangeStableAssignmentEvent)
> * Use RaftGroupService through
> table.internalTable().tableRaftService().partitionRaftGroupService calls
> This fact prevents us on the track of zone-based collocation. The further
> collocation steps will be easier, if we will move the whole RAFT connected
> operation to the Replica class. Moreover, it should be there semantically
> *Definition of done*
> * All code inside the handleChangePendingAssignmentEvent connected with the
> start of raft groups (PartitionListener/RebalanceRaftGroupEventsListener) and
> raft clients must be moved to the start of the Replica itself
> * The same about handleChangeStableAssignmentEvent - the stop of Replica
> must stop appropriate raft node
> * All calls for
> table.internalTable().tableRaftService().partitionRaftGroupService must be
> replaced by the replicaMgr.replica(replicaGrpdId).raftClient()
> *Implementation notes*
> * The new temporary methods must be implemented and remove after IGNITE-22036
> ** ReplicaManager.replica(ReplicationGroupId replicaGrpId) - which returns
> the appropriate Replica by group id
> ** Replica.raftClient() -
[jira] [Comment Edited] (IGNITE-21805) Refactor TableManager and move all RAFT related pieces to Replica
[
https://issues.apache.org/jira/browse/IGNITE-21805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849819#comment-17849819
]
Mikhail Efremov edited comment on IGNITE-21805 at 5/27/24 8:10 PM:
---
*Done work*
# {{RaftManager}} is moved into {{ReplicaManager}} completely.
# Almost all calls from {{RaftManager}} are made as internal
{{{}ReplicaManager{}}}'s calls.
# {{ReplicaManager#replica()}} method is created and it returns a future
replica by given replication group ID; the method allows to get access to
raft-clients outside replication layer, but through it.
# The follow RAFT-related entities are moved into {{{}ReplicaManager{}}}:
{{{}RaftGroupOptions{}}}, {{RaftGroupEventsListener}}
({{{}RebalanceRaftGroupEventsListener{}}}), {{{}PartitionMover{}}},
{{{}TopologyAwareRaftGroupServiceFactory{}}}, {{{}LogStorageFactoryCreator{}}}.
# The creation place of raft-client in {{TableManager}} through
{{ReplicaManager#startRaftClient}} is localized now and will be removed in
IGNITE-22315
*Related next tickets*
# IGNITE-22315 is about making code to a state where if a node is related in
assignments, then and only then there will be created only one raft-node, only
one raft-client and only one replica. {{ReplicaManager#startRaftClient}} will
be removed as it's single call.
# IGNITE-22218 is about {{TableRaftService}} removing from the code and it's
calls for raft-clients will be replaced with a chains like
{{{}replicaMgr.replica(replicaGrpId).thenApply(Replica::raftClient).thenCompose(raftClient
-> ...){}}}.
# IGNITE-22292 is about {{ReplicaManager#getLogSyncer}} removal.
was (Author: JIRAUSER303791):
*Done work*
# {{RaftManager}} is moved into {{ReplicaManager}} completely.
# Almost all calls from {{RaftManager}} are made as internal
{{{}ReplicaManager{}}}'s calls.
# {{ReplicaManager#replica()}} method is created and it returns a future
replica by given replication group ID; the method allows to get access to
raft-clients outside replication layer, but through it.
# The follow RAFT-related entities are moved into {{{}ReplicaManager{}}}:
{{{}RaftGroupOptions{}}}, {{RaftGroupEventsListener}}
({{{}RebalanceRaftGroupEventsListener{}}}), {{{}PartitionMover{}}},
{{{}TopologyAwareRaftGroupServiceFactory{}}}, {{{}LogStorageFactoryCreator{}}}.
# The creation place of raft-client in {{TableManager}} through
{{ReplicaManager#startRaftClient}} is localized now and will be removed in
IGNITE-22315
*Related next tickets*
# IGNITE-22315 is about making code to a state where if a node is related in
assignments, then and only then there will be created only one raft-node, only
one raft-client and only one replica. {{ReplicaManager#startRaftClient}} will
be removed as it's single call.
# IGNITE-22218 is about {{TableRaftService}} removing from the code and it's
calls for raft-clients will be replaced with a chains like
{{{}replicaMgr.replica(replicaGrpId).thenCompose(raftClient -> ...){}}}.
# IGNITE-22292 is about {{ReplicaManager#getLogSyncer}} removal.
> Refactor TableManager and move all RAFT related pieces to Replica
> -
>
> Key: IGNITE-21805
> URL: https://issues.apache.org/jira/browse/IGNITE-21805
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Motivation*
> At the moment we have some places inside the TableManager, which:
> * Use RaftManager to start/stop RAFT nodes
> (handleChangePendingAssignmentEvent/handleChangeStableAssignmentEvent)
> * Use RaftGroupService through
> table.internalTable().tableRaftService().partitionRaftGroupService calls
> This fact prevents us on the track of zone-based collocation. The further
> collocation steps will be easier, if we will move the whole RAFT connected
> operation to the Replica class. Moreover, it should be there semantically
> *Definition of done*
> * All code inside the handleChangePendingAssignmentEvent connected with the
> start of raft groups (PartitionListener/RebalanceRaftGroupEventsListener) and
> raft clients must be moved to the start of the Replica itself
> * The same about handleChangeStableAssignmentEvent - the stop of Replica
> must stop appropriate raft node
> * All calls for
> table.internalTable().tableRaftService().partitionRaftGroupService must be
> replaced by the replicaMgr.replica(replicaGrpdId).raftClient()
> *Implementation notes*
> * The new temporary methods must be implemented and remove after IGNITE-22036
> ** ReplicaManager.replica(ReplicationGroupId replicaGrpId) - which returns
> the appropriate Replica by group id
> ** Replica.raftClient() - which return replica's
[jira] [Comment Edited] (IGNITE-21805) Refactor TableManager and move all RAFT related pieces to Replica
[
https://issues.apache.org/jira/browse/IGNITE-21805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849819#comment-17849819
]
Mikhail Efremov edited comment on IGNITE-21805 at 5/27/24 8:07 PM:
---
*Done work*
# {{RaftManager}} is moved into {{ReplicaManager}} completely.
# Almost all calls from {{RaftManager}} are made as internal
{{{}ReplicaManager{}}}'s calls.
# {{ReplicaManager#replica()}} method is created and it returns a future
replica by given replication group ID; the method allows to get access to
raft-clients outside replication layer, but through it.
# The follow RAFT-related entities are moved into {{{}ReplicaManager{}}}:
{{{}RaftGroupOptions{}}}, {{RaftGroupEventsListener}}
({{{}RebalanceRaftGroupEventsListener{}}}), {{{}PartitionMover{}}},
{{{}TopologyAwareRaftGroupServiceFactory{}}}, {{{}LogStorageFactoryCreator{}}}.
# The creation place of raft-client in {{TableManager}} through
{{ReplicaManager#startRaftClient}} is localized now and will be removed in
IGNITE-22315
*Related next tickets*
# IGNITE-22315 is about making code to a state where if a node is related in
assignments, then and only then there will be created only one raft-node, only
one raft-client and only one replica. {{ReplicaManager#startRaftClient}} will
be removed as it's single call.
# IGNITE-22218 is about {{TableRaftService}} removing from the code and it's
calls for raft-clients will be replaced with a chains like
{{{}replicaMgr.replica(replicaGrpId).thenCompose(raftClient -> ...){}}}.
# IGNITE-22292 is about {{ReplicaManager#getLogSyncer}} removal.
was (Author: JIRAUSER303791):
*Done work*
# {{RaftManager}} is moved into {{ReplicaManager}} completely.
# Almost all calls from {{RaftManager}} are made as internal
{{{}ReplicaManager{}}}'s calls.
# {{ReplicaManager#replica()}} method is created and it returns a future
replica by given replication group ID; the method allows to get access to
raft-clients outside replication layer, but through it.
# The follow RAFT-related entities are moved into {{{}ReplicaManager{}}}:
{{{}RaftGroupOptions{}}}, {{RaftGroupEventsListener}}
({{{}RebalanceRaftGroupEventsListener{}}}), {{{}PartitionMover{}}},
{{{}TopologyAwareRaftGroupServiceFactory{}}}, {{{}LogStorageFactoryCreator{}}}.
# The creation place of raft-client in {{TableManager}} through
{{ReplicaManager#startRaftClient}} is localized now and will be removed in
IGNITE-22315
*Related next tickets*
# IGNITE-22315 is about making code to a state where if a node is related in
assignments, then and only then there will be created only one raft-node, only
one raft-client and only one replica. {{ReplicaManager#startRaftClient}} will
be removed as it's single call.
# IGNITE-22218 is about {{TableRaftService}} removing from the code and it's
calls for raft-clients will be replaced with a chains like
{{{}replicaMgr.replica(replicaGrpId).thenCompose(raftClient -> ...){}}}.
> Refactor TableManager and move all RAFT related pieces to Replica
> -
>
> Key: IGNITE-21805
> URL: https://issues.apache.org/jira/browse/IGNITE-21805
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Motivation*
> At the moment we have some places inside the TableManager, which:
> * Use RaftManager to start/stop RAFT nodes
> (handleChangePendingAssignmentEvent/handleChangeStableAssignmentEvent)
> * Use RaftGroupService through
> table.internalTable().tableRaftService().partitionRaftGroupService calls
> This fact prevents us on the track of zone-based collocation. The further
> collocation steps will be easier, if we will move the whole RAFT connected
> operation to the Replica class. Moreover, it should be there semantically
> *Definition of done*
> * All code inside the handleChangePendingAssignmentEvent connected with the
> start of raft groups (PartitionListener/RebalanceRaftGroupEventsListener) and
> raft clients must be moved to the start of the Replica itself
> * The same about handleChangeStableAssignmentEvent - the stop of Replica
> must stop appropriate raft node
> * All calls for
> table.internalTable().tableRaftService().partitionRaftGroupService must be
> replaced by the replicaMgr.replica(replicaGrpdId).raftClient()
> *Implementation notes*
> * The new temporary methods must be implemented and remove after IGNITE-22036
> ** ReplicaManager.replica(ReplicationGroupId replicaGrpId) - which returns
> the appropriate Replica by group id
> ** Replica.raftClient() - which return replica's RaftGroupService (raft
> client)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22330) ItDisasterRecoveryReconfigurationTest#testManualRebalanceIfMajorityIsLost is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22330:
-
Summary:
ItDisasterRecoveryReconfigurationTest#testManualRebalanceIfMajorityIsLost is
flaky (was:
ItDisasterRecoveryReconfigurationTest#testManualRebalanceIfMajorityIsLost is
flacky)
> ItDisasterRecoveryReconfigurationTest#testManualRebalanceIfMajorityIsLost is
> flaky
> --
>
> Key: IGNITE-22330
> URL: https://issues.apache.org/jira/browse/IGNITE-22330
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Attachments: image-2024-05-25-01-56-21-327.png
>
>
> This test fails at least on main {{4c6662}} with strange (series of failures)
> rate: !image-2024-05-25-01-56-21-327.png!
> The common issue is {{{}TimeoutException{}}}:
>
> {code:java}
> java.lang.AssertionError: java.util.concurrent.TimeoutException
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
> at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.disaster.ItDisasterRecoveryReconfigurationTest.awaitPrimaryReplica(ItDisasterRecoveryReconfigurationTest.java:306)
> at
> org.apache.ignite.internal.disaster.ItDisasterRecoveryReconfigurationTest.testManualRebalanceIfMajorityIsLost(ItDisasterRecoveryReconfigurationTest.java:209)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180)
> at
> java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104)
> at
> java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:699)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
> at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> Caused by: java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:74)
> ... 32 more
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
>
[jira] [Created] (IGNITE-22330) ItDisasterRecoveryReconfigurationTest#testManualRebalanceIfMajorityIsLost is flacky
Mikhail Efremov created IGNITE-22330:
Summary:
ItDisasterRecoveryReconfigurationTest#testManualRebalanceIfMajorityIsLost is
flacky
Key: IGNITE-22330
URL: https://issues.apache.org/jira/browse/IGNITE-22330
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Efremov
Attachments: image-2024-05-25-01-56-21-327.png
This test fails at least on main {{4c6662}} with strange (series of failures)
rate: !image-2024-05-25-01-56-21-327.png!
The common issue is {{{}TimeoutException{}}}:
{code:java}
java.lang.AssertionError: java.util.concurrent.TimeoutException
at
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
at
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.ignite.internal.disaster.ItDisasterRecoveryReconfigurationTest.awaitPrimaryReplica(ItDisasterRecoveryReconfigurationTest.java:306)
at
org.apache.ignite.internal.disaster.ItDisasterRecoveryReconfigurationTest.testManualRebalanceIfMajorityIsLost(ItDisasterRecoveryReconfigurationTest.java:209)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180)
at
java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104)
at
java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:699)
at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at
java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
at
java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
Caused by: java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
at
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:74)
... 32 more
java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
at
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:74)
at
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
[jira] [Updated] (IGNITE-22292) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22292:
-
Description:
*Description*
The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
{{{}Loza#getLogSyncer{}}}.
*Motivation*
# There is an intention to hide all raft-specific entities behind replication
layer and log syncer is an entity that sticking out. Besides it's only needs
for engines and may be passed though {{IgniteImpl}} as an ignite component.
# All current implementations except {{DefaultLogStorageFactory}} are not
implements properly sync method at all that looks like the reason for interface
segregation between {{LogSyncer}} and {{LogStorageFactory.}}
*Definition of done*
# There no more {{Loza#getLogSyncer}} method and its' calls.
# {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.
# {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
{{{}IgniteImpl{}}}.
was:
*Description*
The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
{{{}Loza#getLogSyncer{}}}.
*Motivation*
# There is an intention to hide all raft-specific entities behind replication
layer and log syncer is an entity that sticking out. Besides it's only needs
for engines and may be passed though {{IgniteImpl}} as an ignite component.
# All current implementations except {{DefaultLogStorageFactory}} are not
implements properly sync method at all that looks like the reason for interface
segregation between {{LogSyncer}} and {{LogStorageFactory.}}
*Definition of done*
# There no more {{Loza#getLogSyncer}} method and its' calls.
# {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
{}}}
# {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
{{{}IgniteIml{}}}.
> Moving LogSyncer from Loza and RaftServer and pass it to usages as
> IgniteComponent
> --
>
> Key: IGNITE-22292
> URL: https://issues.apache.org/jira/browse/IGNITE-22292
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
> {{{}Loza#getLogSyncer{}}}.
> *Motivation*
> # There is an intention to hide all raft-specific entities behind
> replication layer and log syncer is an entity that sticking out. Besides it's
> only needs for engines and may be passed though {{IgniteImpl}} as an ignite
> component.
> # All current implementations except {{DefaultLogStorageFactory}} are not
> implements properly sync method at all that looks like the reason for
> interface segregation between {{LogSyncer}} and {{LogStorageFactory.}}
> *Definition of done*
> # There no more {{Loza#getLogSyncer}} method and its' calls.
> # {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.
> # {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
> {{{}IgniteImpl{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
[
https://issues.apache.org/jira/browse/IGNITE-22315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22315:
-
Description:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
{{startGroupFut}} returns {{{}false{}}}:\{{ localMemberAssignment}} is {{null}}
or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService tableRaftService =
table.internalTable().tableRaftService();
try {
// Return existing service if it's already started.
return completedFuture(
(TopologyAwareRaftGroupService)
tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
);
} catch (IgniteInternalException e) {
// We use "IgniteInternalException" in accordance with the
javadoc of "partitionRaftGroupService" method.
try {
// TODO IGNITE-19614 This procedure takes 10 seconds if
there's no majority online.
return raftMgr
.startRaftGroupService(replicaGrpId,
newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
} catch (NodeStoppingException ex) {
return failedFuture(ex);
}
}
}), ioExecutor)
.thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, () -> {
((InternalTableImpl) internalTbl).tableRaftService()
.updateInternalTableRaftGroupService(partId,
updatedRaftGroupService);
boolean startedRaftNode = startGroupFut.join();
if (localMemberAssignment == null || !startedRaftNode ||
replicaMgr.isReplicaStarted(replicaGrpId)) {
return;
} {code}
the code shows that {{v}} argument ({{{}startGroupFut{}}}'s result) in the
lambda doesn't affect on raft-client's starting, and also the client is put
into {{TableRaftService}} then regardless of replica's starting.
On the other hand, there is a place that rely on raft-client creation on every
node with table's ID in {{TableManager#tables}} map: inside
{{TableManager#handleChangePendingAssignmentEvent}} there are two calls:
# the same name method
{{{}TableManager#handleChangePendingAssignmentEvent{}}}}}{}}}
# {{TableManager#changePeersOnRebalance}}
Both are asking for internal table's
{{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no any
checks about is the local node is suitable for raft-entities and replica
starting or they are already started.
Then, when we would try to fix instant raft-client starting it will lead to
instant {{IgniteInternalException}} with _"No such partition P in table T"_
from {{{}TableRaftService#{}}}{{{}partitionRaftGroupService{}}}. This is a
problem that should be solved.
{color:#383838}*Definition of done*{color}
# {color:#383838}Raft-client must be started only together with raft-node and
replica or shouldn't be started otherwise.{color}
# {color:#383838}{{TableRaftService}} shouldn't be requested for raft-client
if the local node isn't in a raft group.{color}
# {color:#383838}Some tests may rely on described behavior, then failed tests
should be investigated and, probably fixed.{color}
# {color:#383838}New tests that check single starting of raft-node,
raft-client and replica together are required{color}
{color:#0f54d6} {color}
{color:#383838} {color}
{color:#00855f} {color}
was:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
{{startGroupFut}} returns {{{}false{}}}:\{{ localMemberAssignment}} is {{null}}
or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService
[jira] [Updated] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
[
https://issues.apache.org/jira/browse/IGNITE-22315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22315:
-
Description:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
{{startGroupFut}} returns {{{}false{}}}:\{{ localMemberAssignment}} is {{null}}
or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService tableRaftService =
table.internalTable().tableRaftService();
try {
// Return existing service if it's already started.
return completedFuture(
(TopologyAwareRaftGroupService)
tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
);
} catch (IgniteInternalException e) {
// We use "IgniteInternalException" in accordance with the
javadoc of "partitionRaftGroupService" method.
try {
// TODO IGNITE-19614 This procedure takes 10 seconds if
there's no majority online.
return raftMgr
.startRaftGroupService(replicaGrpId,
newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
} catch (NodeStoppingException ex) {
return failedFuture(ex);
}
}
}), ioExecutor)
.thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, () -> {
((InternalTableImpl) internalTbl).tableRaftService()
.updateInternalTableRaftGroupService(partId,
updatedRaftGroupService);
boolean startedRaftNode = startGroupFut.join();
if (localMemberAssignment == null || !startedRaftNode ||
replicaMgr.isReplicaStarted(replicaGrpId)) {
return;
} {code}
the code shows that {{v}} argument ({{{}startGroupFut{}}}'s result) in the
lambda doesn't affect on raft-client's starting, and also the client is put
into {{TableRaftService}} then regardless of replica's starting.
On the other hand, there is a place that rely on raft-client creation on every
node with table's ID in {{TableManager#tables}} map: inside
{{TableManager#handleChangePendingAssignmentEvent}} there are two calls:
# the same name method
{{{}TableManager#handleChangePendingAssignmentEvent{}}}}}{}}}
# {{TableManager#changePeersOnRebalance}}
Both are asking for internal table's
{{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no any
checks about is the local node is suitable for raft-entities and replica
starting or they are already started.
Then, when we would try to fix instant raft-client starting it will lead to
instant {{IgniteInternalException}} with _"No such partition P in table T"_
from {{{}TableRaftService#{}}}{{{}partitionRaftGroupService{}}}. This is a
problem that should be solved.
{color:#383838}*Definition of done*{color}
{color:#383838}1. Raft-client must be started only together with raft-node and
replica or shouldn't be started otherwise.{color}
{color:#383838}2. {{TableRaftService}} shouldn't be requested for raft-client
if the local node isn't in a raft group.{color}
{color:#383838}3. Some tests may rely on described behavior, then failed tests
should be investigated and, probably fixed.{color}
{color:#383838}4. New tests that check single starting of raft-node,
raft-client and replica together are required{color}
{color:#0f54d6} {color}
{color:#383838} {color}
{color:#00855f} {color}
was:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
{{startGroupFut}} returns {{{}false{}}}:{{ localMemberAssignment}} is {{null}}
or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService
[jira] [Updated] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
[
https://issues.apache.org/jira/browse/IGNITE-22315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22315:
-
Description:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
{{startGroupFut}} returns {{{}false{}}}:{{ localMemberAssignment}} is {{null}}
or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService tableRaftService =
table.internalTable().tableRaftService();
try {
// Return existing service if it's already started.
return completedFuture(
(TopologyAwareRaftGroupService)
tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
);
} catch (IgniteInternalException e) {
// We use "IgniteInternalException" in accordance with the
javadoc of "partitionRaftGroupService" method.
try {
// TODO IGNITE-19614 This procedure takes 10 seconds if
there's no majority online.
return raftMgr
.startRaftGroupService(replicaGrpId,
newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
} catch (NodeStoppingException ex) {
return failedFuture(ex);
}
}
}), ioExecutor)
.thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, () -> {
((InternalTableImpl) internalTbl).tableRaftService()
.updateInternalTableRaftGroupService(partId,
updatedRaftGroupService);
boolean startedRaftNode = startGroupFut.join();
if (localMemberAssignment == null || !startedRaftNode ||
replicaMgr.isReplicaStarted(replicaGrpId)) {
return;
} {code}
{color:#00855f}the code shows that {{v}} argument ({{{}startGroupFut{}}}'s
result) in the lambda doesn't affect on raft-client's starting, and also the
client is put into {{TableRaftService}} then regardless of replica's
starting.{color}
On the other hand, there is a place that rely on raft-client creation on every
node with table's ID in {{TableManager#tables}} map: inside
{{TableManager#handleChangePendingAssignmentEvent}} there are two calls:
# the same name method
{{TableManager#handleChangePendingAssignmentEvent}}{{{}{}}}
# {{TableManager#changePeersOnRebalance}}
Both are asking for internal table's
{{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no any
checks about is the local node is suitable for raft-entities and replica
starting or they are already started.
Then, when we would try to fix instant raft-client starting it will lead to
instant {{IgniteInternalException}} with _"No such partition P in table T"_
from {{{}TableRaftService#{}}}{{{}partitionRaftGroupService{}}}. This is a
problem that should be solved.
{color:#383838}*Definition of done*{color}
{color:#383838}1. Raft-client must be started only together with raft-node and
replica or shouldn't be started otherwise.{color}
{color:#383838}2. {{TableRaftService}} shouldn't be requested for raft-client
if the local node isn't in a raft group.{color}
{color:#383838}3. Some tests may rely on described behavior, then failed tests
should be investigated and, probably fixed.{color}
{color:#383838}4. New tests that check single starting of raft-node,
raft-client and replica together are required{color}
{color:#0f54d6} {color}
{color:#383838} {color}
{color:#00855f} {color}
was:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
startGroupFut returns false: {{localMemberAssignment}} is {{null}} or
{{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
[jira] [Updated] (IGNITE-22292) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22292:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Moving LogSyncer from Loza and RaftServer and pass it to usages as
> IgniteComponent
> --
>
> Key: IGNITE-22292
> URL: https://issues.apache.org/jira/browse/IGNITE-22292
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
> {{{}Loza#getLogSyncer{}}}.
> *Motivation*
> # There is an intention to hide all raft-specific entities behind
> replication layer and log syncer is an entity that sticking out. Besides it's
> only needs for engines and may be passed though {{IgniteImpl}} as an ignite
> component.
> # All current implementations except {{DefaultLogStorageFactory}} are not
> implements properly sync method at all that looks like the reason for
> interface segregation between {{LogSyncer}} and {{LogStorageFactory.}}
> *Definition of done*
> # There no more {{Loza#getLogSyncer}} method and its' calls.
> # {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
> {}}}
> # {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
> {{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22218) Remove TableRaftService in favor of using RaftGroupService from Replica instances
[
https://issues.apache.org/jira/browse/IGNITE-22218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22218:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Remove TableRaftService in favor of using RaftGroupService from Replica
> instances
> -
>
> Key: IGNITE-22218
> URL: https://issues.apache.org/jira/browse/IGNITE-22218
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> All {{RaftGroupService}} instances should be gotten from
> {{Replica#raftClient}} instead of using
> {{TableRaftService#partitionRaftGroupService}}.
> *Motivation*
> Main goal is to follow IGNITE-21805 track and localize raft-clients'
> instances management inside {{ReplicaManager}} and
> {{Replica}}. That requires to remove {{TableRaftService}} as entity that
> collects raft-clients inside.
> *Definition of done*
> 1. {{TableRaftService}} is removed.
> 2. All usings of TableRaftService#partitionRaftGroupService}} should be
> replaced on
>{{ReplicaManager#getReplica#raftClient}} calls chain.
> 3. {{TableViewInternal#leaderAssignment}} should be removed from the
> interface.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21805) Refactor TableManager and move all RAFT related pieces to Replica
[ https://issues.apache.org/jira/browse/IGNITE-21805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-21805: - Ignite Flags: (was: Docs Required,Release Notes Required) > Refactor TableManager and move all RAFT related pieces to Replica > - > > Key: IGNITE-21805 > URL: https://issues.apache.org/jira/browse/IGNITE-21805 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3 > Time Spent: 2h 40m > Remaining Estimate: 0h > > *Motivation* > At the moment we have some places inside the TableManager, which: > * Use RaftManager to start/stop RAFT nodes > (handleChangePendingAssignmentEvent/handleChangeStableAssignmentEvent) > * Use RaftGroupService through > table.internalTable().tableRaftService().partitionRaftGroupService calls > This fact prevents us on the track of zone-based collocation. The further > collocation steps will be easier, if we will move the whole RAFT connected > operation to the Replica class. Moreover, it should be there semantically > *Definition of done* > * All code inside the handleChangePendingAssignmentEvent connected with the > start of raft groups (PartitionListener/RebalanceRaftGroupEventsListener) and > raft clients must be moved to the start of the Replica itself > * The same about handleChangeStableAssignmentEvent - the stop of Replica > must stop appropriate raft node > * All calls for > table.internalTable().tableRaftService().partitionRaftGroupService must be > replaced by the replicaMgr.replica(replicaGrpdId).raftClient() > *Implementation notes* > * The new temporary methods must be implemented and remove after IGNITE-22036 > ** ReplicaManager.replica(ReplicationGroupId replicaGrpId) - which returns > the appropriate Replica by group id > ** Replica.raftClient() - which return replica's RaftGroupService (raft > client) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
[
https://issues.apache.org/jira/browse/IGNITE-22315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22315:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Make raft-client starting only once and only with raft-client and replica
> together
> --
>
> Key: IGNITE-22315
> URL: https://issues.apache.org/jira/browse/IGNITE-22315
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The goal is to make sure that when partition starting on an ignite-node, if
> the node in assignments, then there should be only ones raft-node,
> raft-client and replica and no any started entities otherwise.
> *Motivation*
> Now on the one hand in {{TableManager}} there is a path when raft-node and
> replica didn't start, but raft-client is:
> In {{TableManager#startPartitionAndStartClient}} there is a place where
> startGroupFut returns false: {{localMemberAssignment}} is {{null}} or
> {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
> Then, raft-node and replica will not be started, but regardless of
> {{startGroupFut}} result raft client will be started:
> {code:java}
> startGroupFut
> .thenComposeAsync(v -> inBusyLock(busyLock, () -> {
> TableRaftService tableRaftService =
> table.internalTable().tableRaftService();
> try {
> // Return existing service if it's already started.
> return completedFuture(
> (TopologyAwareRaftGroupService)
> tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
> );
> } catch (IgniteInternalException e) {
> // We use "IgniteInternalException" in accordance with the
> javadoc of "partitionRaftGroupService" method.
> try {
> // TODO IGNITE-19614 This procedure takes 10 seconds if
> there's no majority online.
> return raftMgr
> .startRaftGroupService(replicaGrpId,
> newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
> } catch (NodeStoppingException ex) {
> return failedFuture(ex);
> }
> }
> }), ioExecutor)
> .thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, ()
> -> {
> ((InternalTableImpl) internalTbl).tableRaftService()
> .updateInternalTableRaftGroupService(partId,
> updatedRaftGroupService);
> boolean startedRaftNode = startGroupFut.join();
> if (localMemberAssignment == null || !startedRaftNode ||
> replicaMgr.isReplicaStarted(replicaGrpId)) {
> return;
> } {code}
> {color:#00855f}{color:#383838}the code shows that {{v}} argument
> ({{{}startGroupFut{}}}'s result) in the lambda doesn't affect on
> raft-client's starting, and also the client is put into {{TableRaftService}}
> then regardless of replica's starting.{color}{color}
> On the other hand, there is a place that rely on raft-client creation on
> every node with table's ID in {{TableManager#tables}} map: inside
> {{TableManager#handleChangePendingAssignmentEvent}} there are two calls: #
> the same name method {{TableManager#handleChangePendingAssignmentEvent}}
> # {{TableManager#changePeersOnRebalance}}
> Both are asking for internal table's
> {{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no
> any checks about is the local node is suitable for raft-entities and replica
> starting or they are already started.
>
> Then, when we would try to fix instant raft-client starting it will lead to
> instant {{IgniteInternalException}} with _"No such partition P in table T"_
> from {{TableRaftService#}}
> {{{}partitionRaftGroupService{}}}. This is a problem that should be
> solved.{color:#00855f}
> {color}{color:#383838}
> {color}
> {color:#383838}*Definition of done*{color}
> {color:#383838}1. Raft-client must be started only together with raft-node
> and replica or shouldn't be started otherwise.
> {color}
> {color:#383838}2. {{TableRaftService}} shouldn't be requested for raft-client
> if the local node isn't in a raft group.{color}
> {color:#383838}3. Some tests may rely on described behavior, then failed
> tests should be investigated and, probably fixed.{color}
> {color:#383838}4. New tests that check single starting of raft-node,
> raft-client and replica together are required{color}
> {color:#0f54d6} {color}
> {color:#383838} {color}
> {color:#00855f} {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22036) Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest
[ https://issues.apache.org/jira/browse/IGNITE-22036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-22036: - Epic Link: IGNITE-22313 (was: IGNITE-19170) > Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest > --- > > Key: IGNITE-22036 > URL: https://issues.apache.org/jira/browse/IGNITE-22036 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3 > > *Motivation* > To simplify the process of moving to the zone-based collocation we need to > remove all raft-connected code from TableManager. After IGNITE-21805 we will > still have: > * TableManager.changePeersOnRebalance > This method must be replaced by appropriate request to Replica. > *Definition of done* > * TableManager send the broadcast ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct call to raft changePeersAsync > *Implementation details* > We need to: > * Introduce ChangePeersReplicaRequest(PeersAndLearners peersAndLearners) - > the new replica request type > * Move the code from TableManager.changePeersOnRebalance to the Replica > itself, as a reaction to ChangePeersReplicaRequest > * TableManager must send the ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct > TableManager.changePeersOnRebalance call -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22218) Remove TableRaftService in favor of using RaftGroupService from Replica instances
[
https://issues.apache.org/jira/browse/IGNITE-22218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22218:
-
Epic Link: IGNITE-22313 (was: IGNITE-22115)
> Remove TableRaftService in favor of using RaftGroupService from Replica
> instances
> -
>
> Key: IGNITE-22218
> URL: https://issues.apache.org/jira/browse/IGNITE-22218
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> All {{RaftGroupService}} instances should be gotten from
> {{Replica#raftClient}} instead of using
> {{TableRaftService#partitionRaftGroupService}}.
> *Motivation*
> Main goal is to follow IGNITE-21805 track and localize raft-clients'
> instances management inside {{ReplicaManager}} and
> {{Replica}}. That requires to remove {{TableRaftService}} as entity that
> collects raft-clients inside.
> *Definition of done*
> 1. {{TableRaftService}} is removed.
> 2. All usings of TableRaftService#partitionRaftGroupService}} should be
> replaced on
>{{ReplicaManager#getReplica#raftClient}} calls chain.
> 3. {{TableViewInternal#leaderAssignment}} should be removed from the
> interface.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22222) Move ThreadLocalPartitionCommandsMarshaller to ReplicaManager module with cycle dependency fix
[
https://issues.apache.org/jira/browse/IGNITE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-2:
-
Epic Link: IGNITE-22313
> Move ThreadLocalPartitionCommandsMarshaller to ReplicaManager module with
> cycle dependency fix
> --
>
> Key: IGNITE-2
> URL: https://issues.apache.org/jira/browse/IGNITE-2
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> Now the marshaller starts in {{IgniteImpl}} and using only for
> {{ReplicaManager}} creation, there is a reason to move it in
> {{{}ReplicaManager{}}}'s constructor, but there is cyclic dependency arises.
> Also in some places in tests classes like
> {{org.apache.ignite.internal.replicator.ItPlacementDriverReplicaSideTest#beforeTest}}
> we can't pass or mock this specific marshaller's class.
> *Definition of done*
> {{ThreadLocalPartitionCommandsMarshaller}} instantiation is moved into
> {{ReplicaManager}} and there no any another places of it's instance creation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21805) Refactor TableManager and move all RAFT related pieces to Replica
[ https://issues.apache.org/jira/browse/IGNITE-21805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-21805: - Epic Link: IGNITE-22313 (was: IGNITE-19170) > Refactor TableManager and move all RAFT related pieces to Replica > - > > Key: IGNITE-21805 > URL: https://issues.apache.org/jira/browse/IGNITE-21805 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3 > Time Spent: 2h 40m > Remaining Estimate: 0h > > *Motivation* > At the moment we have some places inside the TableManager, which: > * Use RaftManager to start/stop RAFT nodes > (handleChangePendingAssignmentEvent/handleChangeStableAssignmentEvent) > * Use RaftGroupService through > table.internalTable().tableRaftService().partitionRaftGroupService calls > This fact prevents us on the track of zone-based collocation. The further > collocation steps will be easier, if we will move the whole RAFT connected > operation to the Replica class. Moreover, it should be there semantically > *Definition of done* > * All code inside the handleChangePendingAssignmentEvent connected with the > start of raft groups (PartitionListener/RebalanceRaftGroupEventsListener) and > raft clients must be moved to the start of the Replica itself > * The same about handleChangeStableAssignmentEvent - the stop of Replica > must stop appropriate raft node > * All calls for > table.internalTable().tableRaftService().partitionRaftGroupService must be > replaced by the replicaMgr.replica(replicaGrpdId).raftClient() > *Implementation notes* > * The new temporary methods must be implemented and remove after IGNITE-22036 > ** ReplicaManager.replica(ReplicationGroupId replicaGrpId) - which returns > the appropriate Replica by group id > ** Replica.raftClient() - which return replica's RaftGroupService (raft > client) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
Mikhail Efremov created IGNITE-22315:
Summary: Make raft-client starting only once and only with
raft-client and replica together
Key: IGNITE-22315
URL: https://issues.apache.org/jira/browse/IGNITE-22315
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
startGroupFut returns false: {{localMemberAssignment}} is {{null}} or
{{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService tableRaftService =
table.internalTable().tableRaftService();
try {
// Return existing service if it's already started.
return completedFuture(
(TopologyAwareRaftGroupService)
tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
);
} catch (IgniteInternalException e) {
// We use "IgniteInternalException" in accordance with the
javadoc of "partitionRaftGroupService" method.
try {
// TODO IGNITE-19614 This procedure takes 10 seconds if
there's no majority online.
return raftMgr
.startRaftGroupService(replicaGrpId,
newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
} catch (NodeStoppingException ex) {
return failedFuture(ex);
}
}
}), ioExecutor)
.thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, () -> {
((InternalTableImpl) internalTbl).tableRaftService()
.updateInternalTableRaftGroupService(partId,
updatedRaftGroupService);
boolean startedRaftNode = startGroupFut.join();
if (localMemberAssignment == null || !startedRaftNode ||
replicaMgr.isReplicaStarted(replicaGrpId)) {
return;
} {code}
{color:#00855f}{color:#383838}the code shows that {{v}} argument
({{{}startGroupFut{}}}'s result) in the lambda doesn't affect on raft-client's
starting, and also the client is put into {{TableRaftService}} then regardless
of replica's starting.{color}{color}
On the other hand, there is a place that rely on raft-client creation on every
node with table's ID in {{TableManager#tables}} map: inside
{{TableManager#handleChangePendingAssignmentEvent}} there are two calls: # the
same name method {{TableManager#handleChangePendingAssignmentEvent}}
# {{TableManager#changePeersOnRebalance}}
Both are asking for internal table's
{{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no any
checks about is the local node is suitable for raft-entities and replica
starting or they are already started.
Then, when we would try to fix instant raft-client starting it will lead to
instant {{IgniteInternalException}} with _"No such partition P in table T"_
from {{TableRaftService#}}
{{{}partitionRaftGroupService{}}}. This is a problem that should be
solved.{color:#00855f}
{color}{color:#383838}
{color}
{color:#383838}*Definition of done*{color}
{color:#383838}1. Raft-client must be started only together with raft-node and
replica or shouldn't be started otherwise.
{color}
{color:#383838}2. {{TableRaftService}} shouldn't be requested for raft-client
if the local node isn't in a raft group.{color}
{color:#383838}3. Some tests may rely on described behavior, then failed tests
should be investigated and, probably fixed.{color}
{color:#383838}4. New tests that check single starting of raft-node,
raft-client and replica together are required{color}
{color:#0f54d6} {color}
{color:#383838} {color}
{color:#00855f} {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22292) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22292:
-
Epic Link: IGNITE-22313 (was: IGNITE-22115)
> Moving LogSyncer from Loza and RaftServer and pass it to usages as
> IgniteComponent
> --
>
> Key: IGNITE-22292
> URL: https://issues.apache.org/jira/browse/IGNITE-22292
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
> {{{}Loza#getLogSyncer{}}}.
> *Motivation*
> # There is an intention to hide all raft-specific entities behind
> replication layer and log syncer is an entity that sticking out. Besides it's
> only needs for engines and may be passed though {{IgniteImpl}} as an ignite
> component.
> # All current implementations except {{DefaultLogStorageFactory}} are not
> implements properly sync method at all that looks like the reason for
> interface segregation between {{LogSyncer}} and {{LogStorageFactory.}}
> *Definition of done*
> # There no more {{Loza#getLogSyncer}} method and its' calls.
> # {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
> {}}}
> # {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
> {{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22313) Moving RAFT-specific code to replication layer
Mikhail Efremov created IGNITE-22313: Summary: Moving RAFT-specific code to replication layer Key: IGNITE-22313 URL: https://issues.apache.org/jira/browse/IGNITE-22313 Project: Ignite Issue Type: Epic Reporter: Mikhail Efremov Assignee: Mikhail Efremov An epic for tickets to move RAFT-related entities and it's calls under replication layer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22292) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22292:
-
Labels: ignite-3 (was: )
> Moving LogSyncer from Loza and RaftServer and pass it to usages as
> IgniteComponent
> --
>
> Key: IGNITE-22292
> URL: https://issues.apache.org/jira/browse/IGNITE-22292
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
> {{{}Loza#getLogSyncer{}}}.
> *Motivation*
> # There is an intention to hide all raft-specific entities behind
> replication layer and log syncer is an entity that sticking out. Besides it's
> only needs for engines and may be passed though {{IgniteImpl}} as an ignite
> component.
> # All current implementations except {{DefaultLogStorageFactory}} are not
> implements properly sync method at all that looks like the reason for
> interface segregation between {{LogSyncer}} and {{LogStorageFactory.}}
> *Definition of done*
> # There no more {{Loza#getLogSyncer}} method and its' calls.
> # {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
> {}}}
> # {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
> {{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-22290) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov resolved IGNITE-22290.
--
Resolution: Invalid
> Moving LogSyncer from Loza and RaftServer and pass it to usages as
> IgniteComponent
> --
>
> Key: IGNITE-22290
> URL: https://issues.apache.org/jira/browse/IGNITE-22290
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
>
> *Description*
> The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
> {{{}Loza#getLogSyncer{}}}.
> *Motivation*
> # There is an intention to hide all raft-specific entities behind
> replication layer and log syncer is an entity that sticking out. Besides it's
> only needs for engines and may be passed though {{IgniteImpl}} as an ignite
> component.
> # All current implementations except {{DefaultLogStorageFactory}} are not
> implements properly sync method at all that looks like the reason for
> interface segregation between {{LogSyncer}} and {{LogStorageFactory.}}
> *Definition of done*
> # There no more {{Loza#getLogSyncer}} method and its' calls.
> # {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
> {}}}
> # {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
> {{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-22291) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov resolved IGNITE-22291.
--
Resolution: Invalid
> Moving LogSyncer from Loza and RaftServer and pass it to usages as
> IgniteComponent
> --
>
> Key: IGNITE-22291
> URL: https://issues.apache.org/jira/browse/IGNITE-22291
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
>
> *Description*
> The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
> {{{}Loza#getLogSyncer{}}}.
> *Motivation*
> # There is an intention to hide all raft-specific entities behind
> replication layer and log syncer is an entity that sticking out. Besides it's
> only needs for engines and may be passed though {{IgniteImpl}} as an ignite
> component.
> # All current implementations except {{DefaultLogStorageFactory}} are not
> implements properly sync method at all that looks like the reason for
> interface segregation between {{LogSyncer}} and {{LogStorageFactory.}}
> *Definition of done*
> # There no more {{Loza#getLogSyncer}} method and its' calls.
> # {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
> {}}}
> # {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
> {{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22291) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
Mikhail Efremov created IGNITE-22291:
Summary: Moving LogSyncer from Loza and RaftServer and pass it to
usages as IgniteComponent
Key: IGNITE-22291
URL: https://issues.apache.org/jira/browse/IGNITE-22291
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
*Description*
The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
{{{}Loza#getLogSyncer{}}}.
*Motivation*
# There is an intention to hide all raft-specific entities behind replication
layer and log syncer is an entity that sticking out. Besides it's only needs
for engines and may be passed though {{IgniteImpl}} as an ignite component.
# All current implementations except {{DefaultLogStorageFactory}} are not
implements properly sync method at all that looks like the reason for interface
segregation between {{LogSyncer}} and {{LogStorageFactory.}}
*Definition of done*
# There no more {{Loza#getLogSyncer}} method and its' calls.
# {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
{}}}
# {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
{{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22292) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
Mikhail Efremov created IGNITE-22292:
Summary: Moving LogSyncer from Loza and RaftServer and pass it to
usages as IgniteComponent
Key: IGNITE-22292
URL: https://issues.apache.org/jira/browse/IGNITE-22292
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
*Description*
The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
{{{}Loza#getLogSyncer{}}}.
*Motivation*
# There is an intention to hide all raft-specific entities behind replication
layer and log syncer is an entity that sticking out. Besides it's only needs
for engines and may be passed though {{IgniteImpl}} as an ignite component.
# All current implementations except {{DefaultLogStorageFactory}} are not
implements properly sync method at all that looks like the reason for interface
segregation between {{LogSyncer}} and {{LogStorageFactory.}}
*Definition of done*
# There no more {{Loza#getLogSyncer}} method and its' calls.
# {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
{}}}
# {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
{{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22290) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
Mikhail Efremov created IGNITE-22290:
Summary: Moving LogSyncer from Loza and RaftServer and pass it to
usages as IgniteComponent
Key: IGNITE-22290
URL: https://issues.apache.org/jira/browse/IGNITE-22290
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
*Description*
The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
{{{}Loza#getLogSyncer{}}}.
*Motivation*
# There is an intention to hide all raft-specific entities behind replication
layer and log syncer is an entity that sticking out. Besides it's only needs
for engines and may be passed though {{IgniteImpl}} as an ignite component.
# All current implementations except {{DefaultLogStorageFactory}} are not
implements properly sync method at all that looks like the reason for interface
segregation between {{LogSyncer}} and {{LogStorageFactory.}}
*Definition of done*
# There no more {{Loza#getLogSyncer}} method and its' calls.
# {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
{}}}
# {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
{{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22222) Move ThreadLocalPartitionCommandsMarshaller to ReplicaManager module with cycle dependency fix
Mikhail Efremov created IGNITE-2:
Summary: Move ThreadLocalPartitionCommandsMarshaller to
ReplicaManager module with cycle dependency fix
Key: IGNITE-2
URL: https://issues.apache.org/jira/browse/IGNITE-2
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
*Description*
Now the marshaller starts in {{IgniteImpl}} and using only for
{{ReplicaManager}} creation, there is a reason to move it in
{{{}ReplicaManager{}}}'s constructor, but there is cyclic dependency arises.
Also in some places in tests classes like
{{org.apache.ignite.internal.replicator.ItPlacementDriverReplicaSideTest#beforeTest}}
we can't pass or mock this specific marshaller's class.
*Definition of done*
{{ThreadLocalPartitionCommandsMarshaller}} instantiation is moved into
{{ReplicaManager}} and there no any another places of it's instance creation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20137) testOneNodeRestartWithGap's assert throws TransactionException is failed
[
https://issues.apache.org/jira/browse/IGNITE-20137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845457#comment-17845457
]
Mikhail Efremov commented on IGNITE-20137:
--
Message in the second case:
{code:java}
Unexpected exception type thrown, expected:
but was:
Expected :class org.apache.ignite.tx.TransactionException
Actual :class org.apache.ignite.lang.IgniteException
org.opentest4j.AssertionFailedError: Unexpected exception type thrown,
expected: but was:
at
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:67)
at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:35)
at org.junit.jupiter.api.Assertions.assertThrows(Assertions.java:3115)
at
org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest.testOneNodeRestartWithGap(ItIgniteNodeRestartTest.java:1190)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180)
at
java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104)
at
java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:699)
at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at
java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
at
java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:73d0cfb1-6abf-4091-a038-b660d8581e84 The primary replica await timed
out [replicationGroupId=8_part_0, referenceTimestamp=HybridTimestamp
[physical=2024-05-11 00:43:48:686 +0600, logical=0,
composite=112418267377565696], currentLease=Lease [leaseholder=iinrt_tonrwg_0,
leaseholderId=99dc8a9e-8dd2-47eb-908e-59e984a0ff54, accepted=false,
startTime=HybridTimestamp [physical=2024-05-11 00:43:53:183 +0600, logical=0,
composite=112418267672281088], expirationTime=HybridTimestamp
[physical=2024-05-11 00:45:53:183 +0600, logical=0,
composite=112418275536601088], prolongable=false, proposedCandidate=null,
replicationGroupId=8_part_0]]
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:118)
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:138)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
[jira] [Commented] (IGNITE-20137) testOneNodeRestartWithGap's assert throws TransactionException is failed
[
https://issues.apache.org/jira/browse/IGNITE-20137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845456#comment-17845456
]
Mikhail Efremov commented on IGNITE-20137:
--
Message in the first case:
{code:java}
org.opentest4j.AssertionFailedError: Expected
org.apache.ignite.tx.TransactionException to be thrown, but nothing was thrown.
at
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:152)
at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:73)
at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:35)
at org.junit.jupiter.api.Assertions.assertThrows(Assertions.java:3115)
at
org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest.testOneNodeRestartWithGap(ItIgniteNodeRestartTest.java:1190)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180)
at
java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104)
at
java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:699)
at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at
java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
at
java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541){code}
> testOneNodeRestartWithGap's assert throws TransactionException is failed
>
>
> Key: IGNITE-20137
> URL: https://issues.apache.org/jira/browse/IGNITE-20137
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> *Description*
> With unchanged code there 2 ways to fail, both in the same assert that waits
> {{TransactionException}} to be thrown:
> # assert returns false because there is no any thrown exception;
> # assert returns false because the caught exception is timeout with
> {{{}PrimaryReplicaAwaitTimeoutException{}}}.
> We could remove the assert and fix the follow line:
> {code:java}
> TableManager tableManager = unwrapTableManager(ignite1.tables());{code}
> {color:#383838}Without unwrapping there will be {{{}ClassCastException{}}}.
> With this 2 changes the test will pass with 100% rate.{color}
>
> *What to fix*
> Probably, the assert should be left, but the issue needs an investigation:
> why there 2 reasons of fail and what exactly do we expect there?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20137) testOneNodeRestartWithGap's assert throws TransactionException is failed
[
https://issues.apache.org/jira/browse/IGNITE-20137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-20137:
-
Description:
*Description*
With unchanged code there 2 ways to fail, both in the same assert that waits
{{TransactionException}} to be thrown:
# assert returns false because there is no any thrown exception;
# assert returns false because the caught exception is timeout with
{{{}PrimaryReplicaAwaitTimeoutException{}}}.
We could remove the assert and fix the follow line:
{code:java}
TableManager tableManager = unwrapTableManager(ignite1.tables());{code}
{color:#383838}Without unwrapping there will be {{{}ClassCastException{}}}.
With this 2 changes the test will pass with 100% rate.{color}
*What to fix*
Probably, the assert should be left, but the issue needs an investigation: why
there 2 reasons of fail and what exactly do we expect there?
was:Looks like sometime the stopped node is not removed from the topology
> testOneNodeRestartWithGap's assert throws TransactionException is failed
>
>
> Key: IGNITE-20137
> URL: https://issues.apache.org/jira/browse/IGNITE-20137
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> *Description*
> With unchanged code there 2 ways to fail, both in the same assert that waits
> {{TransactionException}} to be thrown:
> # assert returns false because there is no any thrown exception;
> # assert returns false because the caught exception is timeout with
> {{{}PrimaryReplicaAwaitTimeoutException{}}}.
> We could remove the assert and fix the follow line:
> {code:java}
> TableManager tableManager = unwrapTableManager(ignite1.tables());{code}
> {color:#383838}Without unwrapping there will be {{{}ClassCastException{}}}.
> With this 2 changes the test will pass with 100% rate.{color}
>
> *What to fix*
> Probably, the assert should be left, but the issue needs an investigation:
> why there 2 reasons of fail and what exactly do we expect there?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20137) testOneNodeRestartWithGap's assert throws TransactionException is failed
[ https://issues.apache.org/jira/browse/IGNITE-20137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-20137: - Summary: testOneNodeRestartWithGap's assert throws TransactionException is failed (was: testOneNodeRestartWithGap is flaky) > testOneNodeRestartWithGap's assert throws TransactionException is failed > > > Key: IGNITE-20137 > URL: https://issues.apache.org/jira/browse/IGNITE-20137 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > Looks like sometime the stopped node is not removed from the topology -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21387) Recovery is not possible, if node have no needed storage profile
[
https://issues.apache.org/jira/browse/IGNITE-21387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837121#comment-17837121
]
Mikhail Efremov edited comment on IGNITE-21387 at 4/15/24 1:10 PM:
---
At the current state, the following changes are done:
* In {{ItDistributionZonesFiltersTest}} the single
testFilteredDataNodesPropagatedToStable test was divided on 3 separate tests:
** {{testDataNodesByFilterPropagatedToStable}} that tests only by attribute
filtering by specified region and storage filter;
** {{testDataNodesByProfilePropagatedToStable}} that tests only by matching
profile name;
** {{testDataNodesByFilterAndProfilePropagatedToStable}} tests both cases
together: attribute filters and profile both.
* In {{TableManager}} was done refactoring:
** extracting assignments creation into the separate method
{{createOrGetLocallyAssignmentsAsync}} along as
{{{}writeTableAssignmentsToMetastore{}}};
** the goal of the previous bullet is to introduce new methods
{{isLocalNodeInAssignmentList}} and
{{isLocalNodeMatchAssignment}} that should be used for checking on a node's
TableManager and IndexManager is the node belongs to current stable assignments
or not. If the latter, then node shouldn't create storages and indices:
{{MvTableStorage}} and
{{TxStateTableStorage}} on table create event in
{{TableManager#createStorages}} and {{IndexManager#startIndexAsync}}
correspondingly.
Current issue is related to versioned values' race:
* {{TableManager.java:1395}} on {{tableVv.update(...)}}
* {{IndexManager.java:270}} on {{handleMetastoreEventVv.update(...)}}
There is {{AssertionError}} with a message like "Causality token is outdated,
previous token 21, got 21" when the number 21 may vary.
The reason is metastore's colling in {{createOrGetLocallyAssignmentsAsync}}
along as
{{{}writeTableAssignmentsToMetastore{}}}:
* the first one calls metastore to check are stable assignments equals null in
{{{}TableManager.java:1298{}}};
* the last one calls metastore to write stable assignments in
{{TableManager.java:705-706}} on {{.invoke(...)}} method.
There should be a way to call versioned value's update before addressing to
metastore.
was (Author: JIRAUSER303791):
At the current state, the following changes are done:
* In {{ItDistributionZonesFiltersTest}} the single
testFilteredDataNodesPropagatedToStable test was divided on 3 separate tests:
** {{testDataNodesByFilterPropagatedToStable}} that tests only by attribute
filtering by specified region and storage filter;
** {{testDataNodesByProfilePropagatedToStable}} that tests only by matching
profile name;
** {{testDataNodesByFilterAndProfilePropagatedToStable}} tests both cases
together: attribute filters and profile both.
*
* In {{TableManager}} was done refactoring:
** extracting assignments creation into the separate method
{{createOrGetLocallyAssignmentsAsync}} along as
{{{}writeTableAssignmentsToMetastore{}}};
** the goal of the previous bullet is to introduce new methods
{{isLocalNodeInAssignmentList}} and
{{isLocalNodeMatchAssignment}} that should be used for checking on a node's
TableManager and IndexManager is the node belongs to current stable assignments
or not. If the latter, then node shouldn't create storages and indices:
{{MvTableStorage}} and
{{TxStateTableStorage}} on table create event in
{{TableManager#createStorages}} and {{IndexManager#startIndexAsync}}
correspondingly.
Current issue is related to versioned values' race:
* {{TableManager.java:1395}} on {{tableVv.update(...)}}
* {{IndexManager.java:270}} on {{handleMetastoreEventVv.update(...)}}
There is {{AssertionError}} with a message like "Causality token is outdated,
previous token 21, got 21" when the number 21 may vary.
The reason is metastore's colling in {{createOrGetLocallyAssignmentsAsync}}
along as
{{{}writeTableAssignmentsToMetastore{}}}:
* the first one calls metastore to check are stable assignments equals null in
{{{}TableManager.java:1298{}}};
* the last one calls metastore to write stable assignments in
{{TableManager.java:705-706}} on {{.invoke(...)}} method.
There should be a way to call versioned value's update before addressing to
metastore.
> Recovery is not possible, if node have no needed storage profile
>
>
> Key: IGNITE-21387
> URL: https://issues.apache.org/jira/browse/IGNITE-21387
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> Looks like any table try to create storages on the recovery node, even if is
> shouldn't be here, because of zone storage profile filter.
> The isssue is reproducing by
>
[jira] [Comment Edited] (IGNITE-21387) Recovery is not possible, if node have no needed storage profile
[
https://issues.apache.org/jira/browse/IGNITE-21387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837121#comment-17837121
]
Mikhail Efremov edited comment on IGNITE-21387 at 4/15/24 1:10 PM:
---
At the current state, the following changes are done:
* In {{ItDistributionZonesFiltersTest}} the single
testFilteredDataNodesPropagatedToStable test was divided on 3 separate tests:
** {{testDataNodesByFilterPropagatedToStable}} that tests only by attribute
filtering by specified region and storage filter;
** {{testDataNodesByProfilePropagatedToStable}} that tests only by matching
profile name;
** {{testDataNodesByFilterAndProfilePropagatedToStable}} tests both cases
together: attribute filters and profile both.
*
* In {{TableManager}} was done refactoring:
** extracting assignments creation into the separate method
{{createOrGetLocallyAssignmentsAsync}} along as
{{{}writeTableAssignmentsToMetastore{}}};
** the goal of the previous bullet is to introduce new methods
{{isLocalNodeInAssignmentList}} and
{{isLocalNodeMatchAssignment}} that should be used for checking on a node's
TableManager and IndexManager is the node belongs to current stable assignments
or not. If the latter, then node shouldn't create storages and indices:
{{MvTableStorage}} and
{{TxStateTableStorage}} on table create event in
{{TableManager#createStorages}} and {{IndexManager#startIndexAsync}}
correspondingly.
Current issue is related to versioned values' race:
* {{TableManager.java:1395}} on {{tableVv.update(...)}}
* {{IndexManager.java:270}} on {{handleMetastoreEventVv.update(...)}}
There is {{AssertionError}} with a message like "Causality token is outdated,
previous token 21, got 21" when the number 21 may vary.
The reason is metastore's colling in {{createOrGetLocallyAssignmentsAsync}}
along as
{{{}writeTableAssignmentsToMetastore{}}}:
* the first one calls metastore to check are stable assignments equals null in
{{{}TableManager.java:1298{}}};
* the last one calls metastore to write stable assignments in
{{TableManager.java:705-706}} on {{.invoke(...)}} method.
There should be a way to call versioned value's update before addressing to
metastore.
was (Author: JIRAUSER303791):
At the current state, the following changes are done:
* In {{ItDistributionZonesFiltersTest}} the single
testFilteredDataNodesPropagatedToStable test was divided on 3 separate tests:
** {{testDataNodesByFilterPropagatedToStable}} that tests only by attribute
filtering by specified region and storage filter;
** {{testDataNodesByProfilePropagatedToStable}} that tests only by matching
profile name;
** {{testDataNodesByFilterAndProfilePropagatedToStable}} tests both cases
together: attribute filters and profile both.
* In {{TableManager}} was done refactoring:
** extracting assignments creation into the separate method
{{createOrGetLocallyAssignmentsAsync}} along as
{{{}writeTableAssignmentsToMetastore{}}};
** the goal of the previous bullet is to introduce new methods
{{isLocalNodeInAssignmentList}} and
{{isLocalNodeMatchAssignment}} that should be used for checking on a node's
TableManager and IndexManager is the node belongs to current stable assignments
or not. If the latter, then node shouldn't create storages and indices:
{{MvTableStorage}} and
{{TxStateTableStorage}} on table create event in
{{TableManager#createStorages}} and {{IndexManager#startIndexAsync}}
correspondingly.
Current issue is related to versioned values' race:
* {{TableManager.java:1395}} on {{tableVv.update(...)}}
* {{IndexManager.java:270}} on {{handleMetastoreEventVv.update(...)}}
There is {{AssertionError}} with a message like "Causality token is outdated,
previous token 21, got 21" when the number 21 may vary.
The reason is metastore's colling in {{createOrGetLocallyAssignmentsAsync}}
along as
{{{}writeTableAssignmentsToMetastore{}}}:
* the first one calls metastore to check are stable assignments equals null in
{{{}TableManager.java:1298{}}};
* the last one calls metastore to write stable assignments in
{{TableManager.java:705-706}} on {{.invoke(...)}} method.
There should be a way to call versioned value's update before addressing to
metastore.
> Recovery is not possible, if node have no needed storage profile
>
>
> Key: IGNITE-21387
> URL: https://issues.apache.org/jira/browse/IGNITE-21387
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> Looks like any table try to create storages on the recovery node, even if is
> shouldn't be here, because of zone storage profile filter.
> The isssue is reproducing by
>
[jira] [Comment Edited] (IGNITE-21387) Recovery is not possible, if node have no needed storage profile
[
https://issues.apache.org/jira/browse/IGNITE-21387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837121#comment-17837121
]
Mikhail Efremov edited comment on IGNITE-21387 at 4/15/24 9:05 AM:
---
At the current state, the following changes are done:
* In {{ItDistributionZonesFiltersTest}} the single
testFilteredDataNodesPropagatedToStable test was divided on 3 separate tests:
** {{testDataNodesByFilterPropagatedToStable}} that tests only by attribute
filtering by specified region and storage filter;
** {{testDataNodesByProfilePropagatedToStable}} that tests only by matching
profile name;
** {{testDataNodesByFilterAndProfilePropagatedToStable}} tests both cases
together: attribute filters and profile both.
* In {{TableManager}} was done refactoring:
** extracting assignments creation into the separate method
{{createOrGetLocallyAssignmentsAsync}} along as
{{{}writeTableAssignmentsToMetastore{}}};
** the goal of the previous bullet is to introduce new methods
{{isLocalNodeInAssignmentList}} and
{{isLocalNodeMatchAssignment}} that should be used for checking on a node's
TableManager and IndexManager is the node belongs to current stable assignments
or not. If the latter, then node shouldn't create storages and indices:
{{MvTableStorage}} and
{{TxStateTableStorage}} on table create event in
{{TableManager#createStorages}} and {{IndexManager#startIndexAsync}}
correspondingly.
Current issue is related to versioned values' race:
* {{TableManager.java:1395}} on {{tableVv.update(...)}}
* {{IndexManager.java:270}} on {{handleMetastoreEventVv.update(...)}}
There is {{AssertionError}} with a message like "Causality token is outdated,
previous token 21, got 21" when the number 21 may vary.
The reason is metastore's colling in {{createOrGetLocallyAssignmentsAsync}}
along as
{{{}writeTableAssignmentsToMetastore{}}}:
* the first one calls metastore to check are stable assignments equals null in
{{{}TableManager.java:1298{}}};
* the last one calls metastore to write stable assignments in
{{TableManager.java:705-706}} on {{.invoke(...)}} method.
There should be a way to call versioned value's update before addressing to
metastore.
was (Author: JIRAUSER303791):
At the current state, the following changes are done:
* In {{ItDistributionZonesFiltersTest}} the single
testFilteredDataNodesPropagatedToStable test was divided on 3 separate
tests:{color:#6b2fba}
{color}
**
{{testDataNodesByFilterPropagatedToStable}} that tests only by attribute
filtering by specified region and storage filter;
**
{{testDataNodesByProfilePropagatedToStable}} that tests only by matching
profile name;
**
{{testDataNodesByFilterAndProfilePropagatedToStable}} tests both cases
together: attribute filters and profile both.
* In {{TableManager}} was done refactoring:
** exctracting assignments creation into the separate method
{{createOrGetLocallyAssignmentsAsync}} along as
{{writeTableAssignmentsToMetastore;
}}
> Recovery is not possible, if node have no needed storage profile
>
>
> Key: IGNITE-21387
> URL: https://issues.apache.org/jira/browse/IGNITE-21387
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> Looks like any table try to create storages on the recovery node, even if is
> shouldn't be here, because of zone storage profile filter.
> The isssue is reproducing by
> ItDistributionZonesFiltersTest#testFilteredDataNodesPropagatedToStable. So,
> test must be enabled or reworked by this ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21387) Recovery is not possible, if node have no needed storage profile
[
https://issues.apache.org/jira/browse/IGNITE-21387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837121#comment-17837121
]
Mikhail Efremov commented on IGNITE-21387:
--
At the current state, the following changes are done:
* In {{ItDistributionZonesFiltersTest}} the single
testFilteredDataNodesPropagatedToStable test was divided on 3 separate
tests:{color:#6b2fba}
{color}
**
{{testDataNodesByFilterPropagatedToStable}} that tests only by attribute
filtering by specified region and storage filter;
**
{{testDataNodesByProfilePropagatedToStable}} that tests only by matching
profile name;
**
{{testDataNodesByFilterAndProfilePropagatedToStable}} tests both cases
together: attribute filters and profile both.
* In {{TableManager}} was done refactoring:
** exctracting assignments creation into the separate method
{{createOrGetLocallyAssignmentsAsync}} along as
{{writeTableAssignmentsToMetastore;
}}
> Recovery is not possible, if node have no needed storage profile
>
>
> Key: IGNITE-21387
> URL: https://issues.apache.org/jira/browse/IGNITE-21387
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> Looks like any table try to create storages on the recovery node, even if is
> shouldn't be here, because of zone storage profile filter.
> The isssue is reproducing by
> ItDistributionZonesFiltersTest#testFilteredDataNodesPropagatedToStable. So,
> test must be enabled or reworked by this ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22001) Throw specific exception if during writeTableAssignmentsToMetastore process was interrupted
Mikhail Efremov created IGNITE-22001:
Summary: Throw specific exception if during
writeTableAssignmentsToMetastore process was interrupted
Key: IGNITE-22001
URL: https://issues.apache.org/jira/browse/IGNITE-22001
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
h2. The problem
In {{TableManager#writeTableAssignmentsToMetastore:752}} as a result of output
{{CompletableFuture}} returns {{{}null{}}}-value. In cases of
{{writeTableAssignmentsToMetastore}} method's using it leads to sudden
{{NullPointerException}} without clear understandings of the reasons of such
situation.
h2. The solution
Instead of returning {{{}null{}}}-value re-throw more specific exception with
given assignments list to write in metastorage, and table identifier that
should help to investigate cases of the method interruption.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21808) CREATE ZONE syntax must work with any the case of zone name
[
https://issues.apache.org/jira/browse/IGNITE-21808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831788#comment-17831788
]
Mikhail Efremov commented on IGNITE-21808:
--
[~korlov] could you take a look too?
> CREATE ZONE syntax must work with any the case of zone name
> ---
>
> Key: IGNITE-21808
> URL: https://issues.apache.org/jira/browse/IGNITE-21808
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3, sql
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Steps to reproduce
> If we try to run such code
> {code:java}
> cluster.doInSession(0, session -> {
> session.execute(null, "CREATE ZONE test_zone");
> session.execute(null, "CREATE TABLE TEST (id INT PRIMARY KEY,
> name INT) WITH PRIMARY_ZONE='test_zone'");
> });
> {code}
> It fails with {{Failed to validate query. Distribution zone with name
> 'test_zone' not found,}}
> but works if zone name is in upper case
> This behaviour must be changed.
> h3. Definition of done
> * Zone name must support any case, not only upper case
> * Corresponding tests must be added
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21641) OOM in PartitionReplicaListenerTest
[
https://issues.apache.org/jira/browse/IGNITE-21641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822643#comment-17822643
]
Mikhail Efremov commented on IGNITE-21641:
--
The main suspect there is while(true) loop, that is a separated issue, and
delete-upsert-read chain that produces large a row versions chain.
!image-2024-03-01-20-36-08-577.png!
So, the solution may be for the one hand to restrict loop's iterations count or
set a timeout for a test, and for another hand is to figure out what's wrong
with delete-upsert-read. The flags case is: insertFirst=true,
upsertAfterDelete=true, committed=true, multiple=false. The reason may be in
the if (row == null) {} statement.
> OOM in PartitionReplicaListenerTest
> ---
>
> Key: IGNITE-21641
> URL: https://issues.apache.org/jira/browse/IGNITE-21641
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: image-2024-03-01-12-22-32-053.png,
> image-2024-03-01-20-36-08-577.png
>
>
> TC run failed with OOM
> Problem occurred after
> PartitionReplicaListenerTest.testReadOnlyGetAfterRowRewrite run,
> {noformat}
> [2024-03-01T05:12:50,629][INFO ][Test worker][PartitionReplicaListenerTest]
> >>> Starting test:
> PartitionReplicaListenerTest#testReadOnlyGetAfterRowRewrite, displayName:
> [14] true, true, false, true
> [2024-03-01T05:12:50,629][INFO ][Test worker][PartitionReplicaListenerTest]
> workDir:
> build/work/PartitionReplicaListenerTest/testReadOnlyGetAfterRowRewrite_33496469368142283
> [2024-03-01T05:12:50,638][INFO ][Test worker][PartitionReplicaListenerTest]
> >>> Stopping test:
> PartitionReplicaListenerTest#testReadOnlyGetAfterRowRewrite, displayName:
> [14] true, true, false, true, cost: 8ms.
> [05:12:50] : [testReadOnlyGetAfterRowRewrite(boolean,
> boolean, boolean, boolean)]
> org.apache.ignite.internal.table.distributed.replication.PartitionReplicaListenerTest.testReadOnlyGetAfterRowRewrite([15]
> true, true, true, false) (10m:22s)
> [05:12:50] : [:ignite-table:test] PartitionReplicaListenerTest >
> testReadOnlyGetAfterRowRewrite(boolean, boolean, boolean, boolean) > [15]
> true, true, true, false STANDARD_OUT
> [05:12:50] : [:ignite-table:test]
> [2024-03-01T05:12:50,648][INFO ][Test worker][PartitionReplicaListenerTest]
> >>> Starting test:
> PartitionReplicaListenerTest#testReadOnlyGetAfterRowRewrite, displayName:
> [15] true, true, true, false
> [05:12:50] : [:ignite-table:test]
> [2024-03-01T05:12:50,648][INFO ][Test worker][PartitionReplicaListenerTest]
> workDir:
> build/work/PartitionReplicaListenerTest/testReadOnlyGetAfterRowRewrite_33496469386328241
> [05:18:42] : [:ignite-table:test] java.lang.OutOfMemoryError: Java
> heap space
> [05:18:42] : [:ignite-table:test] Dumping heap to
> java_pid2349600.hprof ...
> [05:19:06] : [:ignite-table:test] Heap dump file created
> [3645526743 bytes in 24.038 secs]
> {noformat}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7898564?hideTestsFromDependencies=false=false+Inspection=true=true=true=false
> After analysing heap dump it appears that the reason of OOM is a problem with
> Mockito.
> !image-2024-03-01-12-22-32-053.png!
> We need to investigate the reason of a problem with Mockito
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21641) OOM in PartitionReplicaListenerTest
[
https://issues.apache.org/jira/browse/IGNITE-21641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-21641:
-
Attachment: image-2024-03-01-20-36-08-577.png
> OOM in PartitionReplicaListenerTest
> ---
>
> Key: IGNITE-21641
> URL: https://issues.apache.org/jira/browse/IGNITE-21641
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: image-2024-03-01-12-22-32-053.png,
> image-2024-03-01-20-36-08-577.png
>
>
> TC run failed with OOM
> Problem occurred after
> PartitionReplicaListenerTest.testReadOnlyGetAfterRowRewrite run,
> {noformat}
> [2024-03-01T05:12:50,629][INFO ][Test worker][PartitionReplicaListenerTest]
> >>> Starting test:
> PartitionReplicaListenerTest#testReadOnlyGetAfterRowRewrite, displayName:
> [14] true, true, false, true
> [2024-03-01T05:12:50,629][INFO ][Test worker][PartitionReplicaListenerTest]
> workDir:
> build/work/PartitionReplicaListenerTest/testReadOnlyGetAfterRowRewrite_33496469368142283
> [2024-03-01T05:12:50,638][INFO ][Test worker][PartitionReplicaListenerTest]
> >>> Stopping test:
> PartitionReplicaListenerTest#testReadOnlyGetAfterRowRewrite, displayName:
> [14] true, true, false, true, cost: 8ms.
> [05:12:50] : [testReadOnlyGetAfterRowRewrite(boolean,
> boolean, boolean, boolean)]
> org.apache.ignite.internal.table.distributed.replication.PartitionReplicaListenerTest.testReadOnlyGetAfterRowRewrite([15]
> true, true, true, false) (10m:22s)
> [05:12:50] : [:ignite-table:test] PartitionReplicaListenerTest >
> testReadOnlyGetAfterRowRewrite(boolean, boolean, boolean, boolean) > [15]
> true, true, true, false STANDARD_OUT
> [05:12:50] : [:ignite-table:test]
> [2024-03-01T05:12:50,648][INFO ][Test worker][PartitionReplicaListenerTest]
> >>> Starting test:
> PartitionReplicaListenerTest#testReadOnlyGetAfterRowRewrite, displayName:
> [15] true, true, true, false
> [05:12:50] : [:ignite-table:test]
> [2024-03-01T05:12:50,648][INFO ][Test worker][PartitionReplicaListenerTest]
> workDir:
> build/work/PartitionReplicaListenerTest/testReadOnlyGetAfterRowRewrite_33496469386328241
> [05:18:42] : [:ignite-table:test] java.lang.OutOfMemoryError: Java
> heap space
> [05:18:42] : [:ignite-table:test] Dumping heap to
> java_pid2349600.hprof ...
> [05:19:06] : [:ignite-table:test] Heap dump file created
> [3645526743 bytes in 24.038 secs]
> {noformat}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7898564?hideTestsFromDependencies=false=false+Inspection=true=true=true=false
> After analysing heap dump it appears that the reason of OOM is a problem with
> Mockito.
> !image-2024-03-01-12-22-32-053.png!
> We need to investigate the reason of a problem with Mockito
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15889) Add 'contains' method to Record API
[ https://issues.apache.org/jira/browse/IGNITE-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-15889: - Summary: Add 'contains' method to Record API (was: Add 'contains' method to Record API) > Add 'contains' method to Record API > --- > > Key: IGNITE-15889 > URL: https://issues.apache.org/jira/browse/IGNITE-15889 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3, newbie > Time Spent: 1h 10m > Remaining Estimate: 0h > > There is no method in Record API with the same semantic as the 'contains' > method in KV views. > Add *RecordView.contains* similar to *KeyValueView.contains*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15889) Add 'contains' method to Record API
[ https://issues.apache.org/jira/browse/IGNITE-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-15889: - Summary: Add 'contains' method to Record API (was: Add 'contains' method to Record API) > Add 'contains' method to Record API > > > Key: IGNITE-15889 > URL: https://issues.apache.org/jira/browse/IGNITE-15889 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3, newbie > Time Spent: 1h 10m > Remaining Estimate: 0h > > There is no method in Record API with the same semantic as the 'contains' > method in KV views. > Add *RecordView.contains* similar to *KeyValueView.contains*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21387) Recovery is not possible, if node have no needed storage profile
[ https://issues.apache.org/jira/browse/IGNITE-21387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-21387: - Summary: Recovery is not possible, if node have no needed storage profile (was: Recovery is not possible, if node have no needed storage profile) > Recovery is not possible, if node have no needed storage profile > > > Key: IGNITE-21387 > URL: https://issues.apache.org/jira/browse/IGNITE-21387 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3 > > Looks like any table try to create storages on the recovery node, even if is > shouldn't be here, because of zone storage profile filter. > The isssue is reproducing by > ItDistributionZonesFiltersTest#testFilteredDataNodesPropagatedToStable. So, > test must be enabled or reworked by this ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21387) Recovery is not possible, if node have no needed storage profile
[ https://issues.apache.org/jira/browse/IGNITE-21387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-21387: - Summary: Recovery is not possible, if node have no needed storage profile (was: Recovery is not possible, if node have no needed storage profile) > Recovery is not possible, if node have no needed storage profile > - > > Key: IGNITE-21387 > URL: https://issues.apache.org/jira/browse/IGNITE-21387 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3 > > Looks like any table try to create storages on the recovery node, even if is > shouldn't be here, because of zone storage profile filter. > The isssue is reproducing by > ItDistributionZonesFiltersTest#testFilteredDataNodesPropagatedToStable. So, > test must be enabled or reworked by this ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15889) Add 'contains' method to Record API
[
https://issues.apache.org/jira/browse/IGNITE-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812174#comment-17812174
]
Mikhail Efremov commented on IGNITE-15889:
--
[~amashenkov] Hi, I did the pull request, but have several questions:
# I have registered in TC, but have no access to the project and can't view
check logs without help. Can you grant me kind of viewer access in TC? The
username is the same as in JIRA.
# I launched gradle test task, It failed, but the failed test relates to
logging module {{{}ClientLoggingTest::testBasicLogging{}}}, I'm not sure should
I to fix it or not?
Thank you~
> Add 'contains' method to Record API
> ---
>
> Key: IGNITE-15889
> URL: https://issues.apache.org/jira/browse/IGNITE-15889
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3, newbie
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There is no method in Record API with the same semantic as the 'contains'
> method in KV views.
> Add *RecordView.contains* similar to *KeyValueView.contains*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-15889) Add 'contains' method to Record API
[ https://issues.apache.org/jira/browse/IGNITE-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov reassigned IGNITE-15889: Assignee: Mikhail Efremov > Add 'contains' method to Record API > --- > > Key: IGNITE-15889 > URL: https://issues.apache.org/jira/browse/IGNITE-15889 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3, newbie > > There is no method in Record API with the same semantic as the 'contains' > method in KV views. > Add *RecordView.contains* similar to *KeyValueView.contains*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
