[jira] [Updated] (IGNITE-20280) Lease updater exception is not logged on initialization
[
https://issues.apache.org/jira/browse/IGNITE-20280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20280:
---
Attachment: _Integration_Tests_Run_All_Other_13956.log
> Lease updater exception is not logged on initialization
> ---
>
> Key: IGNITE-20280
> URL: https://issues.apache.org/jira/browse/IGNITE-20280
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Run_All_Other_13956.log
>
>
> In the case in which the lease updater gets an exception on initialization
> ({{LeaseUpdater#init}}), the stake trace has never been logged. The exception
> is stored in {{PlacementDriverManager#raftClientFuture}}, but never texted to
> the log file.
> [Fail on
> TC|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_IntegrationTests_RunAllOther/7454760?hideProblemsFromDependencies=false=false=true=true=true]
> Look at the log for {{PlacementDriverManagerTest#testLeaseRestore}} (the full
> log file is attached) there are no lines:
> {noformat}
> [INFO ][Test worker][TopologyTracker] Logical topology initialized for
> placement driver [...]
> [INFO ][Test worker][AssignmentsTracker] Assignment cache initialized for
> placement driver [...]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20280) Lease updater exception is not logged on initialization
[
https://issues.apache.org/jira/browse/IGNITE-20280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20280:
---
Description:
In the case in which the lease updater gets an exception on initialization
({{LeaseUpdater#init}}), the stake trace has never been logged. The exception
is stored in {{PlacementDriverManager#raftClientFuture}}, but never texted to
the log file.
[Fail on
TC|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_IntegrationTests_RunAllOther/7454760?hideProblemsFromDependencies=false=false=true=true=true]
Look at the log for {{PlacementDriverManagerTest#testLeaseRestore}} (the full
log file is attached) there are no lines:
{noformat}
[INFO ][Test worker][TopologyTracker] Logical topology initialized for
placement driver [...]
[INFO ][Test worker][AssignmentsTracker] Assignment cache initialized for
placement driver [...]
{noformat}
was:
In the case in which the lease updater gets an exception on initialization
(LeaseUpdater#init), the stake trace has never been logged. The exception is
stored in PlacementDriverManager#raftClientFuture, but never texted to the log
file.
[Fail on
TC|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_IntegrationTests_RunAllOther/7454760?hideProblemsFromDependencies=false=false=true=true=true]
Look at the log for PlacementDriverManagerTest#testLeaseRestore (the full log
file is attached) there are no lines:
{noformat}
[INFO ][Test worker][TopologyTracker] Logical topology initialized for
placement driver [...]
[INFO ][Test worker][AssignmentsTracker] Assignment cache initialized for
placement driver [...]
{noformat}
> Lease updater exception is not logged on initialization
> ---
>
> Key: IGNITE-20280
> URL: https://issues.apache.org/jira/browse/IGNITE-20280
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Run_All_Other_13956.log
>
>
> In the case in which the lease updater gets an exception on initialization
> ({{LeaseUpdater#init}}), the stake trace has never been logged. The exception
> is stored in {{PlacementDriverManager#raftClientFuture}}, but never texted to
> the log file.
> [Fail on
> TC|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_IntegrationTests_RunAllOther/7454760?hideProblemsFromDependencies=false=false=true=true=true]
> Look at the log for {{PlacementDriverManagerTest#testLeaseRestore}} (the full
> log file is attached) there are no lines:
> {noformat}
> [INFO ][Test worker][TopologyTracker] Logical topology initialized for
> placement driver [...]
> [INFO ][Test worker][AssignmentsTracker] Assignment cache initialized for
> placement driver [...]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20280) Lease updater exception is not logged on initialization
Vladislav Pyatkov created IGNITE-20280:
--
Summary: Lease updater exception is not logged on initialization
Key: IGNITE-20280
URL: https://issues.apache.org/jira/browse/IGNITE-20280
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
In the case in which the lease updater gets an exception on initialization
(LeaseUpdater#init), the stake trace has never been logged. The exception is
stored in PlacementDriverManager#raftClientFuture, but never texted to the log
file.
[Fail on
TC|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_IntegrationTests_RunAllOther/7454760?hideProblemsFromDependencies=false=false=true=true=true]
Look at the log for PlacementDriverManagerTest#testLeaseRestore (the full log
file is attached) there are no lines:
{noformat}
[INFO ][Test worker][TopologyTracker] Logical topology initialized for
placement driver [...]
[INFO ][Test worker][AssignmentsTracker] Assignment cache initialized for
placement driver [...]
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20260) RaftGroupServiceImpl#readIndex() is broken
[
https://issues.apache.org/jira/browse/IGNITE-20260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20260:
-
Priority: Blocker (was: Major)
> RaftGroupServiceImpl#readIndex() is broken
> --
>
> Key: IGNITE-20260
> URL: https://issues.apache.org/jira/browse/IGNITE-20260
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Denis Chudov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> According to {{NodeImpl#readLeader()}}, peerId must be specified together
> with serverId on a {{ReadIndexRequest}}, but
> {{RaftGroupServiceImpl#readIndex()}} omits serverId, so on the server side
> request processing always fails.
> Probably, local node name should be sent as serverId.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20255) Query join order SQL hint.
[ https://issues.apache.org/jira/browse/IGNITE-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-20255: -- Description: For the join operations, we should have several SQL hints. Like join order or join type. One of them is the query join order hint. Oracle DB's analogy is 'ORDERED'. Looks simple, allows to keep join order. Also, can prevent long joins planning by Calcite. (was: For the join operations, we should have several SQL hints. Like join order or join type. One of them is the query join order hint. Oracle DB's analogue is 'ORDERED'. Looks simple and allows to keep join order and avoid long join planning by Calcite.) > Query join order SQL hint. > -- > > Key: IGNITE-20255 > URL: https://issues.apache.org/jira/browse/IGNITE-20255 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > > For the join operations, we should have several SQL hints. Like join order or > join type. One of them is the query join order hint. Oracle DB's analogy is > 'ORDERED'. Looks simple, allows to keep join order. Also, can prevent long > joins planning by Calcite. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20255) Query join order SQL hint.
[ https://issues.apache.org/jira/browse/IGNITE-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-20255: -- Summary: Query join order SQL hint. (was: Forced join order SQL hint.) > Query join order SQL hint. > -- > > Key: IGNITE-20255 > URL: https://issues.apache.org/jira/browse/IGNITE-20255 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > > For the join operations, we should have several SQL hints. Like join order or > join type. One of them is the query join order hint. Oracle DB's analogue is > 'ORDERED'. Looks simple and allows to keep join order and avoid long join > planning by Calcite. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20255) Forced join order SQL hint.
[ https://issues.apache.org/jira/browse/IGNITE-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-20255: -- Description: For the join operations, we should have several SQL hints. Like join order or join type. One of them is the query join order hint. Oracle DB's analogue is 'ORDERED'. Looks simple and allows to keep join order and avoid long join planning by Calcite. (was: For the join operations, we should have several SQL hints. One of them are the forced join order hints. Oracle DB's analogue would be 'ORDERED', 'LEADING'. Might be combined with join operation type like merge, hash, nl like 'USE_NL', 'USE_MERGE') > Forced join order SQL hint. > --- > > Key: IGNITE-20255 > URL: https://issues.apache.org/jira/browse/IGNITE-20255 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > > For the join operations, we should have several SQL hints. Like join order or > join type. One of them is the query join order hint. Oracle DB's analogue is > 'ORDERED'. Looks simple and allows to keep join order and avoid long join > planning by Calcite. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20279) Reordering of altering zone operations
Vladislav Pyatkov created IGNITE-20279:
--
Summary: Reordering of altering zone operations
Key: IGNITE-20279
URL: https://issues.apache.org/jira/browse/IGNITE-20279
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
The issue is shown in the test, where several zone change operations occur. On
my laptop, the test (tRebalanceDistributedTest#testThreeQueuedRebalances) fails
at least twice on 30 runs.
# The first issue that I see is that the test does not wait to execute the last
zone change operation: alterZone(node, ZONE_NAME, 2). In this case, the
operation can be incomplete at the end of the test.
# The second issue is that the next operation may start earlier than the
previous one is completed.
{noformat}
2023-08-24T16:58:51,328][ERROR][%irdt_ttqr_2%tableManager-io-10][WatchProcessor]
Error occurred when processing a watch event
org.apache.ignite.lang.IgniteInternalException: Raft group on the node is
already started [nodeId=RaftNodeId [groupId=1_part_0, peer=Peer
[consistentId=irdt_ttqr_2, idx=0]]]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupNodeInternal(Loza.java:342)
~[main/:?]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupNode(Loza.java:230)
~[main/:?]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupNode(Loza.java:203)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.TableManager.startPartitionRaftGroupNode(TableManager.java:2361)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$handleChangePendingAssignmentEvent$98(TableManager.java:2261)
~[main/:?]
at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:922)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$handleChangePendingAssignmentEvent$99(TableManager.java:2259)
~[main/:?]
at
java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20279) Reordering of altering zone operations
[
https://issues.apache.org/jira/browse/IGNITE-20279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20279:
---
Description:
The issue is shown in the test, where several zone change operations occur. On
my laptop, the test ({{tRebalanceDistributedTest#testThreeQueuedRebalances}})
fails at least twice on 30 runs.
# The first issue that I see is that the test does not wait to execute the
last zone change operation: alterZone(node, ZONE_NAME, 2). In this case, the
operation can be incomplete at the end of the test.
# The second issue is that the next operation may start earlier than the
previous one is completed.
{noformat}
2023-08-24T16:58:51,328][ERROR][%irdt_ttqr_2%tableManager-io-10][WatchProcessor]
Error occurred when processing a watch event
org.apache.ignite.lang.IgniteInternalException: Raft group on the node is
already started [nodeId=RaftNodeId [groupId=1_part_0, peer=Peer
[consistentId=irdt_ttqr_2, idx=0]]]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupNodeInternal(Loza.java:342)
~[main/:?]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupNode(Loza.java:230)
~[main/:?]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupNode(Loza.java:203)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.TableManager.startPartitionRaftGroupNode(TableManager.java:2361)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$handleChangePendingAssignmentEvent$98(TableManager.java:2261)
~[main/:?]
at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:922)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$handleChangePendingAssignmentEvent$99(TableManager.java:2259)
~[main/:?]
at
java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
{noformat}
was:
The issue is shown in the test, where several zone change operations occur. On
my laptop, the test (tRebalanceDistributedTest#testThreeQueuedRebalances) fails
at least twice on 30 runs.
# The first issue that I see is that the test does not wait to execute the last
zone change operation: alterZone(node, ZONE_NAME, 2). In this case, the
operation can be incomplete at the end of the test.
# The second issue is that the next operation may start earlier than the
previous one is completed.
{noformat}
2023-08-24T16:58:51,328][ERROR][%irdt_ttqr_2%tableManager-io-10][WatchProcessor]
Error occurred when processing a watch event
org.apache.ignite.lang.IgniteInternalException: Raft group on the node is
already started [nodeId=RaftNodeId [groupId=1_part_0, peer=Peer
[consistentId=irdt_ttqr_2, idx=0]]]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupNodeInternal(Loza.java:342)
~[main/:?]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupNode(Loza.java:230)
~[main/:?]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupNode(Loza.java:203)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.TableManager.startPartitionRaftGroupNode(TableManager.java:2361)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$handleChangePendingAssignmentEvent$98(TableManager.java:2261)
~[main/:?]
at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:922)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$handleChangePendingAssignmentEvent$99(TableManager.java:2259)
~[main/:?]
at
java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
{noformat}
> Reordering of altering zone operations
> --
>
> Key: IGNITE-20279
> URL: https://issues.apache.org/jira/browse/IGNITE-20279
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> The issue is shown in the test, where several zone change operations occur.
> On my laptop, the test
> ({{tRebalanceDistributedTest#testThreeQueuedRebalances}}) fails at least
> twice on 30 runs.
> # The first issue that I see is that the test does not wait to execute the
> last zone change operation: alterZone(node, ZONE_NAME, 2). In this case, the
>
[jira] [Updated] (IGNITE-20033) Implement local txnStateMap
[
https://issues.apache.org/jira/browse/IGNITE-20033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-20033:
--
Fix Version/s: 3.0.0-beta2
> Implement local txnStateMap
> ---
>
> Key: IGNITE-20033
> URL: https://issues.apache.org/jira/browse/IGNITE-20033
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3, transaction3_recovery, transactions
> Fix For: 3.0.0-beta2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h3. Motivation
> For some purposes, in addition to persistent txnState in commit partition,
> it's required to have a txn meta on every transactional actor: txn
> coordinator, commit partition (both primary and all backups) and all enlisted
> partitions (both primary and backups).
> [IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Txnstatemap]
> names such meta holder as txn state map and specifies following structure
> {code:java}
> txId -> (txState, txCoordAddr, commitTs){code}
> Such map is originally designed to provide required information for
> writeIntentResolution: txState for local write intent resolution and
> txCoordAddr for coordinator-path one, but that's not all it's good for, so it
> definitely worth to implement it as soon as possible in order to unblock
> further activities.
> -Why we have this ticket in "commit partition recovery" pack?
> -Because in order to implement proper handling of a commit partition primary
> replica change (which is definitely a part of the "commit partition pack")
> it's required to:
> # Support local txnStateMap, in order to
> # Implement writeIntentResolution coordinator path, in order to
> # Calculate commitTimestamp on txn coordtinator istead of commit partition,
> where we do it now.
> h3. Definition of Done
> Every transactional actor
> * Txn Coordinator.
> * CommitPartition, both primary and all backups.
> * All enlisted partitions, both primary and all backups.
> should have volatile txnStateMap with following suggested structure 'txId ->
> (txState, txCoordAddr, commitTs)'.
>
> Given map should be adjusted before any further transactional actions within
> node in a following way:
> * Transaction coordinator.
> ** On transaction start with state PENDING.
> ** On transaction commit, right after commitTimestamp calucalttion with
> state FINISHING.
> ** On txFinishReplicaResponse with either COMMITED or ABORTED.
> * Commit partition.
> ** On replica touch with state PENDING.
> ** After succefull finishTxCommand application on majoirty with either
> COMMITED or ABORTED.
> ** Seems that we don't need FINISHING state here, so let's skip it for now.
> * Enlisted replica.
> ** Primary
> *** On replica touch with state PENDING.
> *** On TxCleanupCommand COMMITED or ABORTED.
> ** Backup
> *** On touch replication PENDING.
> *** On TxCleanupCommand COMMITED or ABORTED, same as for primary.
> h3. Implementation Notes
> There are some open questions:
> * Where to put this txnStateMap? TxManager?
> * Properly handle same map multiple updates, based on the fact that Commit
> Partition is also an enlisted partition. To be honest I believe it's not that
> important. We may extent possible state change application rules to assume
> that null > PENDING, PENDING > FINISHING, PENDING > COMMITED, PENDING >
> ABORTED, PENDING > PENDING, COMMITED > COMMITED and ABORTED > ABORTED are all
> possible.
> * Eliminate excessive map updates in case of "one-phase commit".
> https://issues.apache.org/jira/browse/IGNITE-15927
> * Substitute org.apache.ignite.internal.tx.impl.TxManagerImpl#states with
> txnStateMap.
> * Definte "touch".
> * It's reasonbale to use non-consistent node id as txCoordAddr because
> currently there's no sense in sending TxStateReq to the node that lost it's
> local txnStateMap because of node restart.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20205) TxLocalTest#testBalance is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-20205:
--
Fix Version/s: 3.0.0-beta2
> TxLocalTest#testBalance is flaky
>
>
> Key: IGNITE-20205
> URL: https://issues.apache.org/jira/browse/IGNITE-20205
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TxLocalTest is actually a mock of transactional logic based on local dummy
> table. Seems there are some problems with finalizing the transactions
> transferring money between accounts which causes lock exceptions on checking
> final sum over all accounts. Most likely there is a problem with mock because
> there is no similar problem with other test classes for this test.
> The following assertion occurs in PartitionListener:
> {code:java}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:a143f277-4992-491e-afca-2c06814c1737 Write command must have an index
> greater than that of storages [commandIndex=83248, mvAppliedIndex=83270,
> txStateAppliedIndex=83266, cmd=UpdateCommandImpl [full=false,
> rowMessage=BinaryRowMessageImpl [binaryTuple=java.nio.HeapByteBuffer[pos=0
> lim=8 cap=8], schemaVersion=1], rowUuid=0b19d656-2c55-48fb-9955-a6ca0bbf08ca,
> safeTimeLong=395351, tablePartitionId=TablePartitionIdMessageImpl
> [partitionId=0, tableId=10001], txId=-0006-082f--deadbeef]]
> ==>{code}
> Most likely there are races in mocks of TxLocalTest and
> DummyInternalTableImpl classes, because the test is multi-threaded and mocks
> have no synchronization.
> Seems that synchronized block for the mock of RaftGroupService in
> DummyInternalTableImpl should work.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20278) Make binary_tuple_builder more friendly for inheritance.
Dmitrii Zabotlin created IGNITE-20278: - Summary: Make binary_tuple_builder more friendly for inheritance. Key: IGNITE-20278 URL: https://issues.apache.org/jira/browse/IGNITE-20278 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 3.0 Reporter: Dmitrii Zabotlin Assignee: Dmitrii Zabotlin Make binary_tuple_builder in C++ code more friendly for inheritance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19499) TableManager should listen CatalogService events instead of configuration
[ https://issues.apache.org/jira/browse/IGNITE-19499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-19499: - Assignee: Andrey Mashenkov > TableManager should listen CatalogService events instead of configuration > - > > Key: IGNITE-19499 > URL: https://issues.apache.org/jira/browse/IGNITE-19499 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > As of now, TableManager listens configuration events to create internal > structures. > Let's make TableManager listens CatalogService events instead. > Note: Some tests may fails due to changed guarantees and related ticked > incompletion. So, let's do this in a separate feature branch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20033) Implement local txnStateMap
[
https://issues.apache.org/jira/browse/IGNITE-20033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758575#comment-17758575
]
Denis Chudov commented on IGNITE-20033:
---
PR [2483|https://github.com/apache/ignite-3/pull/2483] is ready for review.
> Implement local txnStateMap
> ---
>
> Key: IGNITE-20033
> URL: https://issues.apache.org/jira/browse/IGNITE-20033
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3, transaction3_recovery, transactions
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h3. Motivation
> For some purposes, in addition to persistent txnState in commit partition,
> it's required to have a txn meta on every transactional actor: txn
> coordinator, commit partition (both primary and all backups) and all enlisted
> partitions (both primary and backups).
> [IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Txnstatemap]
> names such meta holder as txn state map and specifies following structure
> {code:java}
> txId -> (txState, txCoordAddr, commitTs){code}
> Such map is originally designed to provide required information for
> writeIntentResolution: txState for local write intent resolution and
> txCoordAddr for coordinator-path one, but that's not all it's good for, so it
> definitely worth to implement it as soon as possible in order to unblock
> further activities.
> -Why we have this ticket in "commit partition recovery" pack?
> -Because in order to implement proper handling of a commit partition primary
> replica change (which is definitely a part of the "commit partition pack")
> it's required to:
> # Support local txnStateMap, in order to
> # Implement writeIntentResolution coordinator path, in order to
> # Calculate commitTimestamp on txn coordtinator istead of commit partition,
> where we do it now.
> h3. Definition of Done
> Every transactional actor
> * Txn Coordinator.
> * CommitPartition, both primary and all backups.
> * All enlisted partitions, both primary and all backups.
> should have volatile txnStateMap with following suggested structure 'txId ->
> (txState, txCoordAddr, commitTs)'.
>
> Given map should be adjusted before any further transactional actions within
> node in a following way:
> * Transaction coordinator.
> ** On transaction start with state PENDING.
> ** On transaction commit, right after commitTimestamp calucalttion with
> state FINISHING.
> ** On txFinishReplicaResponse with either COMMITED or ABORTED.
> * Commit partition.
> ** On replica touch with state PENDING.
> ** After succefull finishTxCommand application on majoirty with either
> COMMITED or ABORTED.
> ** Seems that we don't need FINISHING state here, so let's skip it for now.
> * Enlisted replica.
> ** Primary
> *** On replica touch with state PENDING.
> *** On TxCleanupCommand COMMITED or ABORTED.
> ** Backup
> *** On touch replication PENDING.
> *** On TxCleanupCommand COMMITED or ABORTED, same as for primary.
> h3. Implementation Notes
> There are some open questions:
> * Where to put this txnStateMap? TxManager?
> * Properly handle same map multiple updates, based on the fact that Commit
> Partition is also an enlisted partition. To be honest I believe it's not that
> important. We may extent possible state change application rules to assume
> that null > PENDING, PENDING > FINISHING, PENDING > COMMITED, PENDING >
> ABORTED, PENDING > PENDING, COMMITED > COMMITED and ABORTED > ABORTED are all
> possible.
> * Eliminate excessive map updates in case of "one-phase commit".
> https://issues.apache.org/jira/browse/IGNITE-15927
> * Substitute org.apache.ignite.internal.tx.impl.TxManagerImpl#states with
> txnStateMap.
> * Definte "touch".
> * It's reasonbale to use non-consistent node id as txCoordAddr because
> currently there's no sense in sending TxStateReq to the node that lost it's
> local txnStateMap because of node restart.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20205) TxLocalTest#testBalance is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-20205:
-
Assignee: Denis Chudov
> TxLocalTest#testBalance is flaky
>
>
> Key: IGNITE-20205
> URL: https://issues.apache.org/jira/browse/IGNITE-20205
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> TxLocalTest is actually a mock of transactional logic based on local dummy
> table. Seems there are some problems with finalizing the transactions
> transferring money between accounts which causes lock exceptions on checking
> final sum over all accounts. Most likely there is a problem with mock because
> there is no similar problem with other test classes for this test.
> The following assertion occurs in PartitionListener:
> {code:java}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:a143f277-4992-491e-afca-2c06814c1737 Write command must have an index
> greater than that of storages [commandIndex=83248, mvAppliedIndex=83270,
> txStateAppliedIndex=83266, cmd=UpdateCommandImpl [full=false,
> rowMessage=BinaryRowMessageImpl [binaryTuple=java.nio.HeapByteBuffer[pos=0
> lim=8 cap=8], schemaVersion=1], rowUuid=0b19d656-2c55-48fb-9955-a6ca0bbf08ca,
> safeTimeLong=395351, tablePartitionId=TablePartitionIdMessageImpl
> [partitionId=0, tableId=10001], txId=-0006-082f--deadbeef]]
> ==>{code}
> Most likely there are races in mocks of TxLocalTest and
> DummyInternalTableImpl classes, because the test is multi-threaded and mocks
> have no synchronization.
> Seems that synchronized block for the mock of RaftGroupService in
> DummyInternalTableImpl should work.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20277) Test ItIgniteInMemoryNodeRestartTest.inMemoryNodeRestartNotLeader(TestInfo) is flaky in main branch
Sergey Chugunov created IGNITE-20277:
Summary: Test
ItIgniteInMemoryNodeRestartTest.inMemoryNodeRestartNotLeader(TestInfo) is flaky
in main branch
Key: IGNITE-20277
URL: https://issues.apache.org/jira/browse/IGNITE-20277
Project: Ignite
Issue Type: Bug
Reporter: Sergey Chugunov
An attempt was made to increase stability of the test (see linked ticket) but
fresh history for main branch shows that it is still flaky: [TC
history|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_IntegrationTests=2378861889774452265=testDetails_ApacheIgnite3xGradle_Test_IntegrationTests=%3Cdefault%3E]
Sometimes it fails with an assertion in test code:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
...
at
app//org.apache.ignite.internal.runner.app.ItIgniteInMemoryNodeRestartTest.inMemoryNodeRestartNotLeader(ItIgniteInMemoryNodeRestartTest.java:197)
{code}
other failures are triggered by operation timeouts:
{code:java}
org.apache.ignite.tx.TransactionException: IGN-REP-3
TraceId:7ba66f02-e08d-41fb-b198-15374cfa717c Replication is timed out
[replicaGrpId=1_part_0]
at
app//org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:378)
at
app//org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:461)
at
app//org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:378)
at
app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.wrapReplicationException(InternalTableImpl.java:1584)
at
app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$postEnlist$9(InternalTableImpl.java:506)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlistWithRetry$5(InternalTableImpl.java:480)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
app//org.apache.ignite.internal.replicator.ReplicaService.lambda$sendToReplica$3(ReplicaService.java:97)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at
java.base@11.0.17/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base@11.0.17/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at
java.base@11.0.17/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base@11.0.17/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base@11.0.17/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by:
org.apache.ignite.internal.replicator.exception.ReplicationTimeoutException:
IGN-REP-3 TraceId:7ba66f02-e08d-41fb-b198-15374cfa717c Replication is timed out
[replicaGrpId=1_part_0]
... 9 more
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20274) Github actions must rely on environment variables instead of context
[ https://issues.apache.org/jira/browse/IGNITE-20274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-20274: - Ignite Flags: (was: Docs Required,Release Notes Required) > Github actions must rely on environment variables instead of context > > > Key: IGNITE-20274 > URL: https://issues.apache.org/jira/browse/IGNITE-20274 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Github actions that are used to perform verification against the source code > must use environment variables set directly on the action. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20274) Github actions must rely on environment variables instead of context
[ https://issues.apache.org/jira/browse/IGNITE-20274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758536#comment-17758536 ] Maxim Muzafarov commented on IGNITE-20274: -- Merged to the master branch. > Github actions must rely on environment variables instead of context > > > Key: IGNITE-20274 > URL: https://issues.apache.org/jira/browse/IGNITE-20274 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Github actions that are used to perform verification against the source code > must use environment variables set directly on the action. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20276) Include tests into run PMD configuration
Yury Gerzhedovich created IGNITE-20276: -- Summary: Include tests into run PMD configuration Key: IGNITE-20276 URL: https://issues.apache.org/jira/browse/IGNITE-20276 Project: Ignite Issue Type: Improvement Reporter: Yury Gerzhedovich Assignee: Yury Gerzhedovich Gradle configuration to run PMD check include only production code. Need to add test classes too -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20086) Ensure mockito resources cleaned after tests.
[ https://issues.apache.org/jira/browse/IGNITE-20086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-20086: Assignee: Aleksandr Polovtcev (was: Andrey Mashenkov) > Ensure mockito resources cleaned after tests. > -- > > Key: IGNITE-20086 > URL: https://issues.apache.org/jira/browse/IGNITE-20086 > Project: Ignite > Issue Type: Test >Reporter: Andrey Mashenkov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3, stability > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Tests must clean up inline mocks on tear-down. > Otherwise it may lead to OOM, see IGNITE-20065. > Let's add an arch-test to be sure all the test, which use mocks, inherits > BaseIgniteAbstractTest class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20100) Wrong dependencies in ODBC driver's DEB package
[
https://issues.apache.org/jira/browse/IGNITE-20100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758480#comment-17758480
]
Ivan Artiukhov commented on IGNITE-20100:
-
[~isapego]
Checked rev. 18f67c8fe2266d7fc9932a9a42b47856b438a518.
The issue looks fixed. Please close the ticket.
> Wrong dependencies in ODBC driver's DEB package
>
>
> Key: IGNITE-20100
> URL: https://issues.apache.org/jira/browse/IGNITE-20100
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0
>Reporter: Ivan Artiukhov
>Assignee: Igor Sapego
>Priority: Major
> Labels: ignite-3
>
> OS:
> {noformat}
> root@f2a61d386c24:/# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 12
> (bookworm)"
> NAME="Debian GNU/Linux"
> VERSION_ID="12"
> VERSION="12 (bookworm)"
> {noformat}
> Trying to install DEB with ODBC driver:
> {noformat}
> root@f2a61d386c24:/# apt install /tmp/ignite3-odbc_3.0.0-SNAPSHOT_all.deb
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Note, selecting 'ignite3-odbc' instead of
> '/tmp/ignite3-odbc_9.0.0~ea2_all.deb'
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> The following packages have unmet dependencies:
> ignite3-odbc : Depends: unixODBC but it is not installable
> E: Unable to correct problems, you have held broken packages.
> {noformat}
> Expected dependency name: {{unixodbc}}
> Actual dependency name: {{unuxODBC}}
> Also the following dependency must be explicitly stated to make post-install
> and post-remove steps work correctly: {{odbcinst}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20155) Java client connector skips NOT NULL and other column checks
[ https://issues.apache.org/jira/browse/IGNITE-20155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758446#comment-17758446 ] Pavel Tupitsyn commented on IGNITE-20155: - Merged to main: 73150f1b458607b3bc275369c3b5426855725e0c > Java client connector skips NOT NULL and other column checks > > > Key: IGNITE-20155 > URL: https://issues.apache.org/jira/browse/IGNITE-20155 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > See *TupleMarshallerImpl#marshal* and *#binaryTupleRebuildRequired*: we pass > BinaryTuple as is from the client, bypassing NOT NULL and other constraint > checks. > We should validate the data from the client without reassembling the tuple. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20275) AssertionError in ClientInboundMessageHandler ctor - race condition
[
https://issues.apache.org/jira/browse/IGNITE-20275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20275:
Ignite Flags: (was: Docs Required,Release Notes Required)
> AssertionError in ClientInboundMessageHandler ctor - race condition
> ---
>
> Key: IGNITE-20275
> URL: https://issues.apache.org/jira/browse/IGNITE-20275
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
> [2023-08-24T06:52:18,812][WARN
> ][TestServer--srv-worker-1][ChannelInitializer] Failed to initialize a
> channel. Closing: [id: 0x252ff875, L:/127.0.0.1:10903 - R:/127.0.0.1:52514]
> java.lang.AssertionError: null
> at
> org.apache.ignite.client.handler.ClientInboundMessageHandler.(ClientInboundMessageHandler.java:215)
> ~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.client.handler.ClientHandlerModule.createInboundMessageHandler(ClientHandlerModule.java:291)
> ~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:254)
> ~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at java.lang.Thread.run(Thread.java:834) ~[?:?]
> {code}
> Looks like a race condition in *ClientHandlerModule* between:
> * clusterId = clusterIdSupplier.get().join();
> * createInboundMessageHandler (which passes clusterId to
> ClientInboundMessageHandler)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20275) AssertionError in ClientInboundMessageHandler ctor - race condition
[
https://issues.apache.org/jira/browse/IGNITE-20275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20275:
Description:
{code}
[2023-08-24T06:52:18,812][WARN ][TestServer--srv-worker-1][ChannelInitializer]
Failed to initialize a channel. Closing: [id: 0x252ff875, L:/127.0.0.1:10903 -
R:/127.0.0.1:52514]
java.lang.AssertionError: null
at
org.apache.ignite.client.handler.ClientInboundMessageHandler.(ClientInboundMessageHandler.java:215)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.client.handler.ClientHandlerModule.createInboundMessageHandler(ClientHandlerModule.java:291)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:254)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
{code}
Looks like a race condition in *ClientHandlerModule* between:
* clusterId = clusterIdSupplier.get().join();
* createInboundMessageHandler (which passes clusterId to
ClientInboundMessageHandler)
was:
{code}
[2023-08-24T06:52:18,812][WARN ][TestServer--srv-worker-1][ChannelInitializer]
Failed to initialize a channel. Closing: [id: 0x252ff875, L:/127.0.0.1:10903 -
R:/127.0.0.1:52514]
java.lang.AssertionError: null
at
org.apache.ignite.client.handler.ClientInboundMessageHandler.(ClientInboundMessageHandler.java:215)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.client.handler.ClientHandlerModule.createInboundMessageHandler(ClientHandlerModule.java:291)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:254)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
[jira] [Updated] (IGNITE-20275) AssertionError in ClientInboundMessageHandler ctor - race condition
[
https://issues.apache.org/jira/browse/IGNITE-20275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20275:
Summary: AssertionError in ClientInboundMessageHandler ctor - race
condition (was: AssertionError in ClientInboundMessageHandler ctor)
> AssertionError in ClientInboundMessageHandler ctor - race condition
> ---
>
> Key: IGNITE-20275
> URL: https://issues.apache.org/jira/browse/IGNITE-20275
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
> [2023-08-24T06:52:18,812][WARN
> ][TestServer--srv-worker-1][ChannelInitializer] Failed to initialize a
> channel. Closing: [id: 0x252ff875, L:/127.0.0.1:10903 - R:/127.0.0.1:52514]
> java.lang.AssertionError: null
> at
> org.apache.ignite.client.handler.ClientInboundMessageHandler.(ClientInboundMessageHandler.java:215)
> ~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.client.handler.ClientHandlerModule.createInboundMessageHandler(ClientHandlerModule.java:291)
> ~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:254)
> ~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
> ~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ~[netty-common-4.1.87.Final.jar:4.1.87.Final]
> at java.lang.Thread.run(Thread.java:834) ~[?:?]
> {code}
> There is also a blocking wait
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20275) AssertionError in ClientInboundMessageHandler ctor
[
https://issues.apache.org/jira/browse/IGNITE-20275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20275:
Description:
{code}
[2023-08-24T06:52:18,812][WARN ][TestServer--srv-worker-1][ChannelInitializer]
Failed to initialize a channel. Closing: [id: 0x252ff875, L:/127.0.0.1:10903 -
R:/127.0.0.1:52514]
java.lang.AssertionError: null
at
org.apache.ignite.client.handler.ClientInboundMessageHandler.(ClientInboundMessageHandler.java:215)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.client.handler.ClientHandlerModule.createInboundMessageHandler(ClientHandlerModule.java:291)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:254)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
{code}
There is also a blocking wait
was:
{code}
[2023-08-24T06:52:18,812][WARN ][TestServer--srv-worker-1][ChannelInitializer]
Failed to initialize a channel. Closing: [id: 0x252ff875, L:/127.0.0.1:10903 -
R:/127.0.0.1:52514]
java.lang.AssertionError: null
at
org.apache.ignite.client.handler.ClientInboundMessageHandler.(ClientInboundMessageHandler.java:215)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.client.handler.ClientHandlerModule.createInboundMessageHandler(ClientHandlerModule.java:291)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:254)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
[jira] [Updated] (IGNITE-20275) AssertionError in ClientInboundMessageHandler ctor
[
https://issues.apache.org/jira/browse/IGNITE-20275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20275:
Description:
{code}
[2023-08-24T06:52:18,812][WARN ][TestServer--srv-worker-1][ChannelInitializer]
Failed to initialize a channel. Closing: [id: 0x252ff875, L:/127.0.0.1:10903 -
R:/127.0.0.1:52514]
java.lang.AssertionError: null
at
org.apache.ignite.client.handler.ClientInboundMessageHandler.(ClientInboundMessageHandler.java:215)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.client.handler.ClientHandlerModule.createInboundMessageHandler(ClientHandlerModule.java:291)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:254)
~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
at
io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
~[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
~[netty-common-4.1.87.Final.jar:4.1.87.Final]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
{code}
> AssertionError in ClientInboundMessageHandler ctor
> --
>
> Key: IGNITE-20275
> URL: https://issues.apache.org/jira/browse/IGNITE-20275
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
> [2023-08-24T06:52:18,812][WARN
> ][TestServer--srv-worker-1][ChannelInitializer] Failed to initialize a
> channel. Closing: [id: 0x252ff875, L:/127.0.0.1:10903 - R:/127.0.0.1:52514]
> java.lang.AssertionError: null
> at
> org.apache.ignite.client.handler.ClientInboundMessageHandler.(ClientInboundMessageHandler.java:215)
> ~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.client.handler.ClientHandlerModule.createInboundMessageHandler(ClientHandlerModule.java:291)
> ~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:254)
> ~[ignite-client-handler-3.0.0-SNAPSHOT.jar:?]
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
>
[jira] [Created] (IGNITE-20275) AssertionError in ClientInboundMessageHandler ctor
Pavel Tupitsyn created IGNITE-20275: --- Summary: AssertionError in ClientInboundMessageHandler ctor Key: IGNITE-20275 URL: https://issues.apache.org/jira/browse/IGNITE-20275 Project: Ignite Issue Type: Bug Components: 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] [Assigned] (IGNITE-20100) Wrong dependencies in ODBC driver's DEB package
[
https://issues.apache.org/jira/browse/IGNITE-20100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-20100:
Assignee: Igor Sapego
> Wrong dependencies in ODBC driver's DEB package
>
>
> Key: IGNITE-20100
> URL: https://issues.apache.org/jira/browse/IGNITE-20100
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0
>Reporter: Ivan Artiukhov
>Assignee: Igor Sapego
>Priority: Major
> Labels: ignite-3
>
> OS:
> {noformat}
> root@f2a61d386c24:/# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 12
> (bookworm)"
> NAME="Debian GNU/Linux"
> VERSION_ID="12"
> VERSION="12 (bookworm)"
> {noformat}
> Trying to install DEB with ODBC driver:
> {noformat}
> root@f2a61d386c24:/# apt install /tmp/ignite3-odbc_3.0.0-SNAPSHOT_all.deb
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Note, selecting 'ignite3-odbc' instead of
> '/tmp/ignite3-odbc_9.0.0~ea2_all.deb'
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> The following packages have unmet dependencies:
> ignite3-odbc : Depends: unixODBC but it is not installable
> E: Unable to correct problems, you have held broken packages.
> {noformat}
> Expected dependency name: {{unixodbc}}
> Actual dependency name: {{unuxODBC}}
> Also the following dependency must be explicitly stated to make post-install
> and post-remove steps work correctly: {{odbcinst}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20100) Wrong dependencies in ODBC driver's DEB package
[
https://issues.apache.org/jira/browse/IGNITE-20100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758441#comment-17758441
]
Igor Sapego commented on IGNITE-20100:
--
Problem is fixed in IGNITE-20082. [~Artukhov], please confirm, that the problem
is not reproduced on main.
> Wrong dependencies in ODBC driver's DEB package
>
>
> Key: IGNITE-20100
> URL: https://issues.apache.org/jira/browse/IGNITE-20100
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3
>
> OS:
> {noformat}
> root@f2a61d386c24:/# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 12
> (bookworm)"
> NAME="Debian GNU/Linux"
> VERSION_ID="12"
> VERSION="12 (bookworm)"
> {noformat}
> Trying to install DEB with ODBC driver:
> {noformat}
> root@f2a61d386c24:/# apt install /tmp/ignite3-odbc_3.0.0-SNAPSHOT_all.deb
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Note, selecting 'ignite3-odbc' instead of
> '/tmp/ignite3-odbc_9.0.0~ea2_all.deb'
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> The following packages have unmet dependencies:
> ignite3-odbc : Depends: unixODBC but it is not installable
> E: Unable to correct problems, you have held broken packages.
> {noformat}
> Expected dependency name: {{unixodbc}}
> Actual dependency name: {{unuxODBC}}
> Also the following dependency must be explicitly stated to make post-install
> and post-remove steps work correctly: {{odbcinst}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19570) Write intent resolution for RW transactions
[
https://issues.apache.org/jira/browse/IGNITE-19570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758435#comment-17758435
]
Vladislav Pyatkov commented on IGNITE-19570:
Merged f9bfb52907ca7074c67661e6de7183645add1341
> Write intent resolution for RW transactions
> ---
>
> Key: IGNITE-19570
> URL: https://issues.apache.org/jira/browse/IGNITE-19570
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, transaction, transaction3_recovery
> Fix For: 3.0.0-beta2
>
> Time Spent: 8.5h
> Remaining Estimate: 0h
>
> *Motivation*
> Currently, RW transaction resolves only write intents by itself. If RW
> transaction steps on a write intent from another transaction, an assertion
> error will appear.
> {code:java}
> // Should never happen, currently, locks prevent reading another
> transaction intents during RW requests.
> throw new AssertionError("Mismatched transaction id, expectedTxId={" +
> txId + "},"
> + " actualTxId={" + retrievedResultTxId + '}');
> {code}
> Really, we will be able to leave write intent in case when node restarted
> before it can handle cleanup message. Now, we workaround the case by scanning
> storage for logging for write intent and commit them on start:
> {code:java}
> try (PartitionTimestampCursor cursor =
> partitionDataStorage.scan(HybridTimestamp.MAX_VALUE)) {
> while (cursor.hasNext()) {
> ReadResult readResult = cursor.next();
> if (readResult.isWriteIntent()) {
>
> txsPendingRowIds.computeIfAbsent(readResult.transactionId(), key -> new
> TreeSet<>()).add(readResult.rowId());
> }
> }
> }
> {code}
> But this is very time-consuming.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18965) Sql. CREATE TABLE fails when a column with DEFAULT constraint NULL is present.
[
https://issues.apache.org/jira/browse/IGNITE-18965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18965:
---
Labels: calcite2-required ignite-3 (was: calcite2-required
calcite3-required ignite-3)
> Sql. CREATE TABLE fails when a column with DEFAULT constraint NULL is present.
> --
>
> Key: IGNITE-18965
> URL: https://issues.apache.org/jira/browse/IGNITE-18965
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Default constraint with value = NULL causes an error.
> {code:java}
> CREATE TABLE tbl(id int PRIMARY KEY, val INTEGER DEFAULT NULL)
> {code}
> {code:java}
> Caused by: java.lang.ClassCastException: Cannot cast
> org.apache.calcite.rel.metadata.NullSentinel$1 to java.lang.Integer
> at java.base/java.lang.Class.cast(Class.java:3605)
> at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:288)
> at
> org.apache.ignite.internal.sql.engine.prepare.ddl.DdlSqlToCommandConverter.fromLiteral(DdlSqlToCommandConverter.java:799)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20054) Flaky tests in ItIgniteDistributionZoneManagerNodeRestartTest
[ https://issues.apache.org/jira/browse/IGNITE-20054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-20054: --- Reviewer: Mirza Aliev > Flaky tests in ItIgniteDistributionZoneManagerNodeRestartTest > - > > Key: IGNITE-20054 > URL: https://issues.apache.org/jira/browse/IGNITE-20054 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > *Motivation* > After https://issues.apache.org/jira/browse/IGNITE-19506 was implemented > some tests start to fail. > For example the test testScaleUpTimerIsRestoredAfterRestart use `blockUpdate` > to prevent data nodes updating in the meta storage. Then it check the data > nodes for the zone. But now dataNodes method returns nodes which even have > not written to the meta storage. Because dataNodes use augmentation map. So I > tried to fix this and similar tests by checking data nodes in metastorage, > but after that this tests are flaky. > *Definition of Done* > Fix and enabled tests from ItIgniteDistributionZoneManagerNodeRestartTest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20272) Clean up of DistributionZoneManagerWatchListenerTest
[ https://issues.apache.org/jira/browse/IGNITE-20272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-20272: --- Reviewer: Mirza Aliev > Clean up of DistributionZoneManagerWatchListenerTest > > > Key: IGNITE-20272 > URL: https://issues.apache.org/jira/browse/IGNITE-20272 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, tech-debt > Time Spent: 10m > Remaining Estimate: 0h > > h3. *Motivation* > Ticket https://issues.apache.org/jira/browse/IGNITE-18564 was closed because > it is not actual anymore. But actually, the > DistributionZoneManagerWatchListenerTest that was mentioned in this ticket is > not actual. So we need to remove some tests in this class now and later > remove this class when ticket > https://issues.apache.org/jira/browse/IGNITE-19955 is implemented. > DistributionZoneManagerWatchListenerTest has three tests: > # The testStaleWatchEvent is disabled. It fails on an invoke into a > metastorage in which the logical topology and its version are updated. It > fails because the condition of the invoke was incorrect after some changes in > the code. But it is not necessary to use a condition there, I replaced it > with ms.putAll, and the test passed successfully. This test can be removed > because it repeats the > testScaleUpDidNotChangeDataNodesWhenTriggerKeyWasConcurrentlyChanged test. > # testDataNodesUpdatedOnZoneManagerStart is the happy path of the restart, we > already have such tests. Therefore, this test is not needed and can be > removed. > # testStaleVaultRevisionOnZoneManagerStart This test simulates that on the > zones manager restart, the data nodes for the zone will not be updated to the > value corresponding to the logical topology from the vault, because > zonesChangeTriggerKey > metaStorageManager.appliedRevision(). I have not > found an analog of this test. I think that when the DZM restart is updated > then we can update this test and move it to the more appropriate class. > h3. *Definition of done* > # testStaleWatchEvent and testDataNodesUpdatedOnZoneManagerStart are removed. > # testStaleVaultRevisionOnZoneManagerStart marked by IGNITE-19955. > # TODOs with IGNITE-18564 are removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20155) Java client connector skips NOT NULL and other column checks
[ https://issues.apache.org/jira/browse/IGNITE-20155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758419#comment-17758419 ] Igor Sapego commented on IGNITE-20155: -- Looks good to me. > Java client connector skips NOT NULL and other column checks > > > Key: IGNITE-20155 > URL: https://issues.apache.org/jira/browse/IGNITE-20155 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > See *TupleMarshallerImpl#marshal* and *#binaryTupleRebuildRequired*: we pass > BinaryTuple as is from the client, bypassing NOT NULL and other constraint > checks. > We should validate the data from the client without reassembling the tuple. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19570) Write intent resolution for RW transactions
[
https://issues.apache.org/jira/browse/IGNITE-19570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758411#comment-17758411
]
Alexander Lapin commented on IGNITE-19570:
--
[~v.pyatkov] LGTM
> Write intent resolution for RW transactions
> ---
>
> Key: IGNITE-19570
> URL: https://issues.apache.org/jira/browse/IGNITE-19570
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, transaction, transaction3_recovery
> Fix For: 3.0.0-beta2
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> *Motivation*
> Currently, RW transaction resolves only write intents by itself. If RW
> transaction steps on a write intent from another transaction, an assertion
> error will appear.
> {code:java}
> // Should never happen, currently, locks prevent reading another
> transaction intents during RW requests.
> throw new AssertionError("Mismatched transaction id, expectedTxId={" +
> txId + "},"
> + " actualTxId={" + retrievedResultTxId + '}');
> {code}
> Really, we will be able to leave write intent in case when node restarted
> before it can handle cleanup message. Now, we workaround the case by scanning
> storage for logging for write intent and commit them on start:
> {code:java}
> try (PartitionTimestampCursor cursor =
> partitionDataStorage.scan(HybridTimestamp.MAX_VALUE)) {
> while (cursor.hasNext()) {
> ReadResult readResult = cursor.next();
> if (readResult.isWriteIntent()) {
>
> txsPendingRowIds.computeIfAbsent(readResult.transactionId(), key -> new
> TreeSet<>()).add(readResult.rowId());
> }
> }
> }
> {code}
> But this is very time-consuming.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19570) Write intent resolution for RW transactions
[
https://issues.apache.org/jira/browse/IGNITE-19570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-19570:
-
Reviewer: Alexander Lapin
> Write intent resolution for RW transactions
> ---
>
> Key: IGNITE-19570
> URL: https://issues.apache.org/jira/browse/IGNITE-19570
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, transaction, transaction3_recovery
> Fix For: 3.0.0-beta2
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> *Motivation*
> Currently, RW transaction resolves only write intents by itself. If RW
> transaction steps on a write intent from another transaction, an assertion
> error will appear.
> {code:java}
> // Should never happen, currently, locks prevent reading another
> transaction intents during RW requests.
> throw new AssertionError("Mismatched transaction id, expectedTxId={" +
> txId + "},"
> + " actualTxId={" + retrievedResultTxId + '}');
> {code}
> Really, we will be able to leave write intent in case when node restarted
> before it can handle cleanup message. Now, we workaround the case by scanning
> storage for logging for write intent and commit them on start:
> {code:java}
> try (PartitionTimestampCursor cursor =
> partitionDataStorage.scan(HybridTimestamp.MAX_VALUE)) {
> while (cursor.hasNext()) {
> ReadResult readResult = cursor.next();
> if (readResult.isWriteIntent()) {
>
> txsPendingRowIds.computeIfAbsent(readResult.transactionId(), key -> new
> TreeSet<>()).add(readResult.rowId());
> }
> }
> }
> {code}
> But this is very time-consuming.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20270) Improve RocksDB iterator performance
[
https://issues.apache.org/jira/browse/IGNITE-20270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-20270:
-
Fix Version/s: 3.0.0-beta2
> Improve RocksDB iterator performance
>
>
> Key: IGNITE-20270
> URL: https://issues.apache.org/jira/browse/IGNITE-20270
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: screenshot-2.png, screenshot-3.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When running benchmarks that insert around 700 rows into Ignite 3, I've
> discovered that a lot of time is spent in {{iterator.seek}} calls:
> !screenshot-3.png!
> I've tried multiple strategies to improve this behavior:
> # Introduce Bloom Filters:
> https://github.com/facebook/rocksdb/wiki/Prefix-Seek#configure-prefix-bloom-filter
> # Use Tailing Iterators:
> https://github.com/facebook/rocksdb/wiki/Tailing-Iterator
> # Use adaptive prefix mode:
> https://github.com/facebook/rocksdb/wiki/Prefix-Seek#adaptive-prefix-mode
> This improved some scenarios up to 6 times:
> !screenshot-2.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19570) Write intent resolution for RW transactions
[
https://issues.apache.org/jira/browse/IGNITE-19570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-19570:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Write intent resolution for RW transactions
> ---
>
> Key: IGNITE-19570
> URL: https://issues.apache.org/jira/browse/IGNITE-19570
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, transaction, transaction3_recovery
> Fix For: 3.0.0-beta2
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> *Motivation*
> Currently, RW transaction resolves only write intents by itself. If RW
> transaction steps on a write intent from another transaction, an assertion
> error will appear.
> {code:java}
> // Should never happen, currently, locks prevent reading another
> transaction intents during RW requests.
> throw new AssertionError("Mismatched transaction id, expectedTxId={" +
> txId + "},"
> + " actualTxId={" + retrievedResultTxId + '}');
> {code}
> Really, we will be able to leave write intent in case when node restarted
> before it can handle cleanup message. Now, we workaround the case by scanning
> storage for logging for write intent and commit them on start:
> {code:java}
> try (PartitionTimestampCursor cursor =
> partitionDataStorage.scan(HybridTimestamp.MAX_VALUE)) {
> while (cursor.hasNext()) {
> ReadResult readResult = cursor.next();
> if (readResult.isWriteIntent()) {
>
> txsPendingRowIds.computeIfAbsent(readResult.transactionId(), key -> new
> TreeSet<>()).add(readResult.rowId());
> }
> }
> }
> {code}
> But this is very time-consuming.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19710) .NET: Thin 3.0: Data Streamer schema synchronization
[ https://issues.apache.org/jira/browse/IGNITE-19710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19710: Issue Type: Bug (was: Task) > .NET: Thin 3.0: Data Streamer schema synchronization > > > Key: IGNITE-19710 > URL: https://issues.apache.org/jira/browse/IGNITE-19710 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, .NET data streamer works using a fixed schema version. Implement > schema update logic: > * Detect schema updates while streaming > * Re-serialize current batches > Requires new client schema sync logic from IGNITE-19397 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20077) Sql. Bump calcite version to 1.35.0
[ https://issues.apache.org/jira/browse/IGNITE-20077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-20077: Labels: calcite2-required ignite-3 (was: ignite-3) > Sql. Bump calcite version to 1.35.0 > --- > > Key: IGNITE-20077 > URL: https://issues.apache.org/jira/browse/IGNITE-20077 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite2-required, ignite-3 > > New calcite version was updated [1]. So we need to update > org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable too and as > described in class header item`s : 2, 3, 5 seems can be removed and changed > into native ones. > Also interesting new rule was introduced, probably it would be helpful to > include it. > [1] https://calcite.apache.org/docs/history.html#v1-35-0 > [2] https://issues.apache.org/jira/browse/CALCITE-5669 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20077) Sql. Bump calcite version to 1.35.0
[ https://issues.apache.org/jira/browse/IGNITE-20077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-20077: --- Assignee: Evgeny Stanilovsky > Sql. Bump calcite version to 1.35.0 > --- > > Key: IGNITE-20077 > URL: https://issues.apache.org/jira/browse/IGNITE-20077 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > New calcite version was updated [1]. So we need to update > org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable too and as > described in class header item`s : 2, 3, 5 seems can be removed and changed > into native ones. > Also interesting new rule was introduced, probably it would be helpful to > include it. > [1] https://calcite.apache.org/docs/history.html#v1-35-0 > [2] https://issues.apache.org/jira/browse/CALCITE-5669 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20265) Check and slightly refactor the validation of indexes in the catalog
[ https://issues.apache.org/jira/browse/IGNITE-20265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758387#comment-17758387 ] Roman Puchkovskiy commented on IGNITE-20265: The patch looks good to me > Check and slightly refactor the validation of indexes in the catalog > > > Key: IGNITE-20265 > URL: https://issues.apache.org/jira/browse/IGNITE-20265 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 6.5h > Remaining Estimate: 0h > > We need to make sure that all validation for indexes is present in the > catalog. > Slightly refactor the code related to validation, for example, move > validation methods to *CatalogParamsValidationUtils* and tests related to it > in *CatalogManagerValidationTest*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17890) Calcite engine. Support index scan on boolean field
[
https://issues.apache.org/jira/browse/IGNITE-17890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17890:
--
Labels: calcite (was: calcite calcite3-required)
> Calcite engine. Support index scan on boolean field
> ---
>
> Key: IGNITE-17890
> URL: https://issues.apache.org/jira/browse/IGNITE-17890
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite
> Fix For: 2.15
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, if table has index on boolean field it can't be used, since
> queries like
> {code:java}
> SELECT * FROM tbl WHERE a = TRUE
> {code}
> Simplified by Calcite to
> {code:java}
> SELECT * FROM tbl WHERE a {code}
> Condition `{{{}a{}}}` is not supported for building search bounds (see
> \{{RexUtils.isSupportedTreeComparison()}}) and such an index can't be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20265) Check and slightly refactor the validation of indexes in the catalog
[ https://issues.apache.org/jira/browse/IGNITE-20265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20265: - Reviewer: Roman Puchkovskiy > Check and slightly refactor the validation of indexes in the catalog > > > Key: IGNITE-20265 > URL: https://issues.apache.org/jira/browse/IGNITE-20265 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 6h 20m > Remaining Estimate: 0h > > We need to make sure that all validation for indexes is present in the > catalog. > Slightly refactor the code related to validation, for example, move > validation methods to *CatalogParamsValidationUtils* and tests related to it > in *CatalogManagerValidationTest*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18303) Calcite engine. Fix nanoseconds flakyness in LocalDateTimeSupportTest
[ https://issues.apache.org/jira/browse/IGNITE-18303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-18303: Labels: (was: calcite3-required) > Calcite engine. Fix nanoseconds flakyness in LocalDateTimeSupportTest > -- > > Key: IGNITE-18303 > URL: https://issues.apache.org/jira/browse/IGNITE-18303 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
