[jira] [Updated] (IGNITE-19792) Support @Immutable logic for distributed configuration
[
https://issues.apache.org/jira/browse/IGNITE-19792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-19792:
---
Epic Link: IGNITE-19280
> Support @Immutable logic for distributed configuration
> --
>
> Key: IGNITE-19792
> URL: https://issues.apache.org/jira/browse/IGNITE-19792
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> For distributed properties, the following scenario makes sense:
> # Property value might be set on cluster init
> # If it is provided, it overrides the default; otherwise, the default (set
> in the {{@Value}} annotation) is used
> # Any attempt to modify the property value using a changer is rejected by a
> validator
> {{@Immutable}} annotation is designed to trigger such behavior.
> Now, the observed behavior is different: if a property is annotated as
> {{{}@Immutable{}}}, then, if a value is supplied during cluster
> initialization, the value is silently ignored, so it is impossible to
> configure such property to anything different from the default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18622) Packaging: Zip with sources for C++ client and ODBC
[ https://issues.apache.org/jira/browse/IGNITE-18622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-18622: - Description: A plain and simple zip archive with sources is still very popular way to download and use C++ libraries. We should probably make a gradle build step that will generate a package with C++ client source code. Basically, everything from modules/platforms/cpp should go to this package. was:A plain and simple zip archive with sources is still very popular way to download and use C++ libraries. We should probably make a gradle build step that will generate a package with C++ client source code. > Packaging: Zip with sources for C++ client and ODBC > --- > > Key: IGNITE-18622 > URL: https://issues.apache.org/jira/browse/IGNITE-18622 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > > A plain and simple zip archive with sources is still very popular way to > download and use C++ libraries. We should probably make a gradle build step > that will generate a package with C++ client source code. > Basically, everything from modules/platforms/cpp should go to this package. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18622) Packaging: Zip with sources for C++ client and ODBC
[ https://issues.apache.org/jira/browse/IGNITE-18622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-18622: - Summary: Packaging: Zip with sources for C++ client and ODBC (was: Packaging: Zip with sources for C++ client) > Packaging: Zip with sources for C++ client and ODBC > --- > > Key: IGNITE-18622 > URL: https://issues.apache.org/jira/browse/IGNITE-18622 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > > A plain and simple zip archive with sources is still very popular way to > download and use C++ libraries. We should probably make a gradle build step > that will generate a package with C++ client source code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-19691) Drop column ignore "if exists" clause
[
https://issues.apache.org/jira/browse/IGNITE-19691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak closed IGNITE-19691.
-
> Drop column ignore "if exists" clause
> -
>
> Key: IGNITE-19691
> URL: https://issues.apache.org/jira/browse/IGNITE-19691
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
> Environment: AI3, commit id 612f08f6 on 08.06.2023 at 15:01
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> Scenario:
> 1) create table
> 2) drop some columns
> 3) drop same columns with "if exists"
> Expected results: execute without errors;
> Actual results: last ddl instruction return SQLException
>
> {noformat}
> create table tA(v0 INTEGER, c2 INTEGER, v1 INTEGER, c1 INTEGER not null,
> primary key (c1, c2));
> alter table tA drop column (v0, v1);
> alter table tA drop column if exists (v0, v1);{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19691) Drop column ignore "if exists" clause
[
https://issues.apache.org/jira/browse/IGNITE-19691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742008#comment-17742008
]
Alexander Belyak commented on IGNITE-19691:
---
Now DDL script:
{code:java}
create table test(id int primary key, val int);
alter table test drop column if exists val; {code}
returns expected error:
{noformat}
[Code: 0, SQL State: 5] Exception while executing query [query=alter table
test drop column if exists val]. Error message:Failed to parse query:
Encountered "" at line 1, column 30.
Was expecting one of:
{noformat}
> Drop column ignore "if exists" clause
> -
>
> Key: IGNITE-19691
> URL: https://issues.apache.org/jira/browse/IGNITE-19691
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
> Environment: AI3, commit id 612f08f6 on 08.06.2023 at 15:01
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> Scenario:
> 1) create table
> 2) drop some columns
> 3) drop same columns with "if exists"
> Expected results: execute without errors;
> Actual results: last ddl instruction return SQLException
>
> {noformat}
> create table tA(v0 INTEGER, c2 INTEGER, v1 INTEGER, c1 INTEGER not null,
> primary key (c1, c2));
> alter table tA drop column (v0, v1);
> alter table tA drop column if exists (v0, v1);{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-19691) Drop column ignore "if exists" clause
[
https://issues.apache.org/jira/browse/IGNITE-19691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak resolved IGNITE-19691.
---
Resolution: Won't Fix
> Drop column ignore "if exists" clause
> -
>
> Key: IGNITE-19691
> URL: https://issues.apache.org/jira/browse/IGNITE-19691
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
> Environment: AI3, commit id 612f08f6 on 08.06.2023 at 15:01
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> Scenario:
> 1) create table
> 2) drop some columns
> 3) drop same columns with "if exists"
> Expected results: execute without errors;
> Actual results: last ddl instruction return SQLException
>
> {noformat}
> create table tA(v0 INTEGER, c2 INTEGER, v1 INTEGER, c1 INTEGER not null,
> primary key (c1, c2));
> alter table tA drop column (v0, v1);
> alter table tA drop column if exists (v0, v1);{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19957) ODBC 3.0: Refactor ODBC client to re-use protocol-related code from client
Igor Sapego created IGNITE-19957: Summary: ODBC 3.0: Refactor ODBC client to re-use protocol-related code from client Key: IGNITE-19957 URL: https://issues.apache.org/jira/browse/IGNITE-19957 Project: Ignite Issue Type: Improvement Components: odbc Reporter: Igor Sapego Assignee: Igor Sapego ODBC and C++ client use the same protocol for SQL operations. Currently this code is partially duplicated in each of these components. Let's pull it to protocol library and re-use in both of them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19935) Allow combining individual colocation hashes
[
https://issues.apache.org/jira/browse/IGNITE-19935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741998#comment-17741998
]
Pavel Tupitsyn commented on IGNITE-19935:
-
Merged to main: 8303cc4f022451e932f65a2c6172112895cc1ce3
> Allow combining individual colocation hashes
>
>
> Key: IGNITE-19935
> URL: https://issues.apache.org/jira/browse/IGNITE-19935
> Project: Ignite
> Issue Type: Improvement
>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: 50m
> Remaining Estimate: 0h
>
> A hash of two columns currently is
> {code}
> var coloHash = hash(col1, hash(col2, 0));
> {code}
> which means we need to access the *value of col1* after we compute the *hash
> of col2*. In other words, there is no way to calculate individual column
> hashes and combine them later.
> In practice this means we can't combine serialization and hashing when
> colocation column order is different from serialization order. As a result,
> we have to do the same work twice:
> 1. Extract colocation column values (from tuple or POJO) and compute hash
> 2. Extract all column values (from tuple or POJO) and serialize
> This is especially problematic for String, BigInteger and BitMask where we
> have to allocate an array and copy some bytes there.
> *Solution*
> Provide a way to combine hashes:
> {code}
> var coloHash = hashCombine(hash(col2), hash(col1))
> {code}
> This will allow computing individual column hashes and combining them later
> in any order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19956) Change units arg type in compute execute
Mikhail Pochatkin created IGNITE-19956: -- Summary: Change units arg type in compute execute Key: IGNITE-19956 URL: https://issues.apache.org/jira/browse/IGNITE-19956 Project: Ignite Issue Type: Improvement Environment: Currently we have List arg in execute methods of org.apache.ignite.internal.compute.ComputeComponent. By design it should be array, not list. Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19955) Fix create zone on restart rewrites existing data nodes
Mirza Aliev created IGNITE-19955:
Summary: Fix create zone on restart rewrites existing data nodes
Key: IGNITE-19955
URL: https://issues.apache.org/jira/browse/IGNITE-19955
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
Currently we have the logic for initialisation of newly created zone that it
writes keys
{noformat}
zoneDataNodesKey(zoneId), zoneScaleUpChangeTriggerKey(zoneId),
zoneScaleDownChangeTriggerKey(zoneId), zonesChangeTriggerKey(zoneId)
{noformat}
to metastorage, and condition is
{noformat}
static CompoundCondition triggerKeyConditionForZonesChanges(long revision,
int zoneId) {
return or(
notExists(zonesChangeTriggerKey(zoneId)),
value(zonesChangeTriggerKey(zoneId)).lt(ByteUtils.longToBytes(revision))
);
{noformat}
Recovery process implies that the create zone event will be processed again,
but with the higher revision, so data nodes will be rewritten.
We need to handle this situation, so data nodes will be consistent after
restart.
Possible solution is to change condition to
{noformat}
static SimpleCondition triggerKeyConditionForZonesCreation(long revision,
int zoneId) {
return notExists(zonesChangeTriggerKey(zoneId));
}
static SimpleCondition triggerKeyConditionForZonesDelete(int zoneId) {
return exists(zonesChangeTriggerKey(zoneId));
}
{noformat}
so we could not rely on revision and check only existence of the key, when we
create or remove zone. The problem in this solution is that reordering of the
create and remove on some node could lead to not consistent state for zones key
in metastorage
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19954) .NET: Thin 3.0: TestAutoFlushFrequency is flaky
[
https://issues.apache.org/jira/browse/IGNITE-19954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-19954:
Description:
*TestAutoFlushFrequency* fails due to a known issue with false tx conflicts
(IGNITE-19824). We should either add a try-catch, or use a read-only tx to read
the data while it is being written.
* Add a TODO with a link to IGNITE-19824 to the workaround
https://ci.ignite.apache.org/test/4035794459336688174?currentProjectId=ApacheIgnite3xGradle_Test=true
{code}
Apache.Ignite.Tx.TransactionException : Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
> Apache.Ignite.IgniteException :
org.apache.ignite.tx.TransactionException: IGN-TX-4
TraceId:9c789d86-f595-4389-8988-448ea0247644 Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
at
org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:349)
at
org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:435)
at
org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:349)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.wrapReplicationException(InternalTableImpl.java:1557)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$postEnlist$9(InternalTableImpl.java:498)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlistWithRetry$5(InternalTableImpl.java:477)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.replicator.ReplicaService.lambda$sendToReplica$3(ReplicaService.java:174)
at
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: org.apache.ignite.internal.tx.LockException: IGN-TX-4
TraceId:9c789d86-f595-4389-8988-448ea0247644 Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.lockException(HeapLockManager.java:303)
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.isWaiterReadyToNotify(HeapLockManager.java:281)
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.tryAcquire(HeapLockManager.java:230)
at
org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:95)
at
org.apache.ignite.internal.table.distributed.HashIndexLocker.locksForLookup(HashIndexLocker.java:67)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.resolveRowByPk(PartitionReplicaListener.java:1280)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processSingleEntryAction(PartitionReplicaListener.java:1777)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$1(PartitionReplicaListener.java:329)
at
[jira] [Updated] (IGNITE-19954) .NET: Thin 3.0: TestAutoFlushFrequency is flaky
[
https://issues.apache.org/jira/browse/IGNITE-19954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-19954:
Description:
*TestAutoFlushFrequency* fails due to a known issue with false tx conflicts. We
should either add a try-catch, or use a read-only tx to read the data while it
is being written.
TBD: link to the related tx ticket.
https://ci.ignite.apache.org/test/4035794459336688174?currentProjectId=ApacheIgnite3xGradle_Test=true
{code}
Apache.Ignite.Tx.TransactionException : Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
> Apache.Ignite.IgniteException :
org.apache.ignite.tx.TransactionException: IGN-TX-4
TraceId:9c789d86-f595-4389-8988-448ea0247644 Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
at
org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:349)
at
org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:435)
at
org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:349)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.wrapReplicationException(InternalTableImpl.java:1557)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$postEnlist$9(InternalTableImpl.java:498)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlistWithRetry$5(InternalTableImpl.java:477)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.replicator.ReplicaService.lambda$sendToReplica$3(ReplicaService.java:174)
at
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: org.apache.ignite.internal.tx.LockException: IGN-TX-4
TraceId:9c789d86-f595-4389-8988-448ea0247644 Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.lockException(HeapLockManager.java:303)
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.isWaiterReadyToNotify(HeapLockManager.java:281)
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.tryAcquire(HeapLockManager.java:230)
at
org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:95)
at
org.apache.ignite.internal.table.distributed.HashIndexLocker.locksForLookup(HashIndexLocker.java:67)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.resolveRowByPk(PartitionReplicaListener.java:1280)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processSingleEntryAction(PartitionReplicaListener.java:1777)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$1(PartitionReplicaListener.java:329)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1353)
at
[jira] [Updated] (IGNITE-19954) .NET: Thin 3.0: TestAutoFlushFrequency is flaky
[
https://issues.apache.org/jira/browse/IGNITE-19954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-19954:
Description:
{code}
Apache.Ignite.Tx.TransactionException : Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
> Apache.Ignite.IgniteException :
org.apache.ignite.tx.TransactionException: IGN-TX-4
TraceId:9c789d86-f595-4389-8988-448ea0247644 Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
at
org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:349)
at
org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:435)
at
org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:349)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.wrapReplicationException(InternalTableImpl.java:1557)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$postEnlist$9(InternalTableImpl.java:498)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlistWithRetry$5(InternalTableImpl.java:477)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.replicator.ReplicaService.lambda$sendToReplica$3(ReplicaService.java:174)
at
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: org.apache.ignite.internal.tx.LockException: IGN-TX-4
TraceId:9c789d86-f595-4389-8988-448ea0247644 Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.lockException(HeapLockManager.java:303)
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.isWaiterReadyToNotify(HeapLockManager.java:281)
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.tryAcquire(HeapLockManager.java:230)
at
org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:95)
at
org.apache.ignite.internal.table.distributed.HashIndexLocker.locksForLookup(HashIndexLocker.java:67)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.resolveRowByPk(PartitionReplicaListener.java:1280)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processSingleEntryAction(PartitionReplicaListener.java:1777)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$1(PartitionReplicaListener.java:329)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1353)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processRequest(PartitionReplicaListener.java:329)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$invoke$0(PartitionReplicaListener.java:322)
at
[jira] [Updated] (IGNITE-19954) .NET: Thin 3.0: TestAutoFlushFrequency is flaky
[
https://issues.apache.org/jira/browse/IGNITE-19954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-19954:
Description:
https://ci.ignite.apache.org/test/4035794459336688174?currentProjectId=ApacheIgnite3xGradle_Test=true
{code}
Apache.Ignite.Tx.TransactionException : Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
> Apache.Ignite.IgniteException :
org.apache.ignite.tx.TransactionException: IGN-TX-4
TraceId:9c789d86-f595-4389-8988-448ea0247644 Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
at
org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:349)
at
org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:435)
at
org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:349)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.wrapReplicationException(InternalTableImpl.java:1557)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$postEnlist$9(InternalTableImpl.java:498)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlistWithRetry$5(InternalTableImpl.java:477)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.replicator.ReplicaService.lambda$sendToReplica$3(ReplicaService.java:174)
at
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: org.apache.ignite.internal.tx.LockException: IGN-TX-4
TraceId:9c789d86-f595-4389-8988-448ea0247644 Failed to acquire a lock due to a
conflict [txId=018937f6-e9e1---03b84e72,
conflictingWaiter=WaiterImpl [txId=018937f6-e9ab---03b84e72,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.lockException(HeapLockManager.java:303)
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.isWaiterReadyToNotify(HeapLockManager.java:281)
at
org.apache.ignite.internal.tx.impl.HeapLockManager$LockState.tryAcquire(HeapLockManager.java:230)
at
org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:95)
at
org.apache.ignite.internal.table.distributed.HashIndexLocker.locksForLookup(HashIndexLocker.java:67)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.resolveRowByPk(PartitionReplicaListener.java:1280)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processSingleEntryAction(PartitionReplicaListener.java:1777)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$1(PartitionReplicaListener.java:329)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1353)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processRequest(PartitionReplicaListener.java:329)
at
[jira] [Created] (IGNITE-19954) .NET: Thin 3.0: TestAutoFlushFrequency is flaky
Pavel Tupitsyn created IGNITE-19954: --- Summary: .NET: Thin 3.0: TestAutoFlushFrequency is flaky Key: IGNITE-19954 URL: https://issues.apache.org/jira/browse/IGNITE-19954 Project: Ignite Issue Type: Bug Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19933) RebalanceRaftGroupEventsListener#doOnNewPeersConfigurationApplied must be ready for the empry stale partition assignments
[ https://issues.apache.org/jira/browse/IGNITE-19933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19933: - Labels: ignite-3 (was: ) > RebalanceRaftGroupEventsListener#doOnNewPeersConfigurationApplied must be > ready for the empry stale partition assignments > - > > Key: IGNITE-19933 > URL: https://issues.apache.org/jira/browse/IGNITE-19933 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > In the nearest future we will clean the assignments.stable.* keys on the > table drop (under the IGNITE-18959). But at the same time we can finish the > rebalance a moment after that and try to receive the stable assignment inside > the RebalanceRaftGroupEventsListener#doOnNewPeersConfigurationApplied(...) > and then update them (but we don't want to write it for dropped table) > *Definition of done* > - doOnNewPeersConfigurationApplied stopped as soon as it received the empty > stable assignments -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19931) Sql. Varbinary. Index is not selected for key = '1'::VARBINARY
[
https://issues.apache.org/jira/browse/IGNITE-19931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-19931:
-
Labels: ignite-3 (was: )
> Sql. Varbinary. Index is not selected for key = '1'::VARBINARY
> --
>
> Key: IGNITE-19931
> URL: https://issues.apache.org/jira/browse/IGNITE-19931
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Index is not selected for the following query:
> {code:java}
> @Test
> public void test1() {
> sql("CREATE TABLE t_test (key VARBINARY PRIMARY KEY, val INTEGER)");
> assertQuery("SELECT * FROM t_test WHERE key = '1'::VARBINARY")
> .matches(containsIndexScan("PUBLIC", "T_TEST", "T_TEST_PK"))
> .check();
> }
> {code}
> *Actual result*:
> {code:java}
> java.lang.AssertionError: Invalid plan:
> IgniteExchange(distribution=[single]): rowcount = 1500.0, cumulative cost =
> IgniteCost [rowCount=11500.0, cpu=41500.0, memory=0.0, io=0.0,
> network=12000.0], id = 28
> IgniteTableScan(table=[[PUBLIC, T_TEST]], tableId=[3],
> filters=[=(CAST($t0):VARBINARY NOT NULL, X'31')], requiredColumns=[{0, 1}]):
> rowcount = 1500.0, cumulative cost = IgniteCost [rowCount=1.0,
> cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 25
> Expected: a string contains once ".*IgniteIndexScan\\(table=\\[\\[PUBLIC,
> T_TEST\\]\\], tableId=\\[.*\\], index=\\[T_TEST_PK\\].*\\)"
> but: was "IgniteExchange(distribution=[single]): rowcount = 1500.0,
> cumulative cost = IgniteCost [rowCount=11500.0, cpu=41500.0, memory=0.0,
> io=0.0, network=12000.0], id = 28
> IgniteTableScan(table=[[PUBLIC, T_TEST]], tableId=[3],
> filters=[=(CAST($t0):VARBINARY NOT NULL, X'31')], requiredColumns=[{0, 1}]):
> rowcount = 1500.0, cumulative cost = IgniteCost [rowCount=1.0,
> cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 25
> "
> {code}
> Query with a HEX literal uses index.
> {code:java}
> @Test
> public void test2() {
> sql("CREATE TABLE t_test (key VARBINARY PRIMARY KEY, val INTEGER)");
> assertQuery("SELECT * FROM t_test WHERE key = X'31'")
> .matches(containsIndexScan("PUBLIC", "T_TEST", "T_TEST_PK"))
> .check();
> }
> {code}
> Query with redundant cast from a HEX literal to VARBINARY does not use index:
> {code:java}
> @Test
> public void test3() {
> sql("CREATE TABLE t_test (key VARBINARY PRIMARY KEY, val INTEGER)");
> assertQuery("SELECT * FROM t_test WHERE key = X'31'::VARBINARY")
> .matches(containsIndexScan("PUBLIC", "T_TEST", "T_TEST_PK"))
> .check();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19929) Direct safe time propagation
[ https://issues.apache.org/jira/browse/IGNITE-19929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19929: - Labels: ignite-3 (was: ) > Direct safe time propagation > > > Key: IGNITE-19929 > URL: https://issues.apache.org/jira/browse/IGNITE-19929 > Project: Ignite > Issue Type: Epic >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Safe time propagation works over replication layer. The process replicates > timestamp with high guaranties: clogging the replication log, takes time from > replication flow. Meanwhile, the reliability is not needed for safe time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19953) Ignite 3 CLI: --verbose twice does not work
Aleksandr created IGNITE-19953: -- Summary: Ignite 3 CLI: --verbose twice does not work Key: IGNITE-19953 URL: https://issues.apache.org/jira/browse/IGNITE-19953 Project: Ignite Issue Type: Bug Reporter: Aleksandr Attachments: Screenshot 2023-07-11 at 16.10.43.png Just call any command with --verbose twice in REPL mode. The first one prints HTTP trace, the second one no. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19923) ODBC 3.0: Document ODBC in Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-19923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19923: - Labels: ignite-3 (was: ) > ODBC 3.0: Document ODBC in Ignite 3 > --- > > Key: IGNITE-19923 > URL: https://issues.apache.org/jira/browse/IGNITE-19923 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19949) Completers don't work properly in case of when different completers have the same action option
[
https://issues.apache.org/jira/browse/IGNITE-19949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-19949:
---
Description:
Completers don't work when they have different commands but the same option
{code:java}
@Test
void sameOptionDifferentCompleters() {
// Given
registry.register(
CompleterConf.builder()
.command("command", "subcommand1")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer1
);
registry.register(
CompleterConf.builder()
.command("command", "subcommand2")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer2);
// Then
assertThat(registry.findCompleters(words("command", "subcommand1",
"--to")), containsInAnyOrder(completer1));
// And
assertThat(registry.findCompleters(words("command", "subcommand2",
"--to")), containsInAnyOrder(completer2));
} {code}
was:
Completers don't work when they have different commands but the same option
{code:java}
@Test
void sameOptionDifferentCompleters() {
// Given
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer1
);
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer2);
// Then
assertThat(registry.findCompleters(words("command", "subcommand", "--to")),
containsInAnyOrder(completer1));
// And
assertThat(registry.findCompleters(words("command", "subcommand", "--to")),
containsInAnyOrder(completer2));
} {code}
> Completers don't work properly in case of when different completers have the
> same action option
> ---
>
> Key: IGNITE-19949
> URL: https://issues.apache.org/jira/browse/IGNITE-19949
> Project: Ignite
> Issue Type: Bug
> Components: cli
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> Completers don't work when they have different commands but the same option
> {code:java}
> @Test
> void sameOptionDifferentCompleters() {
> // Given
> registry.register(
> CompleterConf.builder()
> .command("command", "subcommand1")
> .enableOptions("--to")
> .exclusiveEnableOptions().build(),
> words -> completer1
> );
> registry.register(
> CompleterConf.builder()
> .command("command", "subcommand2")
> .enableOptions("--to")
> .exclusiveEnableOptions().build(),
> words -> completer2);
> // Then
> assertThat(registry.findCompleters(words("command", "subcommand1",
> "--to")), containsInAnyOrder(completer1));
> // And
> assertThat(registry.findCompleters(words("command", "subcommand2",
> "--to")), containsInAnyOrder(completer2));
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19951) Get rid of @NotNull annotation
[
https://issues.apache.org/jira/browse/IGNITE-19951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-19951:
---
Summary: Get rid of @NotNull annotation (was: get rid of @NotNull
annotation)
> Get rid of @NotNull annotation
> --
>
> Key: IGNITE-19951
> URL: https://issues.apache.org/jira/browse/IGNITE-19951
> Project: Ignite
> Issue Type: Improvement
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> Despite our code guide style prohibit to use {{@NotNull}} annotation [1] we
> have many usage of the annotation in code.
> Even more, we have example [2] with {{@NotNull}} in code style guide. it
> could breaks mind.
> Let's do the next:
> 1) fix example in code style guide
> 2) get rid {{@NotNull}} in code base.
> 3) add automation checksyle check to avoid appearance new usage of the
> anntation.
> [1] [ -
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2.1Commonannotatingrules|https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2.1Commonannotatingrules]
> [2] -
> [https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-4.1Allasyncmethodsshouldhaveasyncsuffix]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19952) Update Mockito version
[ https://issues.apache.org/jira/browse/IGNITE-19952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-19952: - Ignite Flags: (was: Docs Required,Release Notes Required) > Update Mockito version > -- > > Key: IGNITE-19952 > URL: https://issues.apache.org/jira/browse/IGNITE-19952 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Blocker > > When running tests locally using Java 17, some of them fail with NPEs in > Mockito subs. Bumping Mockito version solves this issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19952) Update Mockito version
Aleksandr Polovtcev created IGNITE-19952: Summary: Update Mockito version Key: IGNITE-19952 URL: https://issues.apache.org/jira/browse/IGNITE-19952 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev When running tests locally using Java 17, some of them fail with NPEs in Mockito subs. Bumping Mockito version solves this issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19952) Update Mockito version
[ https://issues.apache.org/jira/browse/IGNITE-19952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-19952: - Labels: ignite-3 (was: ) > Update Mockito version > -- > > Key: IGNITE-19952 > URL: https://issues.apache.org/jira/browse/IGNITE-19952 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When running tests locally using Java 17, some of them fail with NPEs in > Mockito subs. Bumping Mockito version solves this issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19952) Update Mockito version
[ https://issues.apache.org/jira/browse/IGNITE-19952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-19952: - Fix Version/s: 3.0.0-beta2 > Update Mockito version > -- > > Key: IGNITE-19952 > URL: https://issues.apache.org/jira/browse/IGNITE-19952 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Blocker > Fix For: 3.0.0-beta2 > > > When running tests locally using Java 17, some of them fail with NPEs in > Mockito subs. Bumping Mockito version solves this issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19951) get rid of @NotNull annotation
Yury Gerzhedovich created IGNITE-19951:
--
Summary: get rid of @NotNull annotation
Key: IGNITE-19951
URL: https://issues.apache.org/jira/browse/IGNITE-19951
Project: Ignite
Issue Type: Improvement
Reporter: Yury Gerzhedovich
Despite our code guide style prohibit to use {{@NotNull}} annotation [1] we
have many usage of the annotation in code.
Even more, we have example [2] with {{@NotNull}} in code style guide. it could
breaks mind.
Let's do the next:
1) fix example in code style guide
2) get rid {{@NotNull}} in code base.
3) add automation checksyle check to avoid appearance new usage of the
anntation.
[1] [ -
https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2.1Commonannotatingrules|https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2.1Commonannotatingrules]
[2] -
[https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-4.1Allasyncmethodsshouldhaveasyncsuffix]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19205) ODBC 3.0: Implement data buffers from Ignite 2 using Ignite 3 protocol
[ https://issues.apache.org/jira/browse/IGNITE-19205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741936#comment-17741936 ] Igor Sapego commented on IGNITE-19205: -- Thanks for the review. Answered questions. > ODBC 3.0: Implement data buffers from Ignite 2 using Ignite 3 protocol > -- > > Key: IGNITE-19205 > URL: https://issues.apache.org/jira/browse/IGNITE-19205 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > To be done: > - Return functionality to all classes from ignite/odbc/app, re-write them > using our new protocol; > - Port related tests from Ignite 2; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19941) Sql. Test ExecutionServiceImplTest.testCancelOnInitiator is flaky
[ https://issues.apache.org/jira/browse/IGNITE-19941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-19941: -- Fix Version/s: 3.0.0-beta2 > Sql. Test ExecutionServiceImplTest.testCancelOnInitiator is flaky > - > > Key: IGNITE-19941 > URL: https://issues.apache.org/jira/browse/IGNITE-19941 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Can be reproduced by repeated execution until failure -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19941) Sql. Test ExecutionServiceImplTest.testCancelOnInitiator is flaky
[ https://issues.apache.org/jira/browse/IGNITE-19941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-19941: - Assignee: Konstantin Orlov > Sql. Test ExecutionServiceImplTest.testCancelOnInitiator is flaky > - > > Key: IGNITE-19941 > URL: https://issues.apache.org/jira/browse/IGNITE-19941 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Can be reproduced by repeated execution until failure -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19205) ODBC 3.0: Implement data buffers from Ignite 2 using Ignite 3 protocol
[ https://issues.apache.org/jira/browse/IGNITE-19205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741935#comment-17741935 ] Pavel Tupitsyn commented on IGNITE-19205: - [~isapego] looks good to me. Please see a couple of minor comments on GitHub. > ODBC 3.0: Implement data buffers from Ignite 2 using Ignite 3 protocol > -- > > Key: IGNITE-19205 > URL: https://issues.apache.org/jira/browse/IGNITE-19205 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > To be done: > - Return functionality to all classes from ignite/odbc/app, re-write them > using our new protocol; > - Port related tests from Ignite 2; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19950) Snapshot of in-memory cache groups
[ https://issues.apache.org/jira/browse/IGNITE-19950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-19950: - Labels: iep-43 ise (was: iep-43) > Snapshot of in-memory cache groups > -- > > Key: IGNITE-19950 > URL: https://issues.apache.org/jira/browse/IGNITE-19950 > Project: Ignite > Issue Type: New Feature >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: iep-43, ise > > Ignite can create snapshot for persistent cache groups only. > It will be very usefull for a user to have ability to create and restore > snapshot of in-memory cache groups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19950) Snapshot of in-memory cache groups
[ https://issues.apache.org/jira/browse/IGNITE-19950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-19950: - Labels: iep-43 (was: ) > Snapshot of in-memory cache groups > -- > > Key: IGNITE-19950 > URL: https://issues.apache.org/jira/browse/IGNITE-19950 > Project: Ignite > Issue Type: New Feature >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: iep-43 > > Ignite can create snapshot for persistent cache groups only. > It will be very usefull for a user to have ability to create and restore > snapshot of in-memory cache groups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19950) Snapshot of in-memory cache groups
Nikolay Izhikov created IGNITE-19950: Summary: Snapshot of in-memory cache groups Key: IGNITE-19950 URL: https://issues.apache.org/jira/browse/IGNITE-19950 Project: Ignite Issue Type: New Feature Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Ignite can create snapshot for persistent cache groups only. It will be very usefull for a user to have ability to create and restore snapshot of in-memory cache groups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19949) Completers don't work properly in case of when different completers have the same action option
[
https://issues.apache.org/jira/browse/IGNITE-19949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-19949:
---
Description:
Completers don't work when they have different commands but the same option
{code:java}
@Test
void sameOptionDifferentCompleters() {
// Given
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer1
);
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer2);
// Then
assertThat(registry.findCompleters(words("command", "subcommand",
"--to")).var, containsInAnyOrder(completer1));
// And
assertThat(registry.findCompleters(words("command", "subcommand", "--to")),
containsInAnyOrder(completer2));
} {code}
was:
Completers don't work when they have different commands but the same option
{code:java}
@Test
void sameOptionDifferentCompleters() {
// Given
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer1
);
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer2);
// Then
assertThat(registry.findCompleters(words("user", "role", "assign",
"--to")).var, containsInAnyOrder(completer1));
// And
assertThat(registry.findCompleters(words("role", "privilege", "grant",
"--to")), containsInAnyOrder(completer2));
} {code}
> Completers don't work properly in case of when different completers have the
> same action option
> ---
>
> Key: IGNITE-19949
> URL: https://issues.apache.org/jira/browse/IGNITE-19949
> Project: Ignite
> Issue Type: Bug
> Components: cli
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> Completers don't work when they have different commands but the same option
> {code:java}
> @Test
> void sameOptionDifferentCompleters() {
> // Given
> registry.register(
> CompleterConf.builder()
> .command("command", "subcommand")
> .enableOptions("--to")
> .exclusiveEnableOptions().build(),
> words -> completer1
> );
> registry.register(
> CompleterConf.builder()
> .command("command", "subcommand")
> .enableOptions("--to")
> .exclusiveEnableOptions().build(),
> words -> completer2);
> // Then
> assertThat(registry.findCompleters(words("command", "subcommand",
> "--to")).var, containsInAnyOrder(completer1));
> // And
> assertThat(registry.findCompleters(words("command", "subcommand",
> "--to")), containsInAnyOrder(completer2));
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19949) Completers don't work properly in case of when different completers have the same action option
[
https://issues.apache.org/jira/browse/IGNITE-19949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-19949:
---
Description:
Completers don't work when they have different commands but the same option
{code:java}
@Test
void sameOptionDifferentCompleters() {
// Given
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer1
);
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer2);
// Then
assertThat(registry.findCompleters(words("command", "subcommand", "--to")),
containsInAnyOrder(completer1));
// And
assertThat(registry.findCompleters(words("command", "subcommand", "--to")),
containsInAnyOrder(completer2));
} {code}
was:
Completers don't work when they have different commands but the same option
{code:java}
@Test
void sameOptionDifferentCompleters() {
// Given
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer1
);
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer2);
// Then
assertThat(registry.findCompleters(words("command", "subcommand",
"--to")).var, containsInAnyOrder(completer1));
// And
assertThat(registry.findCompleters(words("command", "subcommand", "--to")),
containsInAnyOrder(completer2));
} {code}
> Completers don't work properly in case of when different completers have the
> same action option
> ---
>
> Key: IGNITE-19949
> URL: https://issues.apache.org/jira/browse/IGNITE-19949
> Project: Ignite
> Issue Type: Bug
> Components: cli
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> Completers don't work when they have different commands but the same option
> {code:java}
> @Test
> void sameOptionDifferentCompleters() {
> // Given
> registry.register(
> CompleterConf.builder()
> .command("command", "subcommand")
> .enableOptions("--to")
> .exclusiveEnableOptions().build(),
> words -> completer1
> );
> registry.register(
> CompleterConf.builder()
> .command("command", "subcommand")
> .enableOptions("--to")
> .exclusiveEnableOptions().build(),
> words -> completer2);
> // Then
> assertThat(registry.findCompleters(words("command", "subcommand",
> "--to")), containsInAnyOrder(completer1));
> // And
> assertThat(registry.findCompleters(words("command", "subcommand",
> "--to")), containsInAnyOrder(completer2));
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19949) Completers don't work properly in case of when different completers have the same action option
Ivan Gagarkin created IGNITE-19949:
--
Summary: Completers don't work properly in case of when different
completers have the same action option
Key: IGNITE-19949
URL: https://issues.apache.org/jira/browse/IGNITE-19949
Project: Ignite
Issue Type: Bug
Reporter: Ivan Gagarkin
Completers don't work when they have different commands but the same option
{code:java}
@Test
void sameOptionDifferentCompleters() {
// Given
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer1
);
registry.register(
CompleterConf.builder()
.command("command", "subcommand")
.enableOptions("--to")
.exclusiveEnableOptions().build(),
words -> completer2);
// Then
assertThat(registry.findCompleters(words("user", "role", "assign",
"--to")).var, containsInAnyOrder(completer1));
// And
assertThat(registry.findCompleters(words("role", "privilege", "grant",
"--to")), containsInAnyOrder(completer2));
} {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19949) Completers don't work properly in case of when different completers have the same action option
[
https://issues.apache.org/jira/browse/IGNITE-19949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-19949:
---
Component/s: cli
> Completers don't work properly in case of when different completers have the
> same action option
> ---
>
> Key: IGNITE-19949
> URL: https://issues.apache.org/jira/browse/IGNITE-19949
> Project: Ignite
> Issue Type: Bug
> Components: cli
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> Completers don't work when they have different commands but the same option
> {code:java}
> @Test
> void sameOptionDifferentCompleters() {
> // Given
> registry.register(
> CompleterConf.builder()
> .command("command", "subcommand")
> .enableOptions("--to")
> .exclusiveEnableOptions().build(),
> words -> completer1
> );
> registry.register(
> CompleterConf.builder()
> .command("command", "subcommand")
> .enableOptions("--to")
> .exclusiveEnableOptions().build(),
> words -> completer2);
> // Then
> assertThat(registry.findCompleters(words("user", "role", "assign",
> "--to")).var, containsInAnyOrder(completer1));
> // And
> assertThat(registry.findCompleters(words("role", "privilege", "grant",
> "--to")), containsInAnyOrder(completer2));
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19948) Add authenticated username to the prompt
Vadim Pakhnushev created IGNITE-19948:
-
Summary: Add authenticated username to the prompt
Key: IGNITE-19948
URL: https://issues.apache.org/jira/browse/IGNITE-19948
Project: Ignite
Issue Type: Improvement
Components: cli
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
When connecting to the cluster with basic authentication enabled, add
{{username:}} to the prompt.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19947) Sql. Fix CAST(n AS DECIMAL(precision, scale) behaviour for scale > precision.
Maksim Zhuravkov created IGNITE-19947: - Summary: Sql. Fix CAST(n AS DECIMAL(precision, scale) behaviour for scale > precision. Key: IGNITE-19947 URL: https://issues.apache.org/jira/browse/IGNITE-19947 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0.0-beta1 Reporter: Maksim Zhuravkov CAST(n AS DECIMAL(p, s) always returns `numeric field overflow` error when s > p which is not correct, in such case we should also check `n`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19946) Implement batch processing of Raft log entries
[ https://issues.apache.org/jira/browse/IGNITE-19946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-19946: -- Assignee: Ivan Bessonov > Implement batch processing of Raft log entries > -- > > Key: IGNITE-19946 > URL: https://issues.apache.org/jira/browse/IGNITE-19946 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > Issue is created as a part of IGNITE-15568. Here we need to implement batches > for the log specifically, so that there will be less IO while writing data > into a shared log storage. > Copy of the comment in that issue: > _The actual implementation here differs from the description._ > _First of all, only the log manager is affected._ > _Second, instead of having a single event that would notify all listeners, I > re-use the "endOfBatch" flag. This solution is not as general, and it can be > later re-implemented using additional event, but I decided not to change the > API too much for now._ > _Log manager internally has the information about the stripe it belongs to. > Using that information, it's possible to perform a single write into a shared > log storage, even when batch consists of data from several different > replication groups._ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[ https://issues.apache.org/jira/browse/IGNITE-15568 ]
Ivan Bessonov deleted comment on IGNITE-15568:
was (Author: ibessonov):
The actual implementation here differs from the description.
First of all, only the log manager is affected.
Second, instead of having a single event that would notify all listeners, I
re-use the "endOfBatch" flag. This solution is not as general, and it can be
later re-implemented using additional event, but I decided not to change the
API too much for now.
Log manager internally has the information about the stripe it belongs to.
Using that information, it's possible to perform a single write into a shared
log storage, even when batch consists of data from several different
replication groups.
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19946) Implement batch processing of Raft log entries
Ivan Bessonov created IGNITE-19946: -- Summary: Implement batch processing of Raft log entries Key: IGNITE-19946 URL: https://issues.apache.org/jira/browse/IGNITE-19946 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Issue is created as a part of IGNITE-15568. Here we need to implement batches for the log specifically, so that there will be less IO while writing data into a shared log storage. Copy of the comment in that issue: _The actual implementation here differs from the description._ _First of all, only the log manager is affected._ _Second, instead of having a single event that would notify all listeners, I re-use the "endOfBatch" flag. This solution is not as general, and it can be later re-implemented using additional event, but I decided not to change the API too much for now._ _Log manager internally has the information about the stripe it belongs to. Using that information, it's possible to perform a single write into a shared log storage, even when batch consists of data from several different replication groups._ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19945) Does ignite 2.8 expose rest api for topology/health parameters - Documentation for Ignite 2.8
Amit Maheshwari created IGNITE-19945: Summary: Does ignite 2.8 expose rest api for topology/health parameters - Documentation for Ignite 2.8 Key: IGNITE-19945 URL: https://issues.apache.org/jira/browse/IGNITE-19945 Project: Ignite Issue Type: Task Affects Versions: 2.8 Reporter: Amit Maheshwari First of all, excuse me if the type of this Jira ticket is improper. I need to create a query ticket. We are using ignite 2.8 and for monitoring purpose, we need to get topology metrics and/or parameters related to ignite health out of currently running ignite server. I could find a documentation for ignite [https://ignite.apache.org/docs/2.9.0/index] But it is starting from 2.9 and going upwards. I need to work on 2.8 version. Can you please let me know, * Does ignite 2.8 expose rest api for topology/health parameters and also, please provide me the link of documents (and examples if there may any) Please let me know if you need any further clarification or other information from my side. -- This message was sent by Atlassian Jira (v8.20.10#820010)
