[jira] [Created] (IGNITE-17658) Unable to make field private final java.lang.Class java.lang.invoke.SerializedLambda.capturingClass accessible: module java.base does not "opens java.lang.invoke" to un
YuJue Li created IGNITE-17658: - Summary: Unable to make field private final java.lang.Class java.lang.invoke.SerializedLambda.capturingClass accessible: module java.base does not "opens java.lang.invoke" to unnamed module Key: IGNITE-17658 URL: https://issues.apache.org/jira/browse/IGNITE-17658 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.13 Environment: jdk17 Reporter: YuJue Li Assignee: YuJue Li Fix For: 2.15 Attachments: IgniteClient.java start a node with peerClassLoadingEnabled = true; execute the reproducer; then error occurs: [19:14:24,425][SEVERE][pub-#17][BinaryContext] Failed to deserialize object [typeName=o.a.i.i.processors.closure.GridClosureProcessor$C4] java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.lang.Class java.lang.invoke.SerializedLambda.capturingClass accessible: mo dule java.base does not "opens java.lang.invoke" to unnamed module @694e1548 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17611) Implement proper local storage recovery for transaction state store
[
https://issues.apache.org/jira/browse/IGNITE-17611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601825#comment-17601825
]
Semyon Danilov commented on IGNITE-17611:
-
Looks good to me!
> Implement proper local storage recovery for transaction state store
> ---
>
> Key: IGNITE-17611
> URL: https://issues.apache.org/jira/browse/IGNITE-17611
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> h3. Preliminaries
> Current design expects transaction states to be replicated using the same
> RAFT groups that process partition transactional data. In code this means
> that there are two physical storages associated with a single state machine.
> This design is easy to achieve when the system is stable, but fault tolerance
> and basic node restart might introduce some complications.
> h3. Partition storage design
> By itself, partition storage works this way:
> * every write command writes value of the RAFT log index, associated with
> the command;
> * this index value is written atomically with the data from the command;
> * updates are accumulated in the memory buffer before being written to disk.
> * upon restart, we read the value of the last applied index and proceed the
> recovery process from it. It's done with RAFT snapshots infrastructure.
> h3. Changes to tx state store
> Basically, everything has to be repeated:
> * applied index value must be introduced to tx state storage;
> * updates must be atomic;
> * on restart, we should use the minimal value of last applied index from
> both TX State and MvPartinion storages ({{{}PartitionSnapshotStorage{}}} has
> to be changed).
> h3. Other necessary changes
> * atomic flush must be set up for the tx state storage. WAL should be
> disabled;
> * snapshot command must trigger the flush. Please refer to
> {{RocksDbFlushListener}} and {{RocksDbMvPartitionStorage#flush}} for
> implementation reference. Listener class can be generified and reused;
> * assertion in {{PartitionListener#onWrite}} should be removed or
> drastically improved;
> * read operation on storages must be prohibited until local recovery is
> completed - we should apply all command up to "commitIndex" value that's been
> read at the start of the node, otherwise storages may have data, inconsistent
> with each other.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17611) Implement proper local storage recovery for transaction state store
[
https://issues.apache.org/jira/browse/IGNITE-17611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov updated IGNITE-17611:
Reviewer: Semyon Danilov
> Implement proper local storage recovery for transaction state store
> ---
>
> Key: IGNITE-17611
> URL: https://issues.apache.org/jira/browse/IGNITE-17611
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> h3. Preliminaries
> Current design expects transaction states to be replicated using the same
> RAFT groups that process partition transactional data. In code this means
> that there are two physical storages associated with a single state machine.
> This design is easy to achieve when the system is stable, but fault tolerance
> and basic node restart might introduce some complications.
> h3. Partition storage design
> By itself, partition storage works this way:
> * every write command writes value of the RAFT log index, associated with
> the command;
> * this index value is written atomically with the data from the command;
> * updates are accumulated in the memory buffer before being written to disk.
> * upon restart, we read the value of the last applied index and proceed the
> recovery process from it. It's done with RAFT snapshots infrastructure.
> h3. Changes to tx state store
> Basically, everything has to be repeated:
> * applied index value must be introduced to tx state storage;
> * updates must be atomic;
> * on restart, we should use the minimal value of last applied index from
> both TX State and MvPartinion storages ({{{}PartitionSnapshotStorage{}}} has
> to be changed).
> h3. Other necessary changes
> * atomic flush must be set up for the tx state storage. WAL should be
> disabled;
> * snapshot command must trigger the flush. Please refer to
> {{RocksDbFlushListener}} and {{RocksDbMvPartitionStorage#flush}} for
> implementation reference. Listener class can be generified and reused;
> * assertion in {{PartitionListener#onWrite}} should be removed or
> drastically improved;
> * read operation on storages must be prohibited until local recovery is
> completed - we should apply all command up to "commitIndex" value that's been
> read at the start of the node, otherwise storages may have data, inconsistent
> with each other.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601818#comment-17601818
]
Ignite TC Bot commented on IGNITE-17541:
{panel:title=Branch: [pull/10230/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10230/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6756488buildTypeId=IgniteTests24Java8_RunAll]
> Add "set" prefix to
> ThinClientConfiguration#sendServerExceptionStackTraceToClient()
> ---
>
> Key: IGNITE-17541
> URL: https://issues.apache.org/jira/browse/IGNITE-17541
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise, newbie
> Time Spent: 3h 25m
> Remaining Estimate: 0h
>
> IGNITE-13389 introduces
> {{ThinClientConfiguration#sendServerExceptionStackTraceToClient()}}, but name
> of the method does not allow to set up this option in XML configuration,
> because Spring expects "set" prefix for setters.
> As you can see below, there is a workaround, but it would be more convenient
> to set up this property directly.
> Workaround:
> {code:xml|title=Add extra ThinClientConfiguration bean with necessary
> parameters}
> class="org.apache.ignite.configuration.ThinClientConfiguration">
>
>
> {code}
> {code:xml|title=Set up thinClientConfiguration by means of SpEL}
>
> class="org.apache.ignite.configuration.ClientConnectorConfiguration">
>
> value="#{thinClientCfg.sendServerExceptionStackTraceToClient(true)}"/>
>
>
> {code}
> We should add "set" and "get" prefix to setter and getter methods
> respectively or add extra methods with such prefixes from the point of
> possible compatibility issues (see IGNITE-16549).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17657) Partition data loss after rolling restart
Alexey Kukushkin created IGNITE-17657:
-
Summary: Partition data loss after rolling restart
Key: IGNITE-17657
URL: https://issues.apache.org/jira/browse/IGNITE-17657
Project: Ignite
Issue Type: Bug
Affects Versions: 2.13
Reporter: Alexey Kukushkin
*Setup*
An active 3+ node Apache Ignite 2.13 cluster with a cache with 1 backup,
enabled persistence and default partition loss policy.
*Actions*
# An application is continuously writing data to the cache
# The nodes are sequentially restarted one after another while the data is
being written to the cache. The next node is restarted only after the data
rebalancing is complete. Using the {{KeysToRebalanceLeft}} metric to monitor
rebalancing (see the
[documentation|https://ignite.apache.org/docs/latest/monitoring-metrics/metrics#monitoring-rebalancing]
for more details)
# The application reads some of the data after restarting all the nodes.
*Expected*
No data is lost since there is 1 backup and the nodes are restarted
sequentially after rebalancing is complete.
*Actual*
Sometimes (in our case in more than 50% of cases) there is a "partition data
has been lost" exception on the attempt to read the data.
*Notes*
Tried to create a JUnit reproducer (all nodes within the same JVM) for the
above scenario - no success so far.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17627) Extend MvPartitionStorage API with write intent resolution capabilities
[
https://issues.apache.org/jira/browse/IGNITE-17627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov reassigned IGNITE-17627:
---
Assignee: Semyon Danilov
> Extend MvPartitionStorage API with write intent resolution capabilities
> ---
>
> Key: IGNITE-17627
> URL: https://issues.apache.org/jira/browse/IGNITE-17627
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
>
> Commit of RW transaction is not instantaneous. RO transaction might require
> reads of data that's in the process of being committed. Current API doesn't
> support such scenario.
> RO API in partition storage has only two methods: {{read}} and {{{}scan{}}}.
> h3. Read
> This one is pretty simple. It should return pair of {{binaryRow}} and
> {{{}txId{}}}. After that, caller can check the state of the transaction and
> either return the value or repeat the call.
> There must be a way to hint read method that uncommitted data must be skipped.
> An interesting way of reading data might be required: it there's a write
> intent, but we see a commit done after the timestamp, we can safely proceed
> with reading.
> Unfortunately, such optimization may be heavy on the storage read operations,
> because it requires a "deep" look-ahead request. So, whether or not we
> implement this depends on one thing - how often do we have write intent
> resolution in real RO transactions?
> API is to be defined.
> h3. Scan
> This one is tricky, we can't just return a cursor. Special type of cursor is
> required, and it must allow same read capabilities on each individual element.
> API is to be defined.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16330) Update slf4j to the latest version
[
https://issues.apache.org/jira/browse/IGNITE-16330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16330:
---
Labels: ise (was: )
> Update slf4j to the latest version
> --
>
> Key: IGNITE-16330
> URL: https://issues.apache.org/jira/browse/IGNITE-16330
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: ise
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Some of the extenal Ignite dependencies like Kafka uses more recent version
> of slf4j which is not compatible with the 1.7.7
> {noformat}
> [data-plane-kafka-request-handler-5] ERROR state.change.logger - [Broker
> id=0] Error while processing LeaderAndIsr request correlationId 1 received
> from controller 0 epoch 1 for partition source-dest-3
> java.lang.NoClassDefFoundError: org/slf4j/event/Level
> {noformat}
> We should update sfl4j to the latest version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16387) Improve CDC logging and monitoring
[
https://issues.apache.org/jira/browse/IGNITE-16387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16387:
---
Labels: IEP-59 ise (was: IEP-59)
> Improve CDC logging and monitoring
> --
>
> Key: IGNITE-16387
> URL: https://issues.apache.org/jira/browse/IGNITE-16387
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59, ise
> Fix For: 2.13
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, it's hard to debug and monitor CDC state and settings.
> We need to provide some additional logging and metrics.
> * Debug {{CacheVersionConflictResolverImpl}} implementation which will log
> all conflict resolution
> * Log {{clusterId}} value and creation of
> {{CacheVersionConflictResolverImpl}} with cache name.
> * Log {{clusterId}} value int {{GridCacheVersion#toString}}
> * Add {{conflictResolver}} value in {{CacheView}}.
> * Add {{clusterId}} metric.
> * etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17655) Sql. Provide integration for index scan
[
https://issues.apache.org/jira/browse/IGNITE-17655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17655:
--
Description:
After IGNITE-17431 indexes became a part of query plan. So, now we need to
provide appropriate runtime to make an execution of index scans possible.
Integration points for sql engine will be interface
org.apache.ignite.internal.index.Index and derived
org.apache.ignite.internal.index.SortedIndex. A few changes is required to
those interfaces though: the {{scan}} methods should be reworked in the
following way:
{code:java}
// for Index.java scan should look like this one
Publisher scan(int partId, InternalTransaction tx, BinaryTuple
key, BitSet columnsToInclude)
// for SortedIndex.java range scan should look like this
Publisher scan(int partId, InternalTransaction tx, @Nullable
BinaryTuple leftBound, @Nullable BinaryTuple rightBound, int flags, BitSet
columnsToInclude)
{code}
Besides, we need to reconsider the way we work with an index conditions.
Currently we stick with Ignite-2 way, where search row is represented by a
tuple of the same size as table row, but only indexed columns is set to a
particular values while others are set to null. For example for table (id,
project_id, command_id, name) and index (command_id, project_id) a search tuple
looks like (null, , , null). We
need to rework this in a way to make a search tuple match the actual order of
indexed columns. With that said, the search tuple for the example above should
look like (, ).
Finally, since both table and index scan have the very similar API, it seems
reasonable to rework
{{org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode}} in a way to
cover both cases (table scan and index scan).
was:
After IGNITE-17431 indexes became a part of query plan. So, now we need to
provide appropriate runtime to make an execution of index scans possible.
Integration points for sql engine will be interface
org.apache.ignite.internal.index.Index and derived
org.apache.ignite.internal.index.SortedIndex. A few changes is required to
those interfaces though: the {{scan}} methods should be reworked in the
following way:
{code:java}
// for Index.java scan should look like this one
Publisher scan(int partId, @Nullable InternalTransaction tx,
BinaryTuple key, BitSet columnsToInclude)
// for SortedIndex.java range scan should look like this
Publisher scan(int partId, @Nullable InternalTransaction tx,
BinaryTuple leftBound, BinaryTuple rightBound, int flags, BitSet
columnsToInclude)
{code}
Besides, we need to reconsider the way we work with an index conditions.
Currently we stick with Ignite-2 way, where search row is represented by a
tuple of the same size as table row, but only indexed columns is set to a
particular values while others are set to null. For example for table (id,
project_id, command_id, name) and index (command_id, project_id) a search tuple
looks like (null, , , null). We
need to rework this in a way to make a search tuple match the actual order of
indexed columns. With that said, the search tuple for the example above should
look like (, ).
Finally, since both table and index scan have the very similar API, it seems
reasonable to rework
{{org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode}} in a way to
cover both cases (table scan and index scan).
> Sql. Provide integration for index scan
> ---
>
> Key: IGNITE-17655
> URL: https://issues.apache.org/jira/browse/IGNITE-17655
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> After IGNITE-17431 indexes became a part of query plan. So, now we need to
> provide appropriate runtime to make an execution of index scans possible.
> Integration points for sql engine will be interface
> org.apache.ignite.internal.index.Index and derived
> org.apache.ignite.internal.index.SortedIndex. A few changes is required to
> those interfaces though: the {{scan}} methods should be reworked in the
> following way:
> {code:java}
> // for Index.java scan should look like this one
> Publisher scan(int partId, InternalTransaction tx, BinaryTuple
> key, BitSet columnsToInclude)
> // for SortedIndex.java range scan should look like this
> Publisher scan(int partId, InternalTransaction tx, @Nullable
> BinaryTuple leftBound, @Nullable BinaryTuple rightBound, int flags, BitSet
> columnsToInclude)
> {code}
> Besides, we need to reconsider the way we work with an index conditions.
> Currently we stick with Ignite-2 way, where search row is represented by a
> tuple of the same size as table row, but only indexed columns is set to a
> particular values while others are set to null. For example for table (id,
>
[jira] [Updated] (IGNITE-17656) Race in DistributedProcess#onSingleNodeMessageReceived
[
https://issues.apache.org/jira/browse/IGNITE-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-17656:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Race in DistributedProcess#onSingleNodeMessageReceived
> --
>
> Key: IGNITE-17656
> URL: https://issues.apache.org/jira/browse/IGNITE-17656
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
>
> DistributedProcess#onSingleNodeMessageReceived
> It could be a case when 2 (one of them is the last) messages receives
> simultaneously:
> # Initial state: remaining = \{node0, node1}, singleMsg={}
> # First msg handled, thread stops after releasing the `mux`:
> remaining=\{node0}, singleMsg={}.
> # Second msg handled, thread doesn't stop and: remaining={},
> singleMsg=\{node1}. And finishes process after that.
> # Thread 1 invoked, put message to singleMsg, but process was already
> finished.
>
> Solution is changing both collections (remaining, singleMsg) under the same
> `mux`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17656) Race in DistributedProcess#onSingleNodeMessageReceived
Maksim Timonin created IGNITE-17656:
---
Summary: Race in DistributedProcess#onSingleNodeMessageReceived
Key: IGNITE-17656
URL: https://issues.apache.org/jira/browse/IGNITE-17656
Project: Ignite
Issue Type: Bug
Reporter: Maksim Timonin
Assignee: Maksim Timonin
DistributedProcess#onSingleNodeMessageReceived
It could be a case when 2 (one of them is the last) messages receives
simultaneously:
# Initial state: remaining = \{node0, node1}, singleMsg={}
# First msg handled, thread stops after releasing the `mux`:
remaining=\{node0}, singleMsg={}.
# Second msg handled, thread doesn't stop and: remaining={},
singleMsg=\{node1}. And finishes process after that.
# Thread 1 invoked, put message to singleMsg, but process was already finished.
Solution is changing both collections (remaining, singleMsg) under the same
`mux`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16470) Rollout on walForceArchiveTimeout only if DataEntry loged
[
https://issues.apache.org/jira/browse/IGNITE-16470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16470:
---
Labels: IEP-59 ise (was: IEP-59)
> Rollout on walForceArchiveTimeout only if DataEntry loged
> -
>
> Key: IGNITE-16470
> URL: https://issues.apache.org/jira/browse/IGNITE-16470
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59, ise
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, {{walForceArchiveTimeout}} switch to the new WAL segment even if
> not DataEntry was logged.
> We can perform a switch only if DataEntry was logged so there are new data
> for CDC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17655) Sql. Provide integration for index scan
[
https://issues.apache.org/jira/browse/IGNITE-17655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17655:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Provide integration for index scan
> ---
>
> Key: IGNITE-17655
> URL: https://issues.apache.org/jira/browse/IGNITE-17655
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> After IGNITE-17431 indexes became a part of query plan. So, now we need to
> provide appropriate runtime to make an execution of index scans possible.
> Integration points for sql engine will be interface
> org.apache.ignite.internal.index.Index and derived
> org.apache.ignite.internal.index.SortedIndex. A few changes is required to
> those interfaces though: the {{scan}} methods should be reworked in the
> following way:
> {code:java}
> // for Index.java scan should look like this one
> Publisher scan(int partId, @Nullable InternalTransaction tx,
> BinaryTuple key, BitSet columnsToInclude)
> // for SortedIndex.java range scan should look like this
> Publisher scan(int partId, @Nullable InternalTransaction tx,
> BinaryTuple leftBound, BinaryTuple rightBound, int flags, BitSet
> columnsToInclude)
> {code}
> Besides, we need to reconsider the way we work with an index conditions.
> Currently we stick with Ignite-2 way, where search row is represented by a
> tuple of the same size as table row, but only indexed columns is set to a
> particular values while others are set to null. For example for table (id,
> project_id, command_id, name) and index (command_id, project_id) a search
> tuple looks like (null, , ,
> null). We need to rework this in a way to make a search tuple match the
> actual order of indexed columns. With that said, the search tuple for the
> example above should look like (,
> ).
> Finally, since both table and index scan have the very similar API, it seems
> reasonable to rework
> {{org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode}} in a way to
> cover both cases (table scan and index scan).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17655) Sql. Provide integration for index scan
Konstantin Orlov created IGNITE-17655:
-
Summary: Sql. Provide integration for index scan
Key: IGNITE-17655
URL: https://issues.apache.org/jira/browse/IGNITE-17655
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Konstantin Orlov
After IGNITE-17431 indexes became a part of query plan. So, now we need to
provide appropriate runtime to make an execution of index scans possible.
Integration points for sql engine will be interface
org.apache.ignite.internal.index.Index and derived
org.apache.ignite.internal.index.SortedIndex. A few changes is required to
those interfaces though: the {{scan}} methods should be reworked in the
following way:
{code:java}
// for Index.java scan should look like this one
Publisher scan(int partId, @Nullable InternalTransaction tx,
BinaryTuple key, BitSet columnsToInclude)
// for SortedIndex.java range scan should look like this
Publisher scan(int partId, @Nullable InternalTransaction tx,
BinaryTuple leftBound, BinaryTuple rightBound, int flags, BitSet
columnsToInclude)
{code}
Besides, we need to reconsider the way we work with an index conditions.
Currently we stick with Ignite-2 way, where search row is represented by a
tuple of the same size as table row, but only indexed columns is set to a
particular values while others are set to null. For example for table (id,
project_id, command_id, name) and index (command_id, project_id) a search tuple
looks like (null, , , null). We
need to rework this in a way to make a search tuple match the actual order of
indexed columns. With that said, the search tuple for the example above should
look like (, ).
Finally, since both table and index scan have the very similar API, it seems
reasonable to rework
{{org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode}} in a way to
cover both cases (table scan and index scan).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16523) WALForceArchiveTimeout lead to node fails to restart
[
https://issues.apache.org/jira/browse/IGNITE-16523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16523:
---
Labels: IEP-59 ise (was: IEP-59)
> WALForceArchiveTimeout lead to node fails to restart
>
>
> Key: IGNITE-16523
> URL: https://issues.apache.org/jira/browse/IGNITE-16523
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: IEP-59, ise
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When WALForceArchiveTimeout set node failed to restart.
> {code:java}
> /** */
> @RunWith(Parameterized.class)
> public class RestartWithWalForceArchiveTimeoutTest extends
> GridCommonAbstractTest {
> /** */
> @Parameterized.Parameter
> public WALMode walMode;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setConsistentId(igniteInstanceName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setWalMode(walMode)
> .setWalForceArchiveTimeout(60 * 60 * 1000) // 1 hour to make sure
> auto archive will not work.
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Parameterized.Parameters(name = "walMode={0}")
> public static Collection parameters() {
> return EnumSet.of(WALMode.FSYNC, WALMode.LOG_ONLY,
> WALMode.BACKGROUND);
> }
> /** */
> @Test
> public void testRestart() throws Exception {
> stopAllGrids(true);
> cleanPersistenceDir();
> Supplier restart = () -> {
> stopAllGrids(true);
> try {
> IgniteEx ign = startGrid(getConfiguration("ignite-0"));
> ign.cluster().state(ACTIVE);
> return ign;
> }
> catch (Exception e) {
> throw new RuntimeException(e);
> }
> };
> IgniteEx ign = restart.get();
> IgniteCache cache =
> ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 0, 100);
> ign = restart.get();
> cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 100, 200);
> ign = restart.get();
> cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 200, 300);
> restart.get();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16019) With authentication enabled. Failure of a node when starting the next one with a service in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-16019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16019:
---
Labels: ise (was: )
> With authentication enabled. Failure of a node when starting the next one
> with a service in the configuration
> -
>
> Key: IGNITE-16019
> URL: https://issues.apache.org/jira/browse/IGNITE-16019
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergei Ryzhov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: ise
> Fix For: 2.12
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With authentication enabled
> Failure of a node when starting the next one with a service in the
> configuration
> Reproducer
> {code:java}
> public class ServiceDeployTest extends AbstractSecurityTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> ServiceConfiguration srvcCfg = new ServiceConfiguration();
> srvcCfg.setName("CounterService");
> srvcCfg.setMaxPerNodeCount(1);
> srvcCfg.setTotalCount(1);
> srvcCfg.setService(new CounterServiceImpl());
> cfg.setServiceConfiguration(srvcCfg);
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrid(0);
> startGrid(1);
> assertEquals(2, G.allGrids().size());
> }
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> cleanPersistenceDir();
> }
> /** */
> public static class CounterServiceImpl implements Service {
> /** Is started. */
> volatile boolean isStarted = false;
> /** Cntr. */
> private AtomicInteger cntr = null;
> /** {@inheritDoc} */
> @Override public void cancel() {
> isStarted = false;
> }
> /** {@inheritDoc} */
> @Override public void init() throws Exception {
> isStarted = true;
> cntr = new AtomicInteger();
> }
> /** {@inheritDoc} */
> @Override public void execute() throws Exception {
> while (isStarted) {
> cntr.incrementAndGet();
> TimeUnit.SECONDS.sleep(1);
> }
> }
> }
> }
> {code}
> ERROR
> {code:java}
> [2021-11-29
> 17:20:51,883][ERROR][tcp-disco-msg-worker-[crd]-#3%service.ServiceDeployTest0%-#66%service.ServiceDeployTest0%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed
> to find security context for subject with given ID :
> b9a59be8-3ff5-48b5-bd1e-5927f7a1]]
> java.lang.IllegalStateException: Failed to find security context for subject
> with given ID : b9a59be8-3ff5-48b5-bd1e-5927f7a1
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onJoiningNodeDataReceived(IgniteServiceProcessor.java:379)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:1054)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2201)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:5116)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:4749)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:3233)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2920)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:8106)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:3091)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
>
[jira] [Updated] (IGNITE-16587) putAllConflict removeAllConfict lost version for transactional caches
[
https://issues.apache.org/jira/browse/IGNITE-16587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16587:
---
Labels: IEP-59 ise ise.lts (was: IEP-59 ise.lts)
> putAllConflict removeAllConfict lost version for transactional caches
> -
>
> Key: IGNITE-16587
> URL: https://issues.apache.org/jira/browse/IGNITE-16587
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59, ise, ise.lts
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{IgniteInternalCache}} contains methods {{putAllConfict}},
> {{removeAllConfict}} that can be used to perform put, remove operations with
> entry {{GridCacheVersion}}.
> But for transactional caches conflict version lost.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14366) Support separate JVM options for ignite-cdc.sh and ignite.sh
[
https://issues.apache.org/jira/browse/IGNITE-14366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-14366:
---
Labels: IEP-59 ise (was: IEP-59)
> Support separate JVM options for ignite-cdc.sh and ignite.sh
>
>
> Key: IGNITE-14366
> URL: https://issues.apache.org/jira/browse/IGNITE-14366
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59, ise
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, ignite-cdc.sh just reuse ignite.sh with it's own main class name
> ({{org.apache.ignite.cdc.CommandLineStartup}})
> Should fix it and provide a way to separate configuration ignite and cdc
> applications.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-7153) Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for values > 8kb
[
https://issues.apache.org/jira/browse/IGNITE-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-7153:
--
Labels: ise redis (was: redis)
> Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for
> values > 8kb
> ---
>
> Key: IGNITE-7153
> URL: https://issues.apache.org/jira/browse/IGNITE-7153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.3
> Environment: Win, PHP 7, php_redis-3.1.1-7.0
>Reporter: Alexey Popov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: ise, redis
> Fix For: 2.14
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Exception:
> {noformat}
> [15:03:23,690][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=28
> lim=8192 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0,
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
> [name=grid-nio-worker-tcp-rest-0, igniteInstanceName=null, finished=false,
> hashCode=396395638, interrupted=false,
> runner=grid-nio-worker-tcp-rest-0-#36]]], writeBuf=null, readBuf=null,
> inRecovery=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/127.0.0.1:6380, rmtAddr=/127.0.0.1:51794, createTime=1512734602674,
> closeTime=0, bytesSent=0, bytesRcvd=8192, bytesSent0=0, bytesRcvd0=8192,
> sndSchedTime=1512734602674, lastSndTime=1512734602674,
> lastRcvTime=1512734602674, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser
> [jdkMarshaller=JdkMarshaller [], routerClient=false], directMode=false]],
> accepted=true]]]
> java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3392)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1096)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2272)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> [15:03:23,691][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: null
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2296)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
> at
>
[jira] [Commented] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.
[
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601742#comment-17601742
]
Nikita Amelchev commented on IGNITE-17610:
--
[~xtern], LGTM.
> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-43
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel the snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that
> displays an *operation ID* that can be used to cancel any snapshot operation
> in progress.
> h5. So the proposal - make snapshot-commands syntax simple and universal
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel --id operationId
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17654) Set executable flags to gradlew and gradlew.bat
[ https://issues.apache.org/jira/browse/IGNITE-17654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601730#comment-17601730 ] Semyon Danilov commented on IGNITE-17654: - LGTM! > Set executable flags to gradlew and gradlew.bat > --- > > Key: IGNITE-17654 > URL: https://issues.apache.org/jira/browse/IGNITE-17654 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Title says it all -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17654) Set executable flags to gradlew and gradlew.bat
[ https://issues.apache.org/jira/browse/IGNITE-17654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-17654: Reviewer: Semyon Danilov > Set executable flags to gradlew and gradlew.bat > --- > > Key: IGNITE-17654 > URL: https://issues.apache.org/jira/browse/IGNITE-17654 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Title says it all -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17654) Set executable flags to gradlew and gradlew.bat
[ https://issues.apache.org/jira/browse/IGNITE-17654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-17654: -- Assignee: Ivan Bessonov > Set executable flags to gradlew and gradlew.bat > --- > > Key: IGNITE-17654 > URL: https://issues.apache.org/jira/browse/IGNITE-17654 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > Title says it all -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17654) Set executable flags to gradlew and gradlew.bat
Ivan Bessonov created IGNITE-17654: -- Summary: Set executable flags to gradlew and gradlew.bat Key: IGNITE-17654 URL: https://issues.apache.org/jira/browse/IGNITE-17654 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Title says it all -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17653) Fix gradle build
[ https://issues.apache.org/jira/browse/IGNITE-17653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-17653: --- Fix Version/s: 3.0.0-alpha6 > Fix gradle build > - > > Key: IGNITE-17653 > URL: https://issues.apache.org/jira/browse/IGNITE-17653 > Project: Ignite > Issue Type: Bug > Components: build, ignite-3 >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > After IGNITE-15931 and IGNITE-16040 some dependencies was changed. Need to > sync it in gradle -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17653) Fix gradle build
[ https://issues.apache.org/jira/browse/IGNITE-17653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-17653: --- Labels: ignite-3 (was: ) > Fix gradle build > - > > Key: IGNITE-17653 > URL: https://issues.apache.org/jira/browse/IGNITE-17653 > Project: Ignite > Issue Type: Bug > Components: build, ignite-3 >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > After IGNITE-15931 and IGNITE-16040 some dependencies was changed. Need to > sync it in gradle -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17297) Thin 3.0: Adopt BinaryTuple format in transport layer
[ https://issues.apache.org/jira/browse/IGNITE-17297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17297: Description: BinaryTuple (see IEP-92) is a common format for data exchange in Ignite 3. Adopt it in the thin client protocol to be able to avoid intermediate conversions when exchanging data. For example, we should be able to write SQL query results to the client socket directly as byte[]. Update IEP-76 when done. was: BinaryTuple (see IEP-92) is a common format for data exchange in Ignite 3. Adopt it in the thin client protocol to be able to avoid intermediate conversions when exchanging data. For example, we should be able to write SQL query results to the client socket directly as byte[]. > Thin 3.0: Adopt BinaryTuple format in transport layer > - > > Key: IGNITE-17297 > URL: https://issues.apache.org/jira/browse/IGNITE-17297 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-92, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > BinaryTuple (see IEP-92) is a common format for data exchange in Ignite 3. > Adopt it in the thin client protocol to be able to avoid intermediate > conversions when exchanging data. > For example, we should be able to write SQL query results to the client > socket directly as byte[]. > > Update IEP-76 when done. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17523) Stabilize and cleanup ignite3_tx branch with rw logic implemented
[ https://issues.apache.org/jira/browse/IGNITE-17523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin reassigned IGNITE-17523: Assignee: Alexander Lapin > Stabilize and cleanup ignite3_tx branch with rw logic implemented > - > > Key: IGNITE-17523 > URL: https://issues.apache.org/jira/browse/IGNITE-17523 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3, transaction3_rw > Time Spent: 10m > Remaining Estimate: 0h > > It's required to cleanup all obsolete stuff > * TxManager > * VersionedRowStore > * todos without tickets > * etc > and stabilize failing tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17653) Fix gradle build
[ https://issues.apache.org/jira/browse/IGNITE-17653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-17653: -- Assignee: Mikhail Pochatkin > Fix gradle build > - > > Key: IGNITE-17653 > URL: https://issues.apache.org/jira/browse/IGNITE-17653 > Project: Ignite > Issue Type: Bug > Components: build, ignite-3 >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > > After IGNITE-15931 and IGNITE-16040 some dependencies was changed. Need to > sync it in gradle -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17608) Fix pmd and checkstyle for gradle build
[ https://issues.apache.org/jira/browse/IGNITE-17608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-17608: -- Assignee: Mikhail Pochatkin > Fix pmd and checkstyle for gradle build > --- > > Key: IGNITE-17608 > URL: https://issues.apache.org/jira/browse/IGNITE-17608 > Project: Ignite > Issue Type: Bug > Components: build, ignite-3 >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17653) Fix gradle build
Mikhail Pochatkin created IGNITE-17653: -- Summary: Fix gradle build Key: IGNITE-17653 URL: https://issues.apache.org/jira/browse/IGNITE-17653 Project: Ignite Issue Type: Bug Components: build, ignite-3 Reporter: Mikhail Pochatkin After IGNITE-15931 and IGNITE-16040 some dependencies was changed. Need to sync it in gradle -- This message was sent by Atlassian Jira (v8.20.10#820010)
