[jira] [Updated] (IGNITE-19483) Transform TableManager and IndexManager to internally work against Catalog event types
[ https://issues.apache.org/jira/browse/IGNITE-19483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-19483: --- Description: Currently, when an event like 'table was added to configuration' happens, the listener polls the table config by itself and then uses it to create the table. This should be changed: the table configuration object should be converted to an object from Catalog domain and pushed to the listeners. Same should be done to indices. Requires investigation. Also, we need to stop passing configuration to deeply-nested components (like storages). Also requires investigation. was: Currently, when an event like 'table was added to configuration' happens, the listener pools the table config by itself and then uses it to create the table. This should be changed: the table configuration object should be converted to an object from Catalog domain and pushed to the listeners. Same should be done to indices. Requires investigation. Also, we need to stop passing configuration to deeply-nested components (like storages). Also requires investigation. > Transform TableManager and IndexManager to internally work against Catalog > event types > -- > > Key: IGNITE-19483 > URL: https://issues.apache.org/jira/browse/IGNITE-19483 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, when an event like 'table was added to configuration' happens, the > listener polls the table config by itself and then uses it to create the > table. > This should be changed: the table configuration object should be converted to > an object from Catalog domain and pushed to the listeners. > Same should be done to indices. > Requires investigation. > Also, we need to stop passing configuration to deeply-nested components (like > storages). Also requires investigation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19629) Missing few metrics in new metrics system
Nikolay created IGNITE-19629: Summary: Missing few metrics in new metrics system Key: IGNITE-19629 URL: https://issues.apache.org/jira/browse/IGNITE-19629 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.15 Reporter: Nikolay In apache ignite 2.15 CacheMetricsMXBean was removed. Legacy metrics system could give us some valuable metrics regarding cache's health. For example, [isValidForReading|https://ignite.apache.org/releases/2.14.0/javadoc/org/apache/ignite/mxbean/CacheMetricsMXBean.html#isValidForReading–] [isValidForWriting|https://ignite.apache.org/releases/2.14.0/javadoc/org/apache/ignite/cache/CacheMetrics.html#isValidForWriting–] In the latest version of apache ignite we miss such metrics, it is hard to understand now when there is a lost_partition situation in caches. Previously these metrics were telling us to go and fix such caches. Can we bring them back? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19452) Blacklist for non-marshallable classes
[ https://issues.apache.org/jira/browse/IGNITE-19452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-19452: - Fix Version/s: 3.0.0-beta2 > Blacklist for non-marshallable classes > -- > > Key: IGNITE-19452 > URL: https://issues.apache.org/jira/browse/IGNITE-19452 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Following IGNITE-19451, we should ban classes like BinaryTuple, > BinaryTuplePrefix, from being declared as marshallable. Blacklist mechanism > is proposed. > We could also include classes like List/Collection into it, or even Object. > Natively marshallable classes like UUID must be banned as well. > I'd go as far as banning boxed primitives, but they lack native support, so > it's up to a developer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19630) Convert default value from Column to TableColumnDescriptor
Roman Puchkovskiy created IGNITE-19630: -- Summary: Convert default value from Column to TableColumnDescriptor Key: IGNITE-19630 URL: https://issues.apache.org/jira/browse/IGNITE-19630 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 In both cases, we must support both constants and function calls -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19631) No way to pass JVM options when using bin/ignite3db
Ivan Artukhov created IGNITE-19631:
--
Summary: No way to pass JVM options when using bin/ignite3db
Key: IGNITE-19631
URL: https://issues.apache.org/jira/browse/IGNITE-19631
Project: Ignite
Issue Type: Bug
Reporter: Ivan Artukhov
There is no way to set custom JVM options when starting an Ignite node via
`bin/ignite3db` script.
The {{${IGNITE_HOME}/etc/vars.env}} file contains the
{{IGNITE3_EXTRA_JVM_ARGS}} parameter, but currently its value is placed after
the {{IgniteRunner}} in the command-line which is wrong. See
[bootstrap-functions.sh|https://github.com/apache/ignite-3/blob/ae3c4660ab9ae0be9a4f4bef84b002e9e392c243/packaging/common/bootstrap-functions.sh#L51].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19271) Persist revision-safeTime mapping in meta-storage
[
https://issues.apache.org/jira/browse/IGNITE-19271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov reassigned IGNITE-19271:
---
Assignee: Semyon Danilov
> Persist revision-safeTime mapping in meta-storage
> -
>
> Key: IGNITE-19271
> URL: https://issues.apache.org/jira/browse/IGNITE-19271
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
>
> IEP-98 states:
> {code:java}
> When creating a message M telling the cluster about a schema update
> activation moment, choose the message timestamp Tm (moving safeTime forward)
> equal to Now, but assign Tu (activation moment) contained in that M to be
> Tm+DD {code}
> This is hard to achieve.
> h3. Problem
> We need {{{}Tu==Tm+DD{}}}. Right now, with what we have in IGNITE-19028, it's
> not straightforward. This is because we have too many actors:
> * There's a {_}client{_}, that chooses Tu, because it's the only actor that
> can affect message content.
> * There's a meta-storage {_}lease-holder{_}, or {_}leader{_}, that chooses
> Tm.
> * There's everybody else, who expect a correspondence between Tu and Tm.
> First two actors are important, because they have independent clocks, but
> must coordinate the same event. This is impossible with described protocol.
> h3. Discussion
> Let's consider these two solutions:
> # Client generates Tm.
> # Meta-storage generates Tu.
> Option 1 is out of question, there must be only a single node at any given
> moment in time, that's responsible for the linear order of time in messages.
> What about option 2? Since meta-storage doesn't know anything about commands
> semantics, it can't really generate any data. So this solution doesn't work
> either.
> h3. Solution
> Combined solution could be the following:
> * Client sends DD as part of the command (this is not a constant, user _can_
> configure it, if they really feel like doing it)
> * Meta-storage generates {{Tm}}
> * Every node, upon receiving the update, calculates {{Tu}}
> This could work, if nodes would have never been restarted. There's one
> problem that needs to be solved: recovering the values of {{Tm}} from the
> (old) data upon node restart.
> This can be achieved by persisting safeTime along with revision as a part of
> metadata, that can be retrieved back through the meta-storage service API.
> In other words:
> 1. Client sends
> {code:java}
> schema.latest = 5
> schema.5.data = ...
> schema.5.dd = 30s{code}
> 2. Lease-holder adds meta-data to the command:
> {code:java}
> safeTime = 10:10
> {code}
> 3. Meta-storage listener writes the data:
> {code:java}
> revision = 33
> schema.latest = 5
> schema.5.data = ...
> schema.5.dd = 30s
> revision.33.safeTime = 10:10:00{code}
>
> How can you read {{{}Tu{}}}:
> * read "{{{}schema.5.dd"{}}};
> * read its revision, it's 33;
> * read a timestamp of revision 33 via specialized API;
> * add two values together.
> h3. Implications and restrictions
> There's a cleanup process in the meta-storage. It will eventually remove any
> "revision.x.safeTime" values, because corresponding revision became obsolete.
> But, we should somehow preserve timestamps of revisions that are used by
> schemas. Such behaviour can be achieved, if components can reserve a
> revision, and meta-storage can't compact it unless the reservation has been
> revoked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-19271) Persist revision-safeTime mapping in meta-storage
[
https://issues.apache.org/jira/browse/IGNITE-19271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov resolved IGNITE-19271.
-
Fix Version/s: 3.0.0-beta2
Resolution: Fixed
Fixed by IGNITE-19532
> Persist revision-safeTime mapping in meta-storage
> -
>
> Key: IGNITE-19271
> URL: https://issues.apache.org/jira/browse/IGNITE-19271
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IEP-98 states:
> {code:java}
> When creating a message M telling the cluster about a schema update
> activation moment, choose the message timestamp Tm (moving safeTime forward)
> equal to Now, but assign Tu (activation moment) contained in that M to be
> Tm+DD {code}
> This is hard to achieve.
> h3. Problem
> We need {{{}Tu==Tm+DD{}}}. Right now, with what we have in IGNITE-19028, it's
> not straightforward. This is because we have too many actors:
> * There's a {_}client{_}, that chooses Tu, because it's the only actor that
> can affect message content.
> * There's a meta-storage {_}lease-holder{_}, or {_}leader{_}, that chooses
> Tm.
> * There's everybody else, who expect a correspondence between Tu and Tm.
> First two actors are important, because they have independent clocks, but
> must coordinate the same event. This is impossible with described protocol.
> h3. Discussion
> Let's consider these two solutions:
> # Client generates Tm.
> # Meta-storage generates Tu.
> Option 1 is out of question, there must be only a single node at any given
> moment in time, that's responsible for the linear order of time in messages.
> What about option 2? Since meta-storage doesn't know anything about commands
> semantics, it can't really generate any data. So this solution doesn't work
> either.
> h3. Solution
> Combined solution could be the following:
> * Client sends DD as part of the command (this is not a constant, user _can_
> configure it, if they really feel like doing it)
> * Meta-storage generates {{Tm}}
> * Every node, upon receiving the update, calculates {{Tu}}
> This could work, if nodes would have never been restarted. There's one
> problem that needs to be solved: recovering the values of {{Tm}} from the
> (old) data upon node restart.
> This can be achieved by persisting safeTime along with revision as a part of
> metadata, that can be retrieved back through the meta-storage service API.
> In other words:
> 1. Client sends
> {code:java}
> schema.latest = 5
> schema.5.data = ...
> schema.5.dd = 30s{code}
> 2. Lease-holder adds meta-data to the command:
> {code:java}
> safeTime = 10:10
> {code}
> 3. Meta-storage listener writes the data:
> {code:java}
> revision = 33
> schema.latest = 5
> schema.5.data = ...
> schema.5.dd = 30s
> revision.33.safeTime = 10:10:00{code}
>
> How can you read {{{}Tu{}}}:
> * read "{{{}schema.5.dd"{}}};
> * read its revision, it's 33;
> * read a timestamp of revision 33 via specialized API;
> * add two values together.
> h3. Implications and restrictions
> There's a cleanup process in the meta-storage. It will eventually remove any
> "revision.x.safeTime" values, because corresponding revision became obsolete.
> But, we should somehow preserve timestamps of revisions that are used by
> schemas. Such behaviour can be achieved, if components can reserve a
> revision, and meta-storage can't compact it unless the reservation has been
> revoked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19628) Add IndexQuery to performance statistics
[ https://issues.apache.org/jira/browse/IGNITE-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-19628: - Labels: ise (was: ) > Add IndexQuery to performance statistics > > > Key: IGNITE-19628 > URL: https://issues.apache.org/jira/browse/IGNITE-19628 > Project: Ignite > Issue Type: Task >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add IndexQuery to performance statistics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19451) Don't marshal binary tuples or binary rows
[
https://issues.apache.org/jira/browse/IGNITE-19451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev reassigned IGNITE-19451:
Assignee: Aleksandr Polovtcev
> Don't marshal binary tuples or binary rows
> --
>
> Key: IGNITE-19451
> URL: https://issues.apache.org/jira/browse/IGNITE-19451
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Messages like
> {{org.apache.ignite.internal.table.distributed.replication.request.ScanRetrieveBatchReplicaRequest}}
> declare tuples/rows as marshalable objects.
> This is bad for the footprint size - every tuple also encodes its schema,
> which makes the payload orders of magnitude bigger than it should be. We need
> to provide alternative transferable classes and refactor existing messages.
>
> It would also be nice to have benchmarks, so that we could check the
> before/after difference. There's already
> org.apache.ignite.internal.network.SerializationMicroBenchmark, but it's for
> UOS specifically, we should probably do something analogous, with the ability
> to customize message type
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19632) .NET: Thin 3.0: Optimize Data Streamer for single connection use case
[ https://issues.apache.org/jira/browse/IGNITE-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19632: Description: Optimize .NET client data streamer for a use case when only one connection exists. In this case we don't need to deal with partition awareness and per-node buffers. This can be detected automatically or by a flag in DataStreamerOptions. was: Optimize Java client data streamer for a use case when only one connection exists. In this case we don't need to deal with partition awareness and per-node buffers. This can be detected automatically or by a flag in DataStreamerOptions. > .NET: Thin 3.0: Optimize Data Streamer for single connection use case > - > > Key: IGNITE-19632 > URL: https://issues.apache.org/jira/browse/IGNITE-19632 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Optimize .NET client data streamer for a use case when only one connection > exists. In this case we don't need to deal with partition awareness and > per-node buffers. > This can be detected automatically or by a flag in DataStreamerOptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19632) .NET: Thin 3.0: Optimize Data Streamer for single connection use case
[ https://issues.apache.org/jira/browse/IGNITE-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19632: Labels: .NET iep-102 ignite-3 (was: iep-102 ignite-3) > .NET: Thin 3.0: Optimize Data Streamer for single connection use case > - > > Key: IGNITE-19632 > URL: https://issues.apache.org/jira/browse/IGNITE-19632 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Optimize .NET client data streamer for a use case when only one connection > exists. In this case we don't need to deal with partition awareness and > per-node buffers. > This can be detected automatically or by a flag in DataStreamerOptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19632) .NET: Thin 3.0: Optimize Data Streamer for single connection use case
Pavel Tupitsyn created IGNITE-19632: --- Summary: .NET: Thin 3.0: Optimize Data Streamer for single connection use case Key: IGNITE-19632 URL: https://issues.apache.org/jira/browse/IGNITE-19632 Project: Ignite Issue Type: Task Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Optimize Java client data streamer for a use case when only one connection exists. In this case we don't need to deal with partition awareness and per-node buffers. This can be detected automatically or by a flag in DataStreamerOptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19605) ItDeploymentUnitTest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-19605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728662#comment-17728662
]
Aleksandr commented on IGNITE-19605:
This test fail happens when previous test used connect command without paired
disconnect, which leaves the periodic session task running.
When starting the nodes in the next test, it so happens that the request for
the node configuration from the JdbcUrlRegistryImpl or any other periodic task
is received while the Micronaut's context is starting in the RestController for
the second node. In this case the
io.micronaut.core.convert.ConversionService#SHARED is cleared and is not yet
populated.
It's not entirely clear what happens next, but most probably the HTTP server
caches the state where there's no corresponding type converter and this leaves
the node in the broken state.
It doesn't seem possible to properly fix this outside of Micronaut, so there's
just a workaround which adds missing disconnect calls.
> ItDeploymentUnitTest is flaky
> -
>
> Key: IGNITE-19605
> URL: https://issues.apache.org/jira/browse/IGNITE-19605
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Even after the IGNITE-19139 was fixed, the {{ItDeploymentUnitTest}} is still
> flaky, the root cause is still looks like the Micronaut's shared converters
> registry. We should look for a better workaround.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19633) Exclude org.apache.calcite.plan.volcano from Javadoc
Mikhail Pochatkin created IGNITE-19633: -- Summary: Exclude org.apache.calcite.plan.volcano from Javadoc Key: IGNITE-19633 URL: https://issues.apache.org/jira/browse/IGNITE-19633 Project: Ignite Issue Type: Improvement Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19452) Blacklist for non-marshallable classes
[ https://issues.apache.org/jira/browse/IGNITE-19452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-19452: - Reviewer: Ivan Bessonov > Blacklist for non-marshallable classes > -- > > Key: IGNITE-19452 > URL: https://issues.apache.org/jira/browse/IGNITE-19452 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Following IGNITE-19451, we should ban classes like BinaryTuple, > BinaryTuplePrefix, from being declared as marshallable. Blacklist mechanism > is proposed. > We could also include classes like List/Collection into it, or even Object. > Natively marshallable classes like UUID must be banned as well. > I'd go as far as banning boxed primitives, but they lack native support, so > it's up to a developer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19634) Fix PMD error when building the SQL module
[ https://issues.apache.org/jira/browse/IGNITE-19634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-19634: - Labels: ignite-3 (was: ) > Fix PMD error when building the SQL module > -- > > Key: IGNITE-19634 > URL: https://issues.apache.org/jira/browse/IGNITE-19634 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Trivial > Labels: ignite-3 > > When build -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19634) Fix PMD error when building the SQL module
[ https://issues.apache.org/jira/browse/IGNITE-19634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-19634: - Ignite Flags: (was: Docs Required,Release Notes Required) > Fix PMD error when building the SQL module > -- > > Key: IGNITE-19634 > URL: https://issues.apache.org/jira/browse/IGNITE-19634 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Trivial > Labels: ignite-3 > > When build -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19634) Fix PMD error when building the SQL module
Aleksandr Polovtcev created IGNITE-19634: Summary: Fix PMD error when building the SQL module Key: IGNITE-19634 URL: https://issues.apache.org/jira/browse/IGNITE-19634 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19634) Fix PMD error when building the SQL module
[ https://issues.apache.org/jira/browse/IGNITE-19634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-19634: - Description: When build > Fix PMD error when building the SQL module > -- > > Key: IGNITE-19634 > URL: https://issues.apache.org/jira/browse/IGNITE-19634 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Trivial > > When build -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19634) Fix PMD error when building the SQL module
[
https://issues.apache.org/jira/browse/IGNITE-19634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-19634:
-
Description:
When building the project, I get the following error when executing the
{{:ignite-sql-engine:pmdMain}} task:
{noformat}
PMDException: Error while parsing
modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/exec/exp/RexToLixTranslator.java
{noformat}
Looks like updating the PMD plugin solves this issue.
was:When build
> Fix PMD error when building the SQL module
> --
>
> Key: IGNITE-19634
> URL: https://issues.apache.org/jira/browse/IGNITE-19634
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Trivial
> Labels: ignite-3
>
> When building the project, I get the following error when executing the
> {{:ignite-sql-engine:pmdMain}} task:
> {noformat}
> PMDException: Error while parsing
> modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/exec/exp/RexToLixTranslator.java
> {noformat}
> Looks like updating the PMD plugin solves this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19483) Transform TableManager and IndexManager to internally work against Catalog event types
[ https://issues.apache.org/jira/browse/IGNITE-19483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-19483: Assignee: Kirill Tkalenko (was: Roman Puchkovskiy) > Transform TableManager and IndexManager to internally work against Catalog > event types > -- > > Key: IGNITE-19483 > URL: https://issues.apache.org/jira/browse/IGNITE-19483 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, when an event like 'table was added to configuration' happens, the > listener polls the table config by itself and then uses it to create the > table. > This should be changed: the table configuration object should be converted to > an object from Catalog domain and pushed to the listeners. > Same should be done to indices. > Requires investigation. > Also, we need to stop passing configuration to deeply-nested components (like > storages). Also requires investigation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19630) Convert default value from Column to TableColumnDescriptor
[ https://issues.apache.org/jira/browse/IGNITE-19630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko resolved IGNITE-19630. -- Resolution: Fixed > Convert default value from Column to TableColumnDescriptor > -- > > Key: IGNITE-19630 > URL: https://issues.apache.org/jira/browse/IGNITE-19630 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In both cases, we must support both constants and function calls -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19622) [IEP-104] Add Realtime CDC buffer
[ https://issues.apache.org/jira/browse/IGNITE-19622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-19622: Description: Realtime CDC buffer requirements: # Size is configured with DataStorageConfiguration#cdcBufSize # Must be FIFO # Is filled by the wal-syncer-thread with ReadSegment data # API: offer, poll, clear, currentSize # After it become full it has not receive any data, even data is polled. For this ticket, the buffer must be filled if CDC option is enabled in IgniteConfiguration. If it is full, then log stop accept new data, log warn, clear the buffer. This should work for ordinary WAL configuration (mmap=true, no FULL_SYNC) was: Realtime CDC buffer requirements: # Size is configured with DataStorageConfiguration#cdcBufSize # Must be FIFO # Is filled by the wal-syncer-thread with ReadSegment data # API: offer, poll, clear, currentSize # After it become full it has not receive any data, even data is polled. > [IEP-104] Add Realtime CDC buffer > - > > Key: IGNITE-19622 > URL: https://issues.apache.org/jira/browse/IGNITE-19622 > Project: Ignite > Issue Type: Sub-task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-104, ise > > Realtime CDC buffer requirements: > # Size is configured with DataStorageConfiguration#cdcBufSize > # Must be FIFO > # Is filled by the wal-syncer-thread with ReadSegment data > # API: offer, poll, clear, currentSize > # After it become full it has not receive any data, even data is polled. > For this ticket, the buffer must be filled if CDC option is enabled in > IgniteConfiguration. If it is full, then log stop accept new data, log warn, > clear the buffer. > This should work for ordinary WAL configuration (mmap=true, no FULL_SYNC) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19596) Partition creation fails with NSFE
[
https://issues.apache.org/jira/browse/IGNITE-19596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728689#comment-17728689
]
Roman Puchkovskiy commented on IGNITE-19596:
The patch looks good to me, thanks!
> Partition creation fails with NSFE
> --
>
> Key: IGNITE-19596
> URL: https://issues.apache.org/jira/browse/IGNITE-19596
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> You can reproduce it by creating tables in a loop. I did that with fsync
> disabled.
> {noformat}
> java.util.concurrent.CompletionException: java.io.UncheckedIOException:
> java.nio.file.NoSuchFileException:
> build/work/ItSqlLogicTest/static_2773294090214/sqllogic0/db/db/table-89/part-6-delta-0.bin.tmp
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:683)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> at
> java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
> at
> org.apache.ignite.internal.storage.util.MvPartitionStorages.create(MvPartitionStorages.java:122)
> at
> org.apache.ignite.internal.storage.pagememory.AbstractPageMemoryTableStorage.lambda$createMvPartition$5(AbstractPageMemoryTableStorage.java:173)
> at
> org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:877)
> at
> org.apache.ignite.internal.storage.pagememory.AbstractPageMemoryTableStorage.busy(AbstractPageMemoryTableStorage.java:229)
> at
> org.apache.ignite.internal.storage.pagememory.AbstractPageMemoryTableStorage.createMvPartition(AbstractPageMemoryTableStorage.java:173)
> at
> org.apache.ignite.internal.table.distributed.TableManager.getOrCreatePartitionStorages(TableManager.java:2288)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$updateAssignmentInternal$21(TableManager.java:682)
> at
> org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:877)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$updateAssignmentInternal$22(TableManager.java:648)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> org.apache.ignite.internal.causality.BaseVersionedValue.lambda$copyState$6(BaseVersionedValue.java:307)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
> at
> java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251)
> at
> org.apache.ignite.internal.causality.BaseVersionedValue.copyState(BaseVersionedValue.java:303)
> at
> org.apache.ignite.internal.causality.BaseVersionedValue.complete(BaseVersionedValue.java:189)
> at
> org.apache.ignite.internal.causality.IncrementalVersionedValue.lambda$completeInternal$1(IncrementalVersionedValue.java:236)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$sendWithRetry$39(RaftGroupServiceImpl.java:540)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> org.apache.ignite.network.DefaultMessagingService.onInvokeResponse(DefaultMessagingService.java:371)
> at
> org.apache.ignite.network.DefaultMessagingService.send0(DefaultMessagingService.java:194)
> at
> org.apache.ignite.
[jira] [Assigned] (IGNITE-19611) Drop ifExists flag from Catalog actions params
[
https://issues.apache.org/jira/browse/IGNITE-19611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-19611:
-
Assignee: Andrey Mashenkov
> Drop ifExists flag from Catalog actions params
> --
>
> Key: IGNITE-19611
> URL: https://issues.apache.org/jira/browse/IGNITE-19611
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3, tech-debt
>
> Let's drop dead code from {{org.apache.ignite.internal.catalog.commands}}
> classes
> E.g. AbstractTableCommandParams.ifTableExists
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19635) [IEP-104] Add cdc worker thread to handle captured data
Maksim Timonin created IGNITE-19635: --- Summary: [IEP-104] Add cdc worker thread to handle captured data Key: IGNITE-19635 URL: https://issues.apache.org/jira/browse/IGNITE-19635 Project: Ignite Issue Type: Sub-task Reporter: Maksim Timonin CdcWorker for this ticket: # Initialized if CDC is enabled in IgniteConfiguration # Consumes the CdcBuffer, delivers data to CdcConsumer # Prepares CdcEvents from byte array (incl filtering WALRecords) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19636) [IEP-104] Add CdcConsumerState
Maksim Timonin created IGNITE-19636: --- Summary: [IEP-104] Add CdcConsumerState Key: IGNITE-19636 URL: https://issues.apache.org/jira/browse/IGNITE-19636 Project: Ignite Issue Type: Sub-task Reporter: Maksim Timonin # CdcWorker should persist state into the local MetaStorage (by command from CdcConsumer) # It should be filled with OFF flag when the buffer is full. # CdcWorker should check the state during intialization. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19637) [IEP-104] Restore CDC state during ignite node start up
Maksim Timonin created IGNITE-19637: --- Summary: [IEP-104] Restore CDC state during ignite node start up Key: IGNITE-19637 URL: https://issues.apache.org/jira/browse/IGNITE-19637 Project: Ignite Issue Type: Sub-task Reporter: Maksim Timonin On Ignite node startup it should fill the buffer with data since last CdcConsumerState with replaying existing WAL segments. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19638) [IEP-104] Add metrics for Realtime CDC
Maksim Timonin created IGNITE-19638: --- Summary: [IEP-104] Add metrics for Realtime CDC Key: IGNITE-19638 URL: https://issues.apache.org/jira/browse/IGNITE-19638 Project: Ignite Issue Type: Sub-task Reporter: Maksim Timonin # Actual status # Actual buffer size # Actual WAL segment capturing # Sent entries/segments # Lag between head of the buffer and actual data -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19639) [IEP-104] Add Cdc WAL records
Maksim Timonin created IGNITE-19639: --- Summary: [IEP-104] Add Cdc WAL records Key: IGNITE-19639 URL: https://issues.apache.org/jira/browse/IGNITE-19639 Project: Ignite Issue Type: Sub-task Reporter: Maksim Timonin In this ticket: # RealtimeCdcRecord (with persisting CdcConsumerState?) # StopRealtimeCdcRecord -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19640) [IEP-104] Add ignite-cdc backup mode
Maksim Timonin created IGNITE-19640: --- Summary: [IEP-104] Add ignite-cdc backup mode Key: IGNITE-19640 URL: https://issues.apache.org/jira/browse/IGNITE-19640 Project: Ignite Issue Type: Sub-task Reporter: Maksim Timonin ignite-cdc should fetch IgniteConfiguration, and run in backup mode if RealtimeCdc is enabled # In backup mode should consume Cdc WAL records # Switch to active state after get StopRealtimeCdcRecord # Persist actual state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19611) Drop ifExists flag from Catalog actions params
[
https://issues.apache.org/jira/browse/IGNITE-19611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-19611:
--
Fix Version/s: 3.0.0-beta2
> Drop ifExists flag from Catalog actions params
> --
>
> Key: IGNITE-19611
> URL: https://issues.apache.org/jira/browse/IGNITE-19611
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3, tech-debt
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Let's drop dead code from {{org.apache.ignite.internal.catalog.commands}}
> classes
> E.g. AbstractTableCommandParams.ifTableExists
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19641) Catalog events are triggered too early.
Andrey Mashenkov created IGNITE-19641: - Summary: Catalog events are triggered too early. Key: IGNITE-19641 URL: https://issues.apache.org/jira/browse/IGNITE-19641 Project: Ignite Issue Type: Bug Components: sql Reporter: Andrey Mashenkov As of now, Catalog events are triggered before a new version of Catalog is registered. Catalog events doesn’t provide a new version of Catalog itself, but only a version number. Thus, events doesn’t contain enough information in a context, which some components may need, and Catalog doesn’t contains a new version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19642) CatalogService should use HybridClock to register new Catalog version.
Andrey Mashenkov created IGNITE-19642: - Summary: CatalogService should use HybridClock to register new Catalog version. Key: IGNITE-19642 URL: https://issues.apache.org/jira/browse/IGNITE-19642 Project: Ignite Issue Type: Bug Components: sql Reporter: Andrey Mashenkov As of now we use System.currentTimestamp to assign timestamp for a new Catalog version. Let's use HybridClock instead. Also, there are bunch of Thread.sleep(5) in CatalogServiceSelftTest tests as a workaround for this issue. Let's also remove any waiting in tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19642) CatalogService should use HybridClock to register new Catalog version.
[ https://issues.apache.org/jira/browse/IGNITE-19642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19642: -- Fix Version/s: 3.0.0-beta2 > CatalogService should use HybridClock to register new Catalog version. > -- > > Key: IGNITE-19642 > URL: https://issues.apache.org/jira/browse/IGNITE-19642 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > As of now we use System.currentTimestamp to assign timestamp for a new > Catalog version. > Let's use HybridClock instead. > Also, there are bunch of Thread.sleep(5) in CatalogServiceSelftTest tests as > a workaround for this issue. Let's also remove any waiting in tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19642) CatalogService should use HybridClock to register new Catalog version.
[ https://issues.apache.org/jira/browse/IGNITE-19642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19642: -- Epic Link: IGNITE-19502 > CatalogService should use HybridClock to register new Catalog version. > -- > > Key: IGNITE-19642 > URL: https://issues.apache.org/jira/browse/IGNITE-19642 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt > > As of now we use System.currentTimestamp to assign timestamp for a new > Catalog version. > Let's use HybridClock instead. > Also, there are bunch of Thread.sleep(5) in CatalogServiceSelftTest tests as > a workaround for this issue. Let's also remove any waiting in tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19641) Catalog events are triggered too early.
[ https://issues.apache.org/jira/browse/IGNITE-19641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19641: -- Fix Version/s: 3.0.0-beta2 > Catalog events are triggered too early. > --- > > Key: IGNITE-19641 > URL: https://issues.apache.org/jira/browse/IGNITE-19641 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > As of now, Catalog events are triggered before a new version of Catalog is > registered. > Catalog events doesn’t provide a new version of Catalog itself, but only a > version number. > Thus, events doesn’t contain enough information in a context, which some > components may need, and Catalog doesn’t contains a new version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19643) Catalog validation code refactoring.
Andrey Mashenkov created IGNITE-19643: - Summary: Catalog validation code refactoring. Key: IGNITE-19643 URL: https://issues.apache.org/jira/browse/IGNITE-19643 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov Let's implement some validation rules that each Catalog command should check before the execution. Then replace current boilerplate validation code with applying these rules using Visitor pattern. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19644) Drop 'COLUMN IF (NOT) EXISTS' syntax sypport.
Andrey Mashenkov created IGNITE-19644: - Summary: Drop 'COLUMN IF (NOT) EXISTS' syntax sypport. Key: IGNITE-19644 URL: https://issues.apache.org/jira/browse/IGNITE-19644 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov Let's drop supporting ambiguous "COLUMN IF (NOT) EXISTS" syntax. Motivation. "IF EXISTS/IF NOT EXISTS" clause is not a part of SQL standard. It usage looks ambiguous when statement contains multiple actions for adding/dropping multiple columns. Multiple actions support is desirable due to performance reasons. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19522) Modify deploy unit command
[ https://issues.apache.org/jira/browse/IGNITE-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev reassigned IGNITE-19522: - Assignee: Vadim Pakhnushev > Modify deploy unit command > --- > > Key: IGNITE-19522 > URL: https://issues.apache.org/jira/browse/IGNITE-19522 > Project: Ignite > Issue Type: New Feature > Components: cli, rest >Reporter: Mikhail Pochatkin >Assignee: Vadim Pakhnushev >Priority: Major > Labels: iep-103, ignite-3 > > ignite3 unit deploy --version (-uv) > --path (-up) | [--nodes > MAJORITY|ALL|] > > Options: > * --version -uv - defines the deployment unit’s version > (). > * --path -up - path to JAR-file () or to the directory () which > contains all required class files and resources. > * --nodes - defines the set of target nodes where the deployment unit will > be deployed. The possible options are possible: > * MAJORITY - Default value. The CMG majority nodes will be chosen as the > target nodes (including the leader node). > * ALL - All available nodes will be chosen as the target nodes. In this case > “available” means The CMG majority nodes (see MAJORITY option) and all nodes > that will be live during the deployment process. If some node will go offline > (excluding the CMG majority nodes) then this node will not finish the > deployment process and will request deployment on-demand. > * - All nodes with corresponding consistent IDs in form node_id2, …]>. Note, that these nodes are treated as an addition to the CMG > majority nodes and behavior is similar to the ALL option (the deployment unit > will be deployed only on available nodes). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19405) Remove assignments from table configuration
[ https://issues.apache.org/jira/browse/IGNITE-19405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728716#comment-17728716 ] Vladislav Pyatkov commented on IGNITE-19405: Merged 7f366d667cea9295f035dc21fa87ccd4cbe70378 > Remove assignments from table configuration > --- > > Key: IGNITE-19405 > URL: https://issues.apache.org/jira/browse/IGNITE-19405 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Time Spent: 3h 40m > Remaining Estimate: 0h > > *Motivation:* > At the moment we have a duplication of table assignments in the metastore > keys and table configurations. Because of that fact, we need to update the > both variants (in the rebalance logic, for example) and handle updates of the > both assignments sources. We should use the metastore keys only assignments > in all places, instead. > *Definition of done:* > - Table assignments are removed from configuration > - All logic connected with listen/update of configuration assignments must be > replaced by appropriate metastore keys -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19645) Suppress an illegal reflective access runtime warning for JDK11
Sergey Korotkov created IGNITE-19645:
Summary: Suppress an illegal reflective access runtime warning for
JDK11
Key: IGNITE-19645
URL: https://issues.apache.org/jira/browse/IGNITE-19645
Project: Ignite
Issue Type: Task
Reporter: Sergey Korotkov
Assignee: Sergey Korotkov
Currently the following runtime warnings are printed to console by command line
utilities like ignite.sh or control.sh if used with JDK11:
{noformat}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.ignite.internal.util.GridUnsafe$2
(file:/opt/ignite/libs/ignite-core-2.15.0.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
{noformat}
Other such warnings are suppressed by the corresponding _--add-opens_ JVM
options in the {{bin/include/jvmdefaults.sh}} (and
{{{}bin/include/jvmdefaults.bat{}}}) files. But not this one.
Warning needs to be suppressed by the
_--add-opens=java.base/java.nio=ALL-UNNAMED_ JVM option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19634) Fix PMD error when building the SQL module
[
https://issues.apache.org/jira/browse/IGNITE-19634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-19634:
-
Fix Version/s: 3.0.0-beta2
> Fix PMD error when building the SQL module
> --
>
> Key: IGNITE-19634
> URL: https://issues.apache.org/jira/browse/IGNITE-19634
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Trivial
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> When building the project, I get the following error when executing the
> {{:ignite-sql-engine:pmdMain}} task:
> {noformat}
> PMDException: Error while parsing
> modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/exec/exp/RexToLixTranslator.java
> {noformat}
> Looks like updating the PMD plugin solves this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19634) Fix PMD error when building the SQL module
[
https://issues.apache.org/jira/browse/IGNITE-19634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-19634:
-
Reviewer: Semyon Danilov
> Fix PMD error when building the SQL module
> --
>
> Key: IGNITE-19634
> URL: https://issues.apache.org/jira/browse/IGNITE-19634
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Trivial
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When building the project, I get the following error when executing the
> {{:ignite-sql-engine:pmdMain}} task:
> {noformat}
> PMDException: Error while parsing
> modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/exec/exp/RexToLixTranslator.java
> {noformat}
> Looks like updating the PMD plugin solves this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19646) Transform IndexManager to internally work against Catalog event types
Kirill Tkalenko created IGNITE-19646: Summary: Transform IndexManager to internally work against Catalog event types Key: IGNITE-19646 URL: https://issues.apache.org/jira/browse/IGNITE-19646 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 Part of ticket IGNITE-19483 which will have changes for IndexManager. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19647) Our Cache Templates introductory documentation is misleading -- implies SQL Create Table only
Alex Levitski created IGNITE-19647: -- Summary: Our Cache Templates introductory documentation is misleading -- implies SQL Create Table only Key: IGNITE-19647 URL: https://issues.apache.org/jira/browse/IGNITE-19647 Project: Ignite Issue Type: Task Components: documentation Reporter: Alex Levitski Assignee: Alex Levitski Identical to [https://ggsystems.atlassian.net/browse/GG-36709] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18528) Distribution Zones [Part2]
[ https://issues.apache.org/jira/browse/IGNITE-18528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-18528. -- Fix Version/s: 3.0.0-beta2 Resolution: Fixed > Distribution Zones [Part2] > -- > > Key: IGNITE-18528 > URL: https://issues.apache.org/jira/browse/IGNITE-18528 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18528) Distribution Zones [Part2]
[ https://issues.apache.org/jira/browse/IGNITE-18528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-18528: Assignee: Mirza Aliev > Distribution Zones [Part2] > -- > > Key: IGNITE-18528 > URL: https://issues.apache.org/jira/browse/IGNITE-18528 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > -- 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:
-
Description:
*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.
was:
*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}
// 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 is can handle cleanup message. Now, we workaround the case by scanning
storage for logging for write intent and commit them on start:
{code}
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.
> 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
>Priority: Major
> Labels: ignite-3
>
> *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] [Created] (IGNITE-19648) Failed to cancel rebalance
Ivan Bessonov created IGNITE-19648:
--
Summary: Failed to cancel rebalance
Key: IGNITE-19648
URL: https://issues.apache.org/jira/browse/IGNITE-19648
Project: Ignite
Issue Type: Bug
Reporter: Ivan Bessonov
{noformat}
Caused by: org.apache.ignite.internal.storage.StorageRebalanceException:
IGN-STORAGE-4 TraceId:8e22c456-103e-4445-9b35-e021e22cd615 Storage in the
process of starting a rebalance: [table=TEST, partitionId=0]
at
org.apache.ignite.internal.storage.util.MvPartitionStorages.throwExceptionDependingOnOperationForRebalance(MvPartitionStorages.java:400)
at
org.apache.ignite.internal.storage.util.MvPartitionStorages.lambda$abortRebalance$16(MvPartitionStorages.java:265)
at
java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1932)
at
org.apache.ignite.internal.storage.util.MvPartitionStorages.abortRebalance(MvPartitionStorages.java:261)
at
org.apache.ignite.internal.storage.pagememory.AbstractPageMemoryTableStorage.lambda$abortRebalancePartition$17(AbstractPageMemoryTableStorage.java:250)
at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:897)
at
org.apache.ignite.internal.storage.pagememory.AbstractPageMemoryTableStorage.abortRebalancePartition(AbstractPageMemoryTableStorage.java:250)
at
org.apache.ignite.internal.table.distributed.raft.snapshot.PartitionAccessImpl.abortRebalance(PartitionAccessImpl.java:221){noformat}
Unfortunately, the entire log is lost. Issue occurred in one of
org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17985) intermittent failure: long pathname prevents server node start on Windows 11 with working IPv6 network
[
https://issues.apache.org/jira/browse/IGNITE-17985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728775#comment-17728775
]
Jeremy McMillan commented on IGNITE-17985:
--
Matching GitHub issue
[#10648|[http://example.com|https://github.com/apache/ignite/issues/10648]] has
additional information.
> intermittent failure: long pathname prevents server node start on Windows 11
> with working IPv6 network
> --
>
> Key: IGNITE-17985
> URL: https://issues.apache.org/jira/browse/IGNITE-17985
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
> Environment: Windows 11
> OpenJDK 17
> Apache Ignite 2.14
>Reporter: Jeremy McMillan
>Priority: Critical
>
> Depending on the IP addresses assigned to nodes before startup, Ignite
> default behavior constructs a consistent ID from a tuple of IP addresses and
> ports identifying the node, which will result in a failure to create local
> page cache folder using the consistent ID as a pathname,
> non-deterministically preventing node startup.
> example log message:
> {{[08:52:17] Ignite node stopped wih ERRORS [uptime=00:00:02.143]}}
> {{class org.apache.ignite.IgniteException: Failed to start processor:
> GridProcessorAdapter []}}
> {{ at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1145)}}
> {{ at org.apache.ignite.Ignition.start(Ignition.java:356)}}
> {{ at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:365)}}
> {{Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> processor: GridProcessorAdapter []}}
> {{ at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1787)}}
> {{ at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1757)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1679)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1121)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1015)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:840)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:710)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:679)}}
> {{ at org.apache.ignite.Ignition.start(Ignition.java:353)}}
> {{ ... 1 more}}
> {{Caused by: class org.apache.ignite.IgniteCheckedException: Failed to create
> page store work directory:
> C:\Users\jt\AppData\Local\IgniteCluster\node0\db\0_0_0_0_0_0_0_1_10_0_1_84_127_0_0_1_2600_1700_5650_3cff_481f_54f_adb9_437_2600_1700_5650_3cff_8188_5e65_f1fc_237_2600_1700_5650_3cff_84a4_9fdf_feb2_b01f_2600_1700_5650_3cff_9194_cd0d_813f_2e71_2600_1700_5650_3cff_a042_5e6f_9b0b_492b_2600_1700_5650_3cff_bcc4_3dca_bcd5_41cb_47500}}
> {{ at
> org.apache.ignite.internal.util.IgniteUtils.ensureDirectory(IgniteUtils.java:9971)}}
> {{ at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.(GridLocalConfigManager.java:127)}}
> {{ at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:618)}}
> {{ at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1784)}}
> {{ ... 11 more}}
> {{Failed to start grid: Failed to start processor: GridProcessorAdapter []}}
> Bad workaround: reboot the node. With good luck, the IP addresses will
> normalize to a shorter string, and the node will start. With bad luck, the IP
> addresses will be too long: try again.
> Acceptable workaround: override the nodes' consistent IDs by [setting the
> property or environment
> variable|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html#IGNITE_OVERRIDE_CONSISTENT_ID]
> at startup time to an appropriate value.
> Factors:
> * #IGNITE-9995
> * #IGNITE-2416
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17985) intermittent failure: long pathname prevents server node start on Windows 11 with working IPv6 network
[
https://issues.apache.org/jira/browse/IGNITE-17985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728775#comment-17728775
]
Jeremy McMillan edited comment on IGNITE-17985 at 6/2/23 2:50 PM:
--
Matching GitHub issue [#10648|https://github.com/apache/ignite/issues/10648]
has additional information.
was (Author: JIRAUSER292640):
Matching GitHub issue
[#10648|[http://example.com|https://github.com/apache/ignite/issues/10648]] has
additional information.
> intermittent failure: long pathname prevents server node start on Windows 11
> with working IPv6 network
> --
>
> Key: IGNITE-17985
> URL: https://issues.apache.org/jira/browse/IGNITE-17985
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
> Environment: Windows 11
> OpenJDK 17
> Apache Ignite 2.14
>Reporter: Jeremy McMillan
>Priority: Critical
>
> Depending on the IP addresses assigned to nodes before startup, Ignite
> default behavior constructs a consistent ID from a tuple of IP addresses and
> ports identifying the node, which will result in a failure to create local
> page cache folder using the consistent ID as a pathname,
> non-deterministically preventing node startup.
> example log message:
> {{[08:52:17] Ignite node stopped wih ERRORS [uptime=00:00:02.143]}}
> {{class org.apache.ignite.IgniteException: Failed to start processor:
> GridProcessorAdapter []}}
> {{ at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1145)}}
> {{ at org.apache.ignite.Ignition.start(Ignition.java:356)}}
> {{ at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:365)}}
> {{Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> processor: GridProcessorAdapter []}}
> {{ at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1787)}}
> {{ at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1757)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1679)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1121)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1015)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:840)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:710)}}
> {{ at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:679)}}
> {{ at org.apache.ignite.Ignition.start(Ignition.java:353)}}
> {{ ... 1 more}}
> {{Caused by: class org.apache.ignite.IgniteCheckedException: Failed to create
> page store work directory:
> C:\Users\jt\AppData\Local\IgniteCluster\node0\db\0_0_0_0_0_0_0_1_10_0_1_84_127_0_0_1_2600_1700_5650_3cff_481f_54f_adb9_437_2600_1700_5650_3cff_8188_5e65_f1fc_237_2600_1700_5650_3cff_84a4_9fdf_feb2_b01f_2600_1700_5650_3cff_9194_cd0d_813f_2e71_2600_1700_5650_3cff_a042_5e6f_9b0b_492b_2600_1700_5650_3cff_bcc4_3dca_bcd5_41cb_47500}}
> {{ at
> org.apache.ignite.internal.util.IgniteUtils.ensureDirectory(IgniteUtils.java:9971)}}
> {{ at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.(GridLocalConfigManager.java:127)}}
> {{ at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:618)}}
> {{ at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1784)}}
> {{ ... 11 more}}
> {{Failed to start grid: Failed to start processor: GridProcessorAdapter []}}
> Bad workaround: reboot the node. With good luck, the IP addresses will
> normalize to a shorter string, and the node will start. With bad luck, the IP
> addresses will be too long: try again.
> Acceptable workaround: override the nodes' consistent IDs by [setting the
> property or environment
> variable|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html#IGNITE_OVERRIDE_CONSISTENT_ID]
> at startup time to an appropriate value.
> Factors:
> * #IGNITE-9995
> * #IGNITE-2416
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19590) Calcite engine. Hide sensitive information in diagnostic tools
[
https://issues.apache.org/jira/browse/IGNITE-19590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728788#comment-17728788
]
Ignite TC Bot commented on IGNITE-19590:
{panel:title=Branch: [pull/10760/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10760/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7199360]]
* {color:#013220}IgniteCalciteTestSuite:
SqlDiagnosticIntegrationTest.testSensitiveInformationHiding - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7199441&buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. Hide sensitive information in diagnostic tools
> --
>
> Key: IGNITE-19590
> URL: https://issues.apache.org/jira/browse/IGNITE-19590
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We need to hide sensitive information in queries exposed to diagnostic tools
> for the Calcite-based SQL engine, if flag IGNITE_TO_STRING_INCLUDE_SENSITIVE
> is not set.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19466) Empty data nodes on table creation
[
https://issues.apache.org/jira/browse/IGNITE-19466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel updated IGNITE-19466:
---
Description:
h3. *Motivation*
After introducing data nodes from DistributionZoneManager on table creation it
became possible that a table is created with an empty data nodes value and
therefore with empty assignments. It causes an exceptions like
{code:java}
Caused by: java.lang.AssertionError
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.randomNode(RaftGroupServiceImpl.java:680)
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.randomNode(RaftGroupServiceImpl.java:667)
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:222)
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:178)
{code}
because there are an empty peers on RaftGroupServiceImpl#start. The proper
solution when a table is created with empty peers but remains unusable until
the data nodes for the zone is updated and RaftGroupServiceImpl is started with
peers.
h3. *Definition of Done*
If the date nodes for the zone are empty, then create a table without a raft
group.
Start raft groups and other components when the data nodes value is updated.
h3. *Implementation Notes*
We have two issues.
# The first is a table creation when the data nodes values of the zone is
empty. In this case createTablePartitionsLocally method gets an empty
newPartAssignment. So it is not possible to do startRaftGroupNode without
peers. Need to skip it if the data nodes is empty.
# The second is starting raft groups when data nodes value is updated. In this
case handleChangePendingAssignmentEvent gets an empty stableAssignments and not
empty pendingAssignments. Currently handleChangePendingAssignmentEvent invokes
startRaftGroupNode to start raft group node with stable assignment and then
invokes changePeersAsync with pendingAssignments. We need to skip it if
stableAssignments is empty and start new raft group with pendingAssignments.
was:
h3. *Motivation*
After introducing data nodes from DistributionZoneManager on table creation it
became possible that a table is created with an empty data nodes value and
therefore with empty assignments. It causes an exceptions like
{code:java}
Caused by: java.lang.AssertionError
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.randomNode(RaftGroupServiceImpl.java:680)
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.randomNode(RaftGroupServiceImpl.java:667)
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:222)
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:178)
{code}
because there are an empty peers on RaftGroupServiceImpl#start. The proper
solution when a table is created with empty peers but remains unusable until
the data nodes for the zone is updated and RaftGroupServiceImpl is started with
peers.
h3. *Definition of Done*
If the date nodes for the zone are empty, then create a table without a raft
group.
> Empty data nodes on table creation
> --
>
> Key: IGNITE-19466
> URL: https://issues.apache.org/jira/browse/IGNITE-19466
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> h3. *Motivation*
> After introducing data nodes from DistributionZoneManager on table creation
> it became possible that a table is created with an empty data nodes value and
> therefore with empty assignments. It causes an exceptions like
> {code:java}
> Caused by: java.lang.AssertionError
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.randomNode(RaftGroupServiceImpl.java:680)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.randomNode(RaftGroupServiceImpl.java:667)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:222)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:178)
> {code}
> because there are an empty peers on RaftGroupServiceImpl#start. The proper
> solution when a table is created with empty peers but remains unusable until
> the data nodes for the zone is updated and RaftGroupServiceImpl is started
> with peers.
> h3. *Definition of Done*
> If the date nodes for the zone are empty, then create a table without a raft
> group.
> Start raft groups and other components when the data nodes value is updated.
> h3. *Implementation Notes*
> We have two issues.
> # The first is a table creation when the data nodes values of the zone is
> empty. In this case createTablePartitionsLocally method gets an empty
> newPartAssignment. So it is not possible to do startRaftGroupNode without
> peers. Need to skip it if the da
[jira] [Commented] (IGNITE-19620) Provide ability to configure metric exporter filter from Spring XML
[
https://issues.apache.org/jira/browse/IGNITE-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728854#comment-17728854
]
Ignite TC Bot commented on IGNITE-19620:
{panel:title=Branch: [pull/10757/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10757/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Spring{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7199653]]
* {color:#013220}IgniteSpringTestSuite: RegexpMetricFilterTest.testFilter -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7199669&buildTypeId=IgniteTests24Java8_RunAll]
> Provide ability to configure metric exporter filter from Spring XML
> ---
>
> Key: IGNITE-19620
> URL: https://issues.apache.org/jira/browse/IGNITE-19620
> Project: Ignite
> Issue Type: Task
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Minor
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Provide ability to configure metric exporter filter from Spring XML
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19649) Ignite Doc: add doc for the 'queryTimeout' & 'connectionTimeout' in the JDBC connection url
YuJue Li created IGNITE-19649: - Summary: Ignite Doc: add doc for the 'queryTimeout' & 'connectionTimeout' in the JDBC connection url Key: IGNITE-19649 URL: https://issues.apache.org/jira/browse/IGNITE-19649 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.15 Reporter: YuJue Li Assignee: YuJue Li Fix For: 2.16 Add doc for the 'queryTimeout' & 'connectionTimeout' in the JDBC connection url -- This message was sent by Atlassian Jira (v8.20.10#820010)
