[jira] [Updated] (IGNITE-20826) Restore last observable ordered timestamp on restart
[ https://issues.apache.org/jira/browse/IGNITE-20826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20826: - Reviewer: Ivan Bessonov > Restore last observable ordered timestamp on restart > > > Key: IGNITE-20826 > URL: https://issues.apache.org/jira/browse/IGNITE-20826 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > In order to guarantee that there's no safe time reordering within the very > first command after node restart, it's required either to restore the last > observable ordered safe time on restart or guarantee that it'll be ordered > because of some external invariants. > h3. Definition of Done > It is possible to check whether safeTime proposed after partition listener > restart is ordered with previously observed value. > h3. Implementation notes > One of the options is to guarantee that any proposed safe time is less than > primaryReplica.expirationTime. Along with selection of a new primary on > restart (with newPrimary.startTime > oldPrimaryStartTime) it'll be enough to > force the invariant specified in DoD. However, it's not trivial to handle > proposedSafeTime out of bounds condition. > Another option is to retrieve safe time from either raft log or snapshot. > > And last but not least - it's also required to restore last observable > ordered timestamp on partition listener re-creation in case of rebalance. > h3. Upd#1 > It's required to initialize `maxObservableSafeTime` not only within node > start but with leader election, actually only within leader election. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21530) Investigations
Alexander Lapin created IGNITE-21530: Summary: Investigations Key: IGNITE-21530 URL: https://issues.apache.org/jira/browse/IGNITE-21530 Project: Ignite Issue Type: Wish Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18502) Excessive full partition scan on node start
[ https://issues.apache.org/jira/browse/IGNITE-18502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin resolved IGNITE-18502. -- Resolution: Duplicate Issue is no longer needed because of fully implement write intent resolution logic, including the one on recovery. > Excessive full partition scan on node start > --- > > Key: IGNITE-18502 > URL: https://issues.apache.org/jira/browse/IGNITE-18502 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > *Motivation* > All tables have a transactional nature, even if we don't use transactions > explicitly. That means all entries are stored as write intents (pending > entries) before they are committed. Those entries are required for > transactional protocol and stored in in-memory collection > (_PartitionListener#txsPendingRowIds_). The collection can be lost due to > restart of the node where the data located. Recovery of the collection > happens through scan of all entries in the partition and can take long time. > There are several possible ways to solve this problem: to persist pending > rows collection, or resolve write intents when they are met by another > transaction, including RW transactions. After some discussions the latter > seems to be better decision, as it doesn't require one more persistent > storage/structure, and RW transactions should be able to resolve write > intents anyway. > *Definition of Done* > No full partition scan on start is needed. > *Implementation notes* > The chosen decision implies that unresolved write intents in partition can be > present in partition, even if such write intents belong to transaction that > was already committed or aborted. When another transaction (no matter > read-only or read-write) meets such write-intent it tries to resolve it. If > it belongs to transaction that was already finished, then local cleanup must > be run for this write-intent. This means that the write intent should be > committed or aborted as like it was processed by _TxCleanupCommand_, but > locally, because the corresponding write intents on another nodes had to be > already processed by transaction cleanup as normally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21378) Investigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817047#comment-17817047 ] Vladislav Pyatkov commented on IGNITE-21378: Merged e521574594d35405b2c0c9bfab8e5c44bcc14c4c > Investigate whether it's possible to make txnState local map updates faster > --- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: PERFORMANCE, Performance, ignite-3, ignite3_performance, > performance, performence > Time Spent: 20m > Remaining Estimate: 0h > > h3. Motivation > IGNITE-21375 is about removing txnState local map updates within RO txn flow > because it brings us 20% performance drop. For RW transactions, it's however > not possible, because such updates are required by the RW protocol. Thus, it > seems reasonable to verify whether proposed VolatileTxStateMetaStorage is > itself fast enough. > h3. Definition of Done > * Increase VolatileTxStateMetaStorag performance if it's possible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21513) ActiveActorTest#testChangeLeaderForce is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21513:
--
Description:
{code:java}
[05:19:12]F:
[org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370){code}
See IGNITE-21381 for more details. This ticket is about fixing flaky test and
removing the code duplication between ActiveActorTest and
TopologyAwareRaftGroupServiceTest.
The actual problem of the test was the race due to the lack of joins on a
futures from #subscribeLeader().
was:
{code:java}
[05:19:12]F:
[org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370){code}
See IGNITE-21381 for more details. This ticket is about fixing flaky test and
removing the code duplication between ActiveActorTest and
TopologyAwareRaftGroupServiceTest.
> ActiveActorTest#testChangeLeaderForce is flaky
> --
>
> Key: IGNITE-21513
> URL: https://issues.apache.org/jira/browse/IGNITE-21513
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> [05:19:12]F:
> [org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
>
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370){code}
> See IGNITE-21381 for more details. This ticket is about fixing flaky test and
> removing the code duplication between ActiveActorTest and
> TopologyAwareRaftGroupServiceTest.
> The actual problem of the test was the race due to the lack of joins on a
> futures from #subscribeLeader().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21529) Implement separate file writer for EventLog
Aleksandr created IGNITE-21529: -- Summary: Implement separate file writer for EventLog Key: IGNITE-21529 URL: https://issues.apache.org/jira/browse/IGNITE-21529 Project: Ignite Issue Type: Improvement Reporter: Aleksandr The first option to write events is to write them to FS. It seems like Logging framework can help us to avoid writing our own. The writing should not be blocking and should not affect the performance of the system. As a result of this ticket internal unit should be implemented. This unit can be configured (where in what format) to write "some" objects. External configurations and Events itself will be implemented later. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21528) EventLog for Apache Ignite 3
Aleksandr created IGNITE-21528: -- Summary: EventLog for Apache Ignite 3 Key: IGNITE-21528 URL: https://issues.apache.org/jira/browse/IGNITE-21528 Project: Ignite Issue Type: Epic Reporter: Aleksandr -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21253) Implement a counter for number of rebalancing tables inside the zone
[ https://issues.apache.org/jira/browse/IGNITE-21253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-21253: Description: *Motivation* According to comment we need to switch zone assignments, only when all zone tables finish their rebalances. To implement this behaviour we need to implement the metastorage counter of tables, which will be decreased on every successfull table rebalance. *Definition of done* - Counter of zone tables created on the rebalance start and decreased with every successfull table rebalance *Implementation notes* - on pending update we set the counter in metastore (if it is not exist). other tables can't be added because of "avoid table creation during the rebalance" ticket. - on the rebalance done instead of the current logic we decrease the counter (with compareAndSet). - the separate listener on every node listen to the counters and when it decreased to 0 - do the usual logic with planned->pending, pending->stable and etc. was: *Motivation* According to [comment|https://issues.apache.org/jira/browse/IGNITE-18991?focusedCommentId=17806657&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17806657] we need to switch zone assignments, only when all zone tables finish their rebalances. To implement this behaviour we need to implement the metastorage counter of tables, which will be decreased on every successfull table rebalance. *Definition of done* - Counter of zone tables created on the rebalance start and decreased with every successfull table rebalance > Implement a counter for number of rebalancing tables inside the zone > - > > Key: IGNITE-21253 > URL: https://issues.apache.org/jira/browse/IGNITE-21253 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > *Motivation* > According to comment we need to switch zone assignments, only when all zone > tables finish their rebalances. > To implement this behaviour we need to implement the metastorage counter of > tables, which will be decreased on every successfull table rebalance. > *Definition of done* > - Counter of zone tables created on the rebalance start and decreased with > every successfull table rebalance > *Implementation notes* > - on pending update we set the counter in metastore (if it is not exist). > other tables can't be added because of "avoid table creation during the > rebalance" ticket. > - on the rebalance done instead of the current logic we decrease the counter > (with compareAndSet). > - the separate listener on every node listen to the counters and when it > decreased to 0 - do the usual logic with planned->pending, pending->stable > and etc. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17824) Use named executor instead of default one in order to process replica Response
[
https://issues.apache.org/jira/browse/IGNITE-17824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy reassigned IGNITE-17824:
--
Assignee: Roman Puchkovskiy
> Use named executor instead of default one in order to process replica Response
> --
>
> Key: IGNITE-17824
> URL: https://issues.apache.org/jira/browse/IGNITE-17824
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> Within ReplicaService.sendToReplica
> {code:java}
> private CompletableFuture sendToReplica(ClusterNode node,
> ReplicaRequest req) {
> CompletableFuture res = new CompletableFuture<>();
> messagingService.invoke(node.address(), req,
> RPC_TIMEOUT).whenCompleteAsync((response, throwable) -> { {code}
> named executor should be used instead of default one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21500) Retry implicit transactions when primary replica failed or moved
[ https://issues.apache.org/jira/browse/IGNITE-21500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov updated IGNITE-21500: --- Description: *Motivation* Implicit transactions are created without a transaction from the client point of view (the transaction is created inside the library and is not exposed outside). A failure to execute such transaction because of the primary replica related exceptions (PrimaryReplicaMissException, etc.). should not result in the users seeing them. Instead, retrying these transactions will likely to succeed. *Definition of done* An implicit transaction that failed to execute because of PrimaryReplicaMissException, PrimaryReplicaAwaitException, TransactionExceptions with messages like "Failed to get the primary replica", "Failed to resolve the primary replica node" should be retried. If it is not possible to await for the primary replica, the transaction will fail. The primary replica failure exceptions are not propagated to the users in cases of implicit transactions - a different exception is thrown instead. *Implementation detail* There might be some difficulties with implicit scan and implicit direct RO transactions. No issues with plain implicit RW transactions is expected. was: *Motivation* Implicit transactions are created without a transaction from the client point of view (the transaction is created inside the library and is not exposed outside). A failure to execute such transaction because of the primary replica related exceptions (PrimaryReplicaMissException, etc.). should not result in the users seeing them. Instead, retrying these transactions will likely to succeed. *Definition of done* An implicit transaction that failed to execute because of PrimaryReplicaMissException, PrimaryReplicaAwaitException, TransactionExceptions with messages like "Failed to get the primary replica", "Failed to resolve the primary replica node" should be retried. If it is not possible to await for the primary replica, the transaction will fail. The primary replica failure exceptions are not propagated to the users in cases of implicit transactions. *Implementation detail* There might be some difficulties with implicit scan and implicit direct RO transactions. No issues with plain implicit RW transactions is expected. > Retry implicit transactions when primary replica failed or moved > > > Key: IGNITE-21500 > URL: https://issues.apache.org/jira/browse/IGNITE-21500 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Implicit transactions are created without a transaction from the client point > of view (the transaction is created inside the library and is not exposed > outside). > A failure to execute such transaction because of the primary replica related > exceptions (PrimaryReplicaMissException, etc.). should not result in the > users seeing them. > Instead, retrying these transactions will likely to succeed. > *Definition of done* > An implicit transaction that failed to execute because of > PrimaryReplicaMissException, PrimaryReplicaAwaitException, > TransactionExceptions with messages like "Failed to get the primary replica", > "Failed to resolve the primary replica node" > should be retried. > If it is not possible to await for the primary replica, the transaction will > fail. The primary replica failure exceptions are not propagated to the users > in cases of implicit transactions - a different exception is thrown instead. > *Implementation detail* > There might be some difficulties with implicit scan and implicit direct RO > transactions. No issues with plain implicit RW transactions is expected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21500) Retry implicit transactions when primary replica failed or moved
[ https://issues.apache.org/jira/browse/IGNITE-21500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov updated IGNITE-21500: --- Description: *Motivation* Implicit transactions are created without a transaction from the client point of view (the transaction is created inside the library and is not exposed outside). A failure to execute such transaction because of the primary replica related exceptions (PrimaryReplicaMissException, etc.). should not result in the users seeing them. Instead, retrying these transactions will likely to succeed. *Definition of done* An implicit transaction that failed to execute because of PrimaryReplicaMissException, PrimaryReplicaAwaitException, TransactionExceptions with messages like "Failed to get the primary replica", "Failed to resolve the primary replica node" should be retried. If it is not possible to await for the primary replica, the transaction will fail. The primary replica failure exceptions are not propagated to the users in cases of implicit transactions. *Implementation detail* There might be some difficulties with implicit scan and implicit direct RO transactions. No issues with plain implicit RW transactions is expected. was: *Motivation* Implicit transactions are created without a transaction from the client point of view (the transaction is created inside the library and is not exposed outside). A failure to execute such transaction because of the primary replica related exceptions (PrimaryReplicaMissException, etc.). should not result in the users seeing them. Instead, retrying these transactions will likely to succeed. *Definition of done* An implicit transaction that failed to execute because of PrimaryReplicaMissException, PrimaryReplicaAwaitException, TransactionExceptions with messages like "Failed to get the primary replica", "Failed to resolve the primary replica node" should be retried. If it is not possible to await for the primary replica, the transaction will fail. The primary replica failure exceptions are not propagated to the users in cases of implicit transactions. *Implementation detail* There might be some difficulties with implicit scan and implicit direct RO transactions. No issues with plain implicit RW transactions is expected. > Retry implicit transactions when primary replica failed or moved > > > Key: IGNITE-21500 > URL: https://issues.apache.org/jira/browse/IGNITE-21500 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Implicit transactions are created without a transaction from the client point > of view (the transaction is created inside the library and is not exposed > outside). > A failure to execute such transaction because of the primary replica related > exceptions (PrimaryReplicaMissException, etc.). should not result in the > users seeing them. > Instead, retrying these transactions will likely to succeed. > *Definition of done* > An implicit transaction that failed to execute because of > PrimaryReplicaMissException, PrimaryReplicaAwaitException, > TransactionExceptions with messages like "Failed to get the primary replica", > "Failed to resolve the primary replica node" > should be retried. > If it is not possible to await for the primary replica, the transaction will > fail. The primary replica failure exceptions are not propagated to the users > in cases of implicit transactions. > *Implementation detail* > There might be some difficulties with implicit scan and implicit direct RO > transactions. No issues with plain implicit RW transactions is expected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21500) Retry implicit transactions when primary replica failed or moved
[
https://issues.apache.org/jira/browse/IGNITE-21500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov updated IGNITE-21500:
---
Description:
*Motivation*
Implicit transactions are created without a transaction from the client point
of view (the transaction is created inside the library and is not exposed
outside).
A failure to execute such transaction because of the primary replica related
exceptions (PrimaryReplicaMissException, etc.). should not result in the users
seeing them. Instead, retrying these transactions will likely to succeed.
*Definition of done*
An implicit transaction that failed to execute because of
PrimaryReplicaMissException, PrimaryReplicaAwaitException,
TransactionExceptions with messages like "Failed to get the primary replica",
"Failed to resolve the primary replica node"
should be retried.
If it is not possible to await for the primary replica, the transaction will
fail. The primary replica failure exceptions are not propagated to the users in
cases of implicit transactions.
*Implementation detail*
There might be some difficulties with implicit scan and implicit direct RO
transactions. No issues with plain implicit RW transactions is expected.
was:
*Motivation*
Implicit transactions usually are "full" and include just one transactional
request which can be safely retried in case of the primary replica related
exceptions (PrimaryReplicaMissException, etc.). So users will never see these
exceptions in case of primary replica failures.
*Definition of done*
PrimaryReplicaMissException, PrimaryReplicaAwaitException,
TransactionExceptions with messages like "Failed to get the primary replica",
"Failed to resolve the primary replica node" are not propagated to the users in
cases of implicit full transactions. If it is not possible to await for primary
replica, PrimaryReplicaAwaitException or transaction exception with timeout is
still possible.
*Implementation detail*
Likely all that is required to do - is to handle the mentioned kinds of
exceptions in {{InternalTableImpl.wrapReplicationException}} and rethrow an
exception with the desired message.
> Retry implicit transactions when primary replica failed or moved
>
>
> Key: IGNITE-21500
> URL: https://issues.apache.org/jira/browse/IGNITE-21500
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Implicit transactions are created without a transaction from the client point
> of view (the transaction is created inside the library and is not exposed
> outside).
> A failure to execute such transaction because of the primary replica related
> exceptions (PrimaryReplicaMissException, etc.). should not result in the
> users seeing them. Instead, retrying these transactions will likely to
> succeed.
> *Definition of done*
> An implicit transaction that failed to execute because of
> PrimaryReplicaMissException, PrimaryReplicaAwaitException,
> TransactionExceptions with messages like "Failed to get the primary replica",
> "Failed to resolve the primary replica node"
> should be retried.
> If it is not possible to await for the primary replica, the transaction will
> fail. The primary replica failure exceptions are not propagated to the users
> in cases of implicit transactions.
> *Implementation detail*
> There might be some difficulties with implicit scan and implicit direct RO
> transactions. No issues with plain implicit RW transactions is expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21500) Retry implicit transactions when primary replica failed or moved
[
https://issues.apache.org/jira/browse/IGNITE-21500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov updated IGNITE-21500:
---
Summary: Retry implicit transactions when primary replica failed or moved
(was: Retry implicit full transactions in case of exceptions related to primary
replica failure or move)
> Retry implicit transactions when primary replica failed or moved
>
>
> Key: IGNITE-21500
> URL: https://issues.apache.org/jira/browse/IGNITE-21500
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Implicit transactions usually are "full" and include just one transactional
> request which can be safely retried in case of the primary replica related
> exceptions (PrimaryReplicaMissException, etc.). So users will never see these
> exceptions in case of primary replica failures.
> *Definition of done*
> PrimaryReplicaMissException, PrimaryReplicaAwaitException,
> TransactionExceptions with messages like "Failed to get the primary replica",
> "Failed to resolve the primary replica node" are not propagated to the users
> in cases of implicit full transactions. If it is not possible to await for
> primary replica, PrimaryReplicaAwaitException or transaction exception with
> timeout is still possible.
> *Implementation detail*
> Likely all that is required to do - is to handle the mentioned kinds of
> exceptions in {{InternalTableImpl.wrapReplicationException}} and rethrow an
> exception with the desired message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21484) Possible race in JobExecution.changePriority method
[ https://issues.apache.org/jira/browse/IGNITE-21484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21484: - Labels: ignite-3 (was: ) > Possible race in JobExecution.changePriority method > --- > > Key: IGNITE-21484 > URL: https://issues.apache.org/jira/browse/IGNITE-21484 > Project: Ignite > Issue Type: Bug > Components: compute >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Dmitry Baranov >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > In > [https://github.com/apache/ignite-3/blob/6729811f99ad18b1490f9b7516a2af84a898e7af/modules/compute/src/main/java/org/apache/ignite/internal/compute/queue/QueueExecutionImpl.java#L115] > race is possible. > thread 1: remove task from the queue > thread 2: haven't found the same task in the queue because it is not added > yet by thread 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21482) Fix of initialization of the last version in GridCacheVersionManager
[
https://issues.apache.org/jira/browse/IGNITE-21482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21482:
--
Description:
GridCacheVersionManager has wierd initialization of its _last_ version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this 'zeroed' value is read before any CRUD, a following
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise the initialization code. The assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
Or we should remove this last version at all. Looks like we need only the order.
was:
GridCacheVersionManager has wierd initialization of its _last_ version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this 'zeroed' value is read before any CRUD, a following
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise the initialization code. The assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
> Fix of initialization of the last version in GridCacheVersionManager
>
>
> Key: IGNITE-21482
> URL: https://issues.apache.org/jira/browse/IGNITE-21482
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> GridCacheVersionManager has wierd initialization of its _last_ version:
> {code:java}
> public void onLocalJoin(long topVer) {
> long startTime = cctx.kernalContext().discovery().gridStartTime();
> if (startTime != 0)
> offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
> last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
> ...
> }
> {code}
> _topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
> '_topVer Topology version plus number of seconds from the start time of the
> first grid node._'. If this 'zeroed' value is read before any CRUD, a
> following comparation of the versions may fail. This happened in
> [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
> We should revise the initialization code. The assumed fix is:
> {code:java}
> last = new GridCacheVersion((int)topVer + offset, order.get(),
> (int)cctx.localNode().order(), dataCenterId);
> {code}
> Or we should remove this last version at all. Looks like we need only the
> order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21391:
-
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
the appropariate line of code with fail
[https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
{code:java}
cluster.ensureSame();{code}
Didn't manage to reproduce the issue locally, however there are several
failures in TC with same reason.
was:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
the appropariate line of code with fail
https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570
{code:java}
cluster.ensureSame();{code}
Didn't manage to reproduce the issue locally, however there are several
failures in TC with same reason.
> ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
> ---
>
> Key: IGNITE-21391
> URL: https://issues.apache.org/jira/browse/IGNITE-21391
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Attachments: test.log
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
> the appropariate line of code with fail
> [https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
> {code:java}
> cluster.ensureSame();{code}
> Didn't manage to reproduce the issue locally, however there are several
> failures in TC with same reason.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19608) Startup errors are ignored in ignite3db script
[
https://issues.apache.org/jira/browse/IGNITE-19608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-19608:
--
Assignee: Aleksandr (was: Mikhail Pochatkin)
> Startup errors are ignored in ignite3db script
> --
>
> Key: IGNITE-19608
> URL: https://issues.apache.org/jira/browse/IGNITE-19608
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1, 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Aleksandr
>Priority: Blocker
> Labels: cli, ignite-3
>
> Ignite3 node is started by `bin/ignite3db` shell script. Unfortunately, this
> script follows some shell scripting bad practices that makes troubleshooting
> harder when something goes wrong.
> Particullary, there are following issues:
> 1. No guarding bash options (like `nounset`, `errexit`, or `pipefile`) is set.
> 2. When starting Java application, its stderr and stdout are redirected into
> `/dev/null`.
> {code:bash}
> CMD="${JAVA_CMD_WITH_ARGS} ${APPLICATION_ARGS}"
> $CMD >>/dev/null 2>&1 ${IGNITE_HOME}/pid
> {code}
> Just for comparison: [control.sh in
> AI2|https://github.com/apache/ignite/blob/master/bin/control.sh] do not
> suffer from such behavior. This should be fixed in AI3 too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21391:
-
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
the appropariate line of code with fail
[https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
{code:java}
cluster.ensureSame();{code}
Didn't manage to reproduce the issue locally, however, there are several
failures in TC with same reason.
was:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
the appropariate line of code with fail
[https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
{code:java}
cluster.ensureSame();{code}
Didn't manage to reproduce the issue locally, however there are several
failures in TC with same reason.
> ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
> ---
>
> Key: IGNITE-21391
> URL: https://issues.apache.org/jira/browse/IGNITE-21391
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Attachments: test.log
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
> the appropariate line of code with fail
> [https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
> {code:java}
> cluster.ensureSame();{code}
> Didn't manage to reproduce the issue locally, however, there are several
> failures in TC with same reason.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21526) .NET: Clean up IEP-54 leftovers
[ https://issues.apache.org/jira/browse/IGNITE-21526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21526: Labels: .NET ignite-3 (was: ignite-3) > .NET: Clean up IEP-54 leftovers > --- > > Key: IGNITE-21526 > URL: https://issues.apache.org/jira/browse/IGNITE-21526 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Igor Sapego >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement IGNITE-19744 for .NET Client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21527) C++: Clean up IEP-54 leftovers
[ https://issues.apache.org/jira/browse/IGNITE-21527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-21527: - Description: Implement IGNITE-19744 for C++ Client. (was: Implement IGNITE-19744 for .NET Client.) > C++: Clean up IEP-54 leftovers > -- > > Key: IGNITE-21527 > URL: https://issues.apache.org/jira/browse/IGNITE-21527 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Implement IGNITE-19744 for C++ Client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21526) .NET: Clean up IEP-54 leftovers
[ https://issues.apache.org/jira/browse/IGNITE-21526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-21526: - Description: Implement IGNITE-19744 for .NET Client. (was: Implement IGNITE-19744 for Java Client and server counterpart.) > .NET: Clean up IEP-54 leftovers > --- > > Key: IGNITE-21526 > URL: https://issues.apache.org/jira/browse/IGNITE-21526 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Implement IGNITE-19744 for .NET Client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21527) C++: Clean up IEP-54 leftovers
Igor Sapego created IGNITE-21527: Summary: C++: Clean up IEP-54 leftovers Key: IGNITE-21527 URL: https://issues.apache.org/jira/browse/IGNITE-21527 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Igor Sapego Fix For: 3.0.0-beta2 Implement IGNITE-19744 for .NET Client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21526) .NET: Clean up IEP-54 leftovers
Igor Sapego created IGNITE-21526: Summary: .NET: Clean up IEP-54 leftovers Key: IGNITE-21526 URL: https://issues.apache.org/jira/browse/IGNITE-21526 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Igor Sapego Fix For: 3.0.0-beta2 Implement IGNITE-19744 for Java Client and server counterpart. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21525) Java Client: Clean up IEP-54 leftovers
Igor Sapego created IGNITE-21525: Summary: Java Client: Clean up IEP-54 leftovers Key: IGNITE-21525 URL: https://issues.apache.org/jira/browse/IGNITE-21525 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Igor Sapego Fix For: 3.0.0-beta2 Implement IGNITE-19744 for Java Client and server counterpart. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21378) Investigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-21378: --- Reviewer: Denis Chudov > Investigate whether it's possible to make txnState local map updates faster > --- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: PERFORMANCE, Performance, ignite-3, ignite3_performance, > performance, performence > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > IGNITE-21375 is about removing txnState local map updates within RO txn flow > because it brings us 20% performance drop. For RW transactions, it's however > not possible, because such updates are required by the RW protocol. Thus, it > seems reasonable to verify whether proposed VolatileTxStateMetaStorage is > itself fast enough. > h3. Definition of Done > * Increase VolatileTxStateMetaStorag performance if it's possible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21524) Sql. Incorrect conversion to KeyValue plan.
Maksim Zhuravkov created IGNITE-21524: - Summary: Sql. Incorrect conversion to KeyValue plan. Key: IGNITE-21524 URL: https://issues.apache.org/jira/browse/IGNITE-21524 Project: Ignite Issue Type: Bug Components: sql Reporter: Maksim Zhuravkov Queries that use part of a primary key can be incorrectly converted to KeyValuePlans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21524) Sql. Incorrect conversion to KeyValue plan.
[ https://issues.apache.org/jira/browse/IGNITE-21524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21524: -- Labels: ignite-3 (was: ) > Sql. Incorrect conversion to KeyValue plan. > --- > > Key: IGNITE-21524 > URL: https://issues.apache.org/jira/browse/IGNITE-21524 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Queries that use part of a primary key can be incorrectly converted to > KeyValuePlans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21523) ItNodeRestartsTest.testRestarts is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-21523:
---
Description:
After running the test repeatedly, the following happened: after a restart of 2
clusterServices, one of the restarted cluster services (port 3344) and one of
not restarted cluster services (port 3345) could not 'see' each other due to
metadata obtaining timeout:
[2024-02-12T14:16:54,968][WARN ][sc-cluster-3345-1409][MetadataStore]
[default:inrt_tr_3345:13b7bdae21a14c86@127.0.1.1:3345][56ad9288-7ce4-4f67-b11c-8e1eaf6d6612]
Timeout getting GetMetadataResp from 127.0.1.1:3344 within 1000 ms, cause:
java.util.concurrent.TimeoutException: Did not observe any item or terminal
signal within 1000ms in 'source(MonoDefer)' (and no fallback has been
configured)
[2024-02-12T14:16:54,968][WARN ][sc-cluster-3345-1409][MembershipProtocol]
[default:inrt_tr_3345:13b7bdae21a14c86@127.0.1.1:3345][updateMembership][SYNC]
Skipping to add/update member: \{m:
default:inrt_tr_3344:788fea0a8f9b4251@127.0.1.1:3344, s: ALIVE, inc: 0}, due to
failed fetchMetadata call (cause: java.util.concurrent.TimeoutException: Did
not observe any item or terminal signal within 1000ms in 'source(MonoDefer)'
(and no fallback has been configured))
> ItNodeRestartsTest.testRestarts is flaky
>
>
> Key: IGNITE-21523
> URL: https://issues.apache.org/jira/browse/IGNITE-21523
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> After running the test repeatedly, the following happened: after a restart of
> 2 clusterServices, one of the restarted cluster services (port 3344) and one
> of not restarted cluster services (port 3345) could not 'see' each other due
> to metadata obtaining timeout:
> [2024-02-12T14:16:54,968][WARN ][sc-cluster-3345-1409][MetadataStore]
> [default:inrt_tr_3345:13b7bdae21a14c86@127.0.1.1:3345][56ad9288-7ce4-4f67-b11c-8e1eaf6d6612]
> Timeout getting GetMetadataResp from 127.0.1.1:3344 within 1000 ms, cause:
> java.util.concurrent.TimeoutException: Did not observe any item or terminal
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been
> configured)
> [2024-02-12T14:16:54,968][WARN ][sc-cluster-3345-1409][MembershipProtocol]
> [default:inrt_tr_3345:13b7bdae21a14c86@127.0.1.1:3345][updateMembership][SYNC]
> Skipping to add/update member: \{m:
> default:inrt_tr_3344:788fea0a8f9b4251@127.0.1.1:3344, s: ALIVE, inc: 0}, due
> to failed fetchMetadata call (cause: java.util.concurrent.TimeoutException:
> Did not observe any item or terminal signal within 1000ms in
> 'source(MonoDefer)' (and no fallback has been configured))
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21523) ItNodeRestartsTest.testRestarts is flaky
Roman Puchkovskiy created IGNITE-21523: -- Summary: ItNodeRestartsTest.testRestarts is flaky Key: IGNITE-21523 URL: https://issues.apache.org/jira/browse/IGNITE-21523 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21522) Remove GetAsync() from C++ doc
[ https://issues.apache.org/jira/browse/IGNITE-21522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816943#comment-17816943 ] Igor Gusev commented on IGNITE-21522: - [~isapego] can you please review the PR? > Remove GetAsync() from C++ doc > -- > > Key: IGNITE-21522 > URL: https://issues.apache.org/jira/browse/IGNITE-21522 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > In the async execution section, we have a C++ example that uses an API that > does not exist: > [https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution] > Please remove the invalid example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21522) Remove GetAsync() from C++ doc
[ https://issues.apache.org/jira/browse/IGNITE-21522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-21522: --- Assignee: Igor Gusev > Remove GetAsync() from C++ doc > -- > > Key: IGNITE-21522 > URL: https://issues.apache.org/jira/browse/IGNITE-21522 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > In the async execution section, we have a C++ example that uses an API that > does not exist: > [https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution] > Please remove the invalid example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21522) Remove GetAsync() from C++ doc
Igor Gusev created IGNITE-21522: --- Summary: Remove GetAsync() from C++ doc Key: IGNITE-21522 URL: https://issues.apache.org/jira/browse/IGNITE-21522 Project: Ignite Issue Type: Task Components: documentation Reporter: Igor Gusev In the async execution section, we have a C++ example that uses an API that does not exist: [https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution] Please remove the invalid example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816931#comment-17816931
]
Kirill Gusakov commented on IGNITE-21391:
-
According to the logs the issue is connected with the restart of nodes. After
restart 2 nodes from 5 is not seeing the full topology:
{noformat}
[2024-01-30T00:06:06,978][INFO ][Test worker][ItNodeTest] Restart error
follower int_taewfiies_5003 and old leader int_taewfiies_5004
[2024-01-30T00:06:07,023][INFO ][sc-cluster-5006-271][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003]]
[2024-01-30T00:06:07,023][INFO ][sc-cluster-5005-270][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003]]
[2024-01-30T00:06:07,023][INFO ][sc-cluster-5007-272][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003]]
[2024-01-30T00:06:07,025][INFO ][sc-cluster-5003-273][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5006]]
[2024-01-30T00:06:07,025][INFO ][sc-cluster-5003-273][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5006]]
[2024-01-30T00:06:07,025][INFO ][sc-cluster-5003-273][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006]]
[2024-01-30T00:06:07,097][INFO ][Test worker][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003]]
[2024-01-30T00:06:07,164][INFO ][sc-cluster-5003-273][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:07,164][INFO ][sc-cluster-5006-271][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:07,164][INFO ][sc-cluster-5007-272][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:07,167][INFO ][sc-cluster-5004-274][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5006]]
[2024-01-30T00:06:07,167][INFO ][sc-cluster-5004-274][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5006, int_taewfiies_5003]]
[2024-01-30T00:06:07,167][INFO ][sc-cluster-5004-274][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5006,
int_taewfiies_5003]]
[2024-01-30T00:06:07,379][INFO ][sc-cluster-5007-272][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:07,782][INFO ][sc-cluster-5005-270][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003]]
[2024-01-30T00:06:07,907][INFO ][sc-cluster-5007-272][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:08,022][INFO ][sc-cluster-5006-271][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:08,023][INFO ][sc-cluster-5005-270][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003]]
[2024-01-30T00:06:08,403][INFO ][sc-cluster-5006-271][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5005,
int_taewfiies_5006, int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:10,167][INFO ][Test worker][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5006,
int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:30,221][INFO ][sc-cluster-5006-271][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5006,
int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:30,221][INFO ][sc-cluster-5007-272][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5006,
int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:30,222][INFO ][sc-cluster-5003-273][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5006,
int_taewfiies_5003, int_taewfiies_5004]]
[2024-01-30T00:06:30,569][INFO ][sc-cluster-5003-273][ScaleCubeTopologyService]
Topology snapshot [nodes=[int_taewfiies_5007, int_taewfiies_5003,
int_taewfiies_5004]]
[2024-01-30T00:06:30,569][INFO ][sc-cluster-5004-274][Scale
[jira] [Updated] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov updated IGNITE-21391:
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
the appropariate line of code with fail
https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570
{code:java}
cluster.ensureSame();{code}
Didn't manage to reproduce the issue locally, however there are several
failures in TC with same reason.
was:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
ItNodeTest.java:2568 is
{code:java}
assertTrue(cluster.start(findById(peers, oldLeaderAddr)));{code}
Didn't manage to reproduce the issue locally, however there are several
failures in TC with same reason.
> ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
> ---
>
> Key: IGNITE-21391
> URL: https://issues.apache.org/jira/browse/IGNITE-21391
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Attachments: test.log
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
> the appropariate line of code with fail
> https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570
> {code:java}
> cluster.ensureSame();{code}
> Didn't manage to reproduce the issue locally, however there are several
> failures in TC with same reason.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov updated IGNITE-21391:
Attachment: test.log
> ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
> ---
>
> Key: IGNITE-21391
> URL: https://issues.apache.org/jira/browse/IGNITE-21391
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Attachments: test.log
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
> ItNodeTest.java:2568 is
> {code:java}
> assertTrue(cluster.start(findById(peers, oldLeaderAddr)));{code}
> Didn't manage to reproduce the issue locally, however there are several
> failures in TC with same reason.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21403) DataStreamer data removal: update public API
[
https://issues.apache.org/jira/browse/IGNITE-21403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816918#comment-17816918
]
Igor Sapego commented on IGNITE-21403:
--
Looks good to me.
> DataStreamer data removal: update public API
>
>
> Key: IGNITE-21403
> URL: https://issues.apache.org/jira/browse/IGNITE-21403
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Change *DataStreamerTarget.streamData* signature to accept *DataStreamerItem*
> instead of raw data:
> {code:java}
> CompletableFuture streamData(
> Flow.Publisher> publisher,
> @Nullable DataStreamerOptions options);
> {code}
> Where *DataStreamerItem* is:
> {code:java}
> public interface DataStreamerItem {
> T get();
> DataStreamerOperationType operationType();
> static DataStreamerItem of(T item) {
> return of(item, DataStreamerOperationType.PUT);
> }
> static DataStreamerItem removed(T item) {
> return of(item, DataStreamerOperationType.REMOVE);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-16184) testTransferLeader is flaky
[ https://issues.apache.org/jira/browse/IGNITE-16184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-16184. -- Resolution: Cannot Reproduce > testTransferLeader is flaky > --- > > Key: IGNITE-16184 > URL: https://issues.apache.org/jira/browse/IGNITE-16184 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Priority: Blocker > Labels: ignite-3 > Attachments: testTransferLeader.log > > > ItCliServiceTest.testTransferLeader is flaky. Need to find out the root cause. > See attached log. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21504) Sql. PlanningCacheMetricsTest.plannerCacheStatisticsTest is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-21504: - Assignee: Maksim Zhuravkov > Sql. PlanningCacheMetricsTest.plannerCacheStatisticsTest is flaky. > --- > > Key: IGNITE-21504 > URL: https://issues.apache.org/jira/browse/IGNITE-21504 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Cache implementation used for SQL plan uses common ForkJoin pool for clean up > task, so cache eviction events can be delayed, thus producing hit events, > when no such events expected by test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21508) Move storage operations from critical threads
[ https://issues.apache.org/jira/browse/IGNITE-21508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816911#comment-17816911 ] Roman Puchkovskiy commented on IGNITE-21508: Thanks! > Move storage operations from critical threads > - > > Key: IGNITE-21508 > URL: https://issues.apache.org/jira/browse/IGNITE-21508 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > Sometimes storages are accessed from threads that are not designed to be > blocked/perform I/O. Such accesses need to be moved to suitable threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21392) .NET: Test TestAllSupportedArgTypes is flaky in main
[
https://issues.apache.org/jira/browse/IGNITE-21392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-21392.
-
Resolution: Cannot Reproduce
There are no failures for two weeks in any branch.
> .NET: Test TestAllSupportedArgTypes is flaky in main
>
>
> Key: IGNITE-21392
> URL: https://issues.apache.org/jira/browse/IGNITE-21392
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
>
> The following test is flaky in main:
> https://ci.ignite.apache.org/test/6772548500460754348?currentProjectId=ApacheIgnite3xGradle_Test&expandTestHistoryChartSection=true
> Fails with a timeout. Warnings in the log:
> {code}
>
> [2024-01-24T02:22:53,167][ERROR][%org.apache.ignite.internal.runner.app.PlatformTestNodeRunner_2%common-scheduler-0][CriticalWorkerWatchdog]
> A critical thread is blocked for 5198 ms that is more than the allowed 500
> ms, it is
> "org.apache.ignite.internal.runner.app.PlatformTestNodeRunner_2-srv-worker-4"
> prio=10 Id=237 TIMED_WAITING on
> java.util.concurrent.CompletableFuture$Signaller@dce8129
> 02:22:53
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21403) DataStreamer data removal: update public API
[
https://issues.apache.org/jira/browse/IGNITE-21403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816895#comment-17816895
]
Pavel Tupitsyn edited comment on IGNITE-21403 at 2/13/24 8:18 AM:
--
[~isapego] please review.
was (Author: ptupitsyn):
[~isapego] please review,
> DataStreamer data removal: update public API
>
>
> Key: IGNITE-21403
> URL: https://issues.apache.org/jira/browse/IGNITE-21403
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Change *DataStreamerTarget.streamData* signature to accept *DataStreamerItem*
> instead of raw data:
> {code:java}
> CompletableFuture streamData(
> Flow.Publisher> publisher,
> @Nullable DataStreamerOptions options);
> {code}
> Where *DataStreamerItem* is:
> {code:java}
> public interface DataStreamerItem {
> T get();
> DataStreamerOperationType operationType();
> static DataStreamerItem of(T item) {
> return of(item, DataStreamerOperationType.PUT);
> }
> static DataStreamerItem removed(T item) {
> return of(item, DataStreamerOperationType.REMOVE);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21521) Wrong update order in upsertAll and DataStreamer for a new key
[
https://issues.apache.org/jira/browse/IGNITE-21521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816894#comment-17816894
]
Pavel Tupitsyn commented on IGNITE-21521:
-
Discussed with [~ascherbakov]:
We could throw away all updates for the key except the last one, but that may
cause unexpected behavior (missing trigger or continuous query invocations).
Therefore, we should apply all updates requested by the user in the correct
order.
> Wrong update order in upsertAll and DataStreamer for a new key
> --
>
> Key: IGNITE-21521
> URL: https://issues.apache.org/jira/browse/IGNITE-21521
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *ItInternalTableTest* to reproduce:
> {code:java}
> @Test
> public void upsertAllOrderTest() {
> RecordView view = table.recordView();
> InternalTable internalTable = ((TableViewInternal)
> table).internalTable();
> List rows = new ArrayList<>();
> int count = 100;
> int lastId = count - 1;
> long id = 12345;
> for (int i = 0; i < count; i++) {
> rows.add(createKeyValueRow(id, i, "row-" + i));
> }
> internalTable.upsertAll(rows, null).join();
> Tuple res = view.get(null, Tuple.create().set("key", id));
> assertEquals(lastId, res.intValue("valInt"));
> assertEquals("row-" + lastId, res.stringValue("valStr"));
> }
> {code}
> As a user, I expect to observe the last value for the given key. Instead,
> there is a random value.
> This is caused by *PartitionReplicaListener* - when there is no row with
> specified key, we generate a new random *RowId*:
> {code:java}
> RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
> {code}
> Then this row id is stored in a hash set, which results in a random update
> order. The same applies to the *DataStreamer*, which goes through
> *InternalTableImpl.updateAll*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21102) Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
[
https://issues.apache.org/jira/browse/IGNITE-21102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816893#comment-17816893
]
Maksim Timonin commented on IGNITE-21102:
-
[~oleg_vlsk] thanks for the patch! Merged to master
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
> -
>
> Key: IGNITE-21102
> URL: https://issues.apache.org/jira/browse/IGNITE-21102
> Project: Ignite
> Issue Type: Bug
>Reporter: Julia Bakulina
>Assignee: Oleg Valuyskiy
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline.
> org.apache.ignite.internal.commandline.BaselineCommand#baselinePrint0
> {code:java}
> logger.info("Cluster state: " + (res.isActive() ? "active" :
> "inactive"));
> {code}
> org.apache.ignite.cluster.ClusterState#ACTIVE_READ_ONLY
>
> An example of changing the cluster state:
> {code:java}
> Command [SET-STATE] started
> Arguments: ... --set-state ACTIVE_READ_ONLY
>
> Cluster state changed to ACTIVE_READ_ONLY
> Command [SET-STATE] finished with code: 0 {code}
> Cluster state in control.sh --baseline
> {code:java}
> Command [BASELINE] started
> Arguments: ... --baseline
>
> Cluster state: active
> Current topology version: 1
> Baseline auto adjustment disabled:...
> Current topology version: 1 (...)
> Baseline nodes:
> ...
>
> Number of baseline nodes: 1
> Other nodes not found.
> Command [BASELINE] finished with code: 0 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21102) Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
[
https://issues.apache.org/jira/browse/IGNITE-21102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-21102:
Fix Version/s: 2.17
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
> -
>
> Key: IGNITE-21102
> URL: https://issues.apache.org/jira/browse/IGNITE-21102
> Project: Ignite
> Issue Type: Bug
>Reporter: Julia Bakulina
>Assignee: Oleg Valuyskiy
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline.
> org.apache.ignite.internal.commandline.BaselineCommand#baselinePrint0
> {code:java}
> logger.info("Cluster state: " + (res.isActive() ? "active" :
> "inactive"));
> {code}
> org.apache.ignite.cluster.ClusterState#ACTIVE_READ_ONLY
>
> An example of changing the cluster state:
> {code:java}
> Command [SET-STATE] started
> Arguments: ... --set-state ACTIVE_READ_ONLY
>
> Cluster state changed to ACTIVE_READ_ONLY
> Command [SET-STATE] finished with code: 0 {code}
> Cluster state in control.sh --baseline
> {code:java}
> Command [BASELINE] started
> Arguments: ... --baseline
>
> Cluster state: active
> Current topology version: 1
> Baseline auto adjustment disabled:...
> Current topology version: 1 (...)
> Baseline nodes:
> ...
>
> Number of baseline nodes: 1
> Other nodes not found.
> Command [BASELINE] finished with code: 0 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21521) Wrong update order in upsertAll and DataStreamer for a new key
[
https://issues.apache.org/jira/browse/IGNITE-21521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21521:
Description:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
As a user, I expect to observe the last value for the given key. Instead, there
is a random value.
This is caused by *PartitionReplicaListener* - when there is no row with
specified key, we generate a new random *RowId*:
{code:java}
RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
{code}
Then this row id is stored in a hash set, which results in a random update
order. The same applies to the *DataStreamer*, which goes through
*InternalTableImpl.updateAll*.
was:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
As a user, I expect the last value for the given key to be applied. Instead, a
random value will be used.
This is caused by *PartitionReplicaListener* - when there is no row with
specified key, we generate a new random *RowId*:
{code:java}
RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
{code}
Then this row id is stored in a hash set, which results in a random update
order. The same applies to the *DataStreamer*, which goes through
*InternalTableImpl.updateAll*.
> Wrong update order in upsertAll and DataStreamer for a new key
> --
>
> Key: IGNITE-21521
> URL: https://issues.apache.org/jira/browse/IGNITE-21521
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *ItInternalTableTest* to reproduce:
> {code:java}
> @Test
> public void upsertAllOrderTest() {
> RecordView view = table.recordView();
> InternalTable internalTable = ((TableViewInternal)
> table).internalTable();
> List rows = new ArrayList<>();
> int count = 100;
> int lastId = count - 1;
> long id = 12345;
> for (int i = 0; i < count; i++) {
> rows.add(createKeyValueRow(id, i, "row-" + i));
> }
> internalTable.upsertAll(rows, null).join();
> Tuple res = view.get(null, Tuple.create().set("key", id));
> assertEquals(lastId, res.intValue("valInt"));
> assertEquals("row-" + lastId, res.stringValue("valStr"));
> }
> {code}
> As a user, I expect to observe the last value for the given key. Instead,
> there is a random value.
> This is caused by *PartitionReplicaListener* - when there is no row with
> specified key, we generate a new random *RowId*:
> {code:java}
> RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
> {code}
> Then this row id is stored in a hash set, which results in a random update
> order. The same applies to the *DataStreamer*, which goes through
> *InternalTableImpl.updateAll*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21521) Wrong update order in upsertAll and DataStreamer for a new key
[
https://issues.apache.org/jira/browse/IGNITE-21521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21521:
Component/s: (was: streaming)
> Wrong update order in upsertAll and DataStreamer for a new key
> --
>
> Key: IGNITE-21521
> URL: https://issues.apache.org/jira/browse/IGNITE-21521
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *ItInternalTableTest* to reproduce:
> {code:java}
> @Test
> public void upsertAllOrderTest() {
> RecordView view = table.recordView();
> InternalTable internalTable = ((TableViewInternal)
> table).internalTable();
> List rows = new ArrayList<>();
> int count = 100;
> int lastId = count - 1;
> long id = 12345;
> for (int i = 0; i < count; i++) {
> rows.add(createKeyValueRow(id, i, "row-" + i));
> }
> internalTable.upsertAll(rows, null).join();
> Tuple res = view.get(null, Tuple.create().set("key", id));
> assertEquals(lastId, res.intValue("valInt"));
> assertEquals("row-" + lastId, res.stringValue("valStr"));
> }
> {code}
> As a user, I expect the last value for the given key to be applied. Instead,
> a random value will be used.
> This is caused by *PartitionReplicaListener* - when there is no row with
> specified key, we generate a new random *RowId*:
> {code:java}
> RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
> {code}
> Then this row id is stored in a hash set, which results in a random update
> order. The same applies to the *DataStreamer*, which goes through
> *InternalTableImpl.updateAll*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21521) Wrong update order in upsertAll and DataStreamer for a new key
[
https://issues.apache.org/jira/browse/IGNITE-21521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21521:
Description:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
As a user, I expect the last value for the given key to be applied. Instead, a
random value will be used.
This is caused by *PartitionReplicaListener* - when there is no row with
specified key, we generate a new random *RowId*:
{code:java}
RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
{code}
Then this row id is stored in a hash set, which results in a random update
order. The same applies to the *DataStreamer*, which goes through
*InternalTableImpl.updateAll*.
was:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
As a user, I expect the last value for the given key to be applied. Instead, a
random value will be used.
This is caused by *PartitionReplicaListener* - when there is no row with
specified key, we generate a new random *RowId*:
{code:java}
RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
{code}
Then this row id is stored in a hash set, which results in a random update
order.
> Wrong update order in upsertAll and DataStreamer for a new key
> --
>
> Key: IGNITE-21521
> URL: https://issues.apache.org/jira/browse/IGNITE-21521
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *ItInternalTableTest* to reproduce:
> {code:java}
> @Test
> public void upsertAllOrderTest() {
> RecordView view = table.recordView();
> InternalTable internalTable = ((TableViewInternal)
> table).internalTable();
> List rows = new ArrayList<>();
> int count = 100;
> int lastId = count - 1;
> long id = 12345;
> for (int i = 0; i < count; i++) {
> rows.add(createKeyValueRow(id, i, "row-" + i));
> }
> internalTable.upsertAll(rows, null).join();
> Tuple res = view.get(null, Tuple.create().set("key", id));
> assertEquals(lastId, res.intValue("valInt"));
> assertEquals("row-" + lastId, res.stringValue("valStr"));
> }
> {code}
> As a user, I expect the last value for the given key to be applied. Instead,
> a random value will be used.
> This is caused by *PartitionReplicaListener* - when there is no row with
> specified key, we generate a new random *RowId*:
> {code:java}
> RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
> {code}
> Then this row id is stored in a hash set, which results in a random update
> order. The same applies to the *DataStreamer*, which goes through
> *InternalTableImpl.updateAll*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21521) Wrong update order in upsertAll and DataStreamer for a new key
[
https://issues.apache.org/jira/browse/IGNITE-21521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21521:
Description:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
As a user, I expect the last value for the given key to be applied. Instead, a
random value will be used.
This is caused by *PartitionReplicaListener* - when there is no row with
specified key, we generate a new random *RowId*:
{code:java}
RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
{code}
Then this row id is stored in a hash set, which results in a random update
order.
was:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
As a user, I expect the last value for the given key to be applied. Instead, a
random value will be used.
This is caused by *PartitionReplicaListener* - when there is no row with
specified key, we generate a new random *RowId*:
{code:java}
RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
{code}
> Wrong update order in upsertAll and DataStreamer for a new key
> --
>
> Key: IGNITE-21521
> URL: https://issues.apache.org/jira/browse/IGNITE-21521
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *ItInternalTableTest* to reproduce:
> {code:java}
> @Test
> public void upsertAllOrderTest() {
> RecordView view = table.recordView();
> InternalTable internalTable = ((TableViewInternal)
> table).internalTable();
> List rows = new ArrayList<>();
> int count = 100;
> int lastId = count - 1;
> long id = 12345;
> for (int i = 0; i < count; i++) {
> rows.add(createKeyValueRow(id, i, "row-" + i));
> }
> internalTable.upsertAll(rows, null).join();
> Tuple res = view.get(null, Tuple.create().set("key", id));
> assertEquals(lastId, res.intValue("valInt"));
> assertEquals("row-" + lastId, res.stringValue("valStr"));
> }
> {code}
> As a user, I expect the last value for the given key to be applied. Instead,
> a random value will be used.
> This is caused by *PartitionReplicaListener* - when there is no row with
> specified key, we generate a new random *RowId*:
> {code:java}
> RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
> {code}
> Then this row id is stored in a hash set, which results in a random update
> order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21521) Wrong update order in upsertAll and DataStreamer for a new key
[
https://issues.apache.org/jira/browse/IGNITE-21521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21521:
Description:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
As a user, I expect the last value for the given key to be applied. Instead, a
random value will be used.
This is caused by *PartitionReplicaListener* - when there is no row with
specified key, we generate a new random *RowId*:
{code:java}
RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
{code}
was:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
As a user, I expect the last value for the given key to be applied. Instead, a
random value will be used.
This is caused in *PartitionReplicaListener* - when there is no row with
specified key, we generate a new random *RowId*:
{code:java}
RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
{code}
> Wrong update order in upsertAll and DataStreamer for a new key
> --
>
> Key: IGNITE-21521
> URL: https://issues.apache.org/jira/browse/IGNITE-21521
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *ItInternalTableTest* to reproduce:
> {code:java}
> @Test
> public void upsertAllOrderTest() {
> RecordView view = table.recordView();
> InternalTable internalTable = ((TableViewInternal)
> table).internalTable();
> List rows = new ArrayList<>();
> int count = 100;
> int lastId = count - 1;
> long id = 12345;
> for (int i = 0; i < count; i++) {
> rows.add(createKeyValueRow(id, i, "row-" + i));
> }
> internalTable.upsertAll(rows, null).join();
> Tuple res = view.get(null, Tuple.create().set("key", id));
> assertEquals(lastId, res.intValue("valInt"));
> assertEquals("row-" + lastId, res.stringValue("valStr"));
> }
> {code}
> As a user, I expect the last value for the given key to be applied. Instead,
> a random value will be used.
> This is caused by *PartitionReplicaListener* - when there is no row with
> specified key, we generate a new random *RowId*:
> {code:java}
> RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21521) Wrong update order in upsertAll and DataStreamer for a new key
[
https://issues.apache.org/jira/browse/IGNITE-21521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21521:
Description:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
As a user, I expect the last value for the given key to be applied. Instead, a
random value will be used.
This is caused in *PartitionReplicaListener* - when there is no row with
specified key, we generate a new random *RowId*:
{code:java}
RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
{code}
was:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
> Wrong update order in upsertAll and DataStreamer for a new key
> --
>
> Key: IGNITE-21521
> URL: https://issues.apache.org/jira/browse/IGNITE-21521
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *ItInternalTableTest* to reproduce:
> {code:java}
> @Test
> public void upsertAllOrderTest() {
> RecordView view = table.recordView();
> InternalTable internalTable = ((TableViewInternal)
> table).internalTable();
> List rows = new ArrayList<>();
> int count = 100;
> int lastId = count - 1;
> long id = 12345;
> for (int i = 0; i < count; i++) {
> rows.add(createKeyValueRow(id, i, "row-" + i));
> }
> internalTable.upsertAll(rows, null).join();
> Tuple res = view.get(null, Tuple.create().set("key", id));
> assertEquals(lastId, res.intValue("valInt"));
> assertEquals("row-" + lastId, res.stringValue("valStr"));
> }
> {code}
> As a user, I expect the last value for the given key to be applied. Instead,
> a random value will be used.
> This is caused in *PartitionReplicaListener* - when there is no row with
> specified key, we generate a new random *RowId*:
> {code:java}
> RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21521) Wrong update order in upsertAll and DataStreamer for a new key
[
https://issues.apache.org/jira/browse/IGNITE-21521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21521:
Description:
Add the following test to *ItInternalTableTest* to reproduce:
{code:java}
@Test
public void upsertAllOrderTest() {
RecordView view = table.recordView();
InternalTable internalTable = ((TableViewInternal)
table).internalTable();
List rows = new ArrayList<>();
int count = 100;
int lastId = count - 1;
long id = 12345;
for (int i = 0; i < count; i++) {
rows.add(createKeyValueRow(id, i, "row-" + i));
}
internalTable.upsertAll(rows, null).join();
Tuple res = view.get(null, Tuple.create().set("key", id));
assertEquals(lastId, res.intValue("valInt"));
assertEquals("row-" + lastId, res.stringValue("valStr"));
}
{code}
> Wrong update order in upsertAll and DataStreamer for a new key
> --
>
> Key: IGNITE-21521
> URL: https://issues.apache.org/jira/browse/IGNITE-21521
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *ItInternalTableTest* to reproduce:
> {code:java}
> @Test
> public void upsertAllOrderTest() {
> RecordView view = table.recordView();
> InternalTable internalTable = ((TableViewInternal)
> table).internalTable();
> List rows = new ArrayList<>();
> int count = 100;
> int lastId = count - 1;
> long id = 12345;
> for (int i = 0; i < count; i++) {
> rows.add(createKeyValueRow(id, i, "row-" + i));
> }
> internalTable.upsertAll(rows, null).join();
> Tuple res = view.get(null, Tuple.create().set("key", id));
> assertEquals(lastId, res.intValue("valInt"));
> assertEquals("row-" + lastId, res.stringValue("valStr"));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21513) ActiveActorTest#testChangeLeaderForce is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21513:
-
Epic Link: IGNITE-21389
> ActiveActorTest#testChangeLeaderForce is flaky
> --
>
> Key: IGNITE-21513
> URL: https://issues.apache.org/jira/browse/IGNITE-21513
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [05:19:12]F:
> [org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
>
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370){code}
> See IGNITE-21381 for more details. This ticket is about fixing flaky test and
> removing the code duplication between ActiveActorTest and
> TopologyAwareRaftGroupServiceTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21521) Wrong update order in upsertAll and DataStreamer for a new key
[ https://issues.apache.org/jira/browse/IGNITE-21521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21521: Summary: Wrong update order in upsertAll and DataStreamer for a new key (was: Wrong update order in DataStreamer for a new key) > Wrong update order in upsertAll and DataStreamer for a new key > -- > > Key: IGNITE-21521 > URL: https://issues.apache.org/jira/browse/IGNITE-21521 > Project: Ignite > Issue Type: Bug > Components: streaming >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
