[jira] [Updated] (IGNITE-17445) RocksDbKeyValueStorage recreates DB on start, so data can't be found until Raft log is replayed
[
https://issues.apache.org/jira/browse/IGNITE-17445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-17445:
--
Description:
RocksDbKeyValueStorage recreates DB on start. This means that entries that were
put to this storage earlier, can or cant be found until raft log is replayed,
i.e. the behavior is undefined. For example, this can cause assertion on node
recovery:
{code:java}
java.lang.AssertionError: Configuration revision must be greater than local
node applied revision [msRev=0, appliedRev=1
{code}
which means that applied revision in vault is 1 but only 0 is found in meta
storage, as the storage of meta storage is being recreated.
For now, the only thing that saves us from this assertion to be thrown every
time, is that operations related to node recovery, applied from distributed
configuration (see IgniteImpl#notifyConfigurationListeners ), take some time
and raft log is small enough to replay faster than the performing of recovery
operations.
was:
RocksDbKeyValueStorage recreates DB on start. This means that entries that were
put to this storage earlier, can or cant be found until raft log is replayed,
i.e. the behavior is undefined. For example, this can cause assertion on node
recovery:
{code:java}
java.lang.AssertionError: Configuration revision must be greater than local
node applied revision [msRev=0, appliedRev=1
{code}
which means that applied revision in vault is 1 but only 0 is found in meta
storage, as the storage of meta storage is being recreated.
> RocksDbKeyValueStorage recreates DB on start, so data can't be found until
> Raft log is replayed
> ---
>
> Key: IGNITE-17445
> URL: https://issues.apache.org/jira/browse/IGNITE-17445
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
>
> RocksDbKeyValueStorage recreates DB on start. This means that entries that
> were put to this storage earlier, can or cant be found until raft log is
> replayed, i.e. the behavior is undefined. For example, this can cause
> assertion on node recovery:
> {code:java}
> java.lang.AssertionError: Configuration revision must be greater than local
> node applied revision [msRev=0, appliedRev=1
> {code}
> which means that applied revision in vault is 1 but only 0 is found in meta
> storage, as the storage of meta storage is being recreated.
> For now, the only thing that saves us from this assertion to be thrown every
> time, is that operations related to node recovery, applied from distributed
> configuration (see IgniteImpl#notifyConfigurationListeners ), take some time
> and raft log is small enough to replay faster than the performing of recovery
> operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17445) RocksDbKeyValueStorage recreates DB on start, so data can't be found until Raft log is replayed
Denis Chudov created IGNITE-17445:
-
Summary: RocksDbKeyValueStorage recreates DB on start, so data
can't be found until Raft log is replayed
Key: IGNITE-17445
URL: https://issues.apache.org/jira/browse/IGNITE-17445
Project: Ignite
Issue Type: Bug
Reporter: Denis Chudov
RocksDbKeyValueStorage recreates DB on start. This means that entries that were
put to this storage earlier, can or cant be found until raft log is replayed,
i.e. the behavior is undefined. For example, this can cause assertion on node
recovery:
{code:java}
java.lang.AssertionError: Configuration revision must be greater than local
node applied revision [msRev=0, appliedRev=1
{code}
which means that applied revision in vault is 1 but only 0 is found in meta
storage, as the storage of meta storage is being recreated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17429) Sql. Extend sql grammar to support CREATE/DROP INDEX statements
[
https://issues.apache.org/jira/browse/IGNITE-17429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17429:
--
Description:
We need to give an ability to manage index via DDL statements.
As a first step lets support CREATE and DROP statements only. Within this
ticket we need to extend the sql grammar file as well as provide all necessary
structures to keep parsed AST.
The proposed grammar:
{code:java}
CREATE INDEX [IF NOT EXISTS] name ON table_name [USING { HASH | TREE }]
(column_name [ASC | DESC] [NULLS {FIRST | LAST}] [, ...]);
{code}
{code:java}
DROP INDEX [IF EXISTS] name;{code}
was:
We need to give an ability to manage index via DDL statements.
As a first step lets support CREATE and DROP statements only. Within this
ticket we need to extend the sql grammar file as well as provide all necessary
structures to keep parsed AST.
The proposed grammar:
{code:java}
CREATE INDEX [IF NOT EXISTS] name ON table_name [USING HASH | SORTED ]
(column_name [ASC | DESC] [NULLS {FIRST | LAST}] [, ...]);
{code}
{code:java}
DROP INDEX [IF EXISTS] name;{code}
> Sql. Extend sql grammar to support CREATE/DROP INDEX statements
> ---
>
> Key: IGNITE-17429
> URL: https://issues.apache.org/jira/browse/IGNITE-17429
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> We need to give an ability to manage index via DDL statements.
> As a first step lets support CREATE and DROP statements only. Within this
> ticket we need to extend the sql grammar file as well as provide all
> necessary structures to keep parsed AST.
> The proposed grammar:
> {code:java}
> CREATE INDEX [IF NOT EXISTS] name ON table_name [USING { HASH | TREE }]
> (column_name [ASC | DESC] [NULLS {FIRST | LAST}] [, ...]);
>
> {code}
> {code:java}
> DROP INDEX [IF EXISTS] name;{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17444) Consider possibility of introducing pluggable metric exporters
Denis Chudov created IGNITE-17444: - Summary: Consider possibility of introducing pluggable metric exporters Key: IGNITE-17444 URL: https://issues.apache.org/jira/browse/IGNITE-17444 Project: Ignite Issue Type: New Feature Reporter: Denis Chudov Consider possibility of introducing pluggable metric exporters to provide ability for users to create their own exporters thay need. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17443) Implement opencensus metric exporter
Denis Chudov created IGNITE-17443: - Summary: Implement opencensus metric exporter Key: IGNITE-17443 URL: https://issues.apache.org/jira/browse/IGNITE-17443 Project: Ignite Issue Type: New Feature Reporter: Denis Chudov Implement opencensus metric exporter, which should push metrics to opencensus, likewise the opencensus exporter in Apache Ignite 2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17442) Colorize Ignite console output
[
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17442:
--
Description:
Recently completed Ignite [migration to use
log4j2|https://issues.apache.org/jira/browse/IGNITE-16650]. So we can use
["highlight" conversion
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to
colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{code:xml}
{code}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
was:
Recently completed Ignite [migration to use
log4j2|https://issues.apache.org/jira/browse/IGNITE-16650]. So we can use
["highlight" conversion
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to
colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
> Colorize Ignite console output
> --
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: prod-propsal.png
>
>
> Recently completed Ignite [migration to use
> log4j2|https://issues.apache.org/jira/browse/IGNITE-16650]. So we can use
> ["highlight" conversion
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to
> colorize the output.
> Initial proposal for production console output (pretty similar to spring
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
> pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink,
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold,
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
> %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each
> node with its own color. Apparently this can't be done without adding your
> own plugin for log4j.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17442) Colorize Ignite console output
[
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17442:
--
Description:
Recently completed Ignite [migration to use
log4j2|https://issues.apache.org/jira/browse/IGNITE-16650]. So we can use
["highlight" conversion
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to
colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
was:
Recently completed Ignite migration to use log4j2. So we can use ["highlight"
conversion
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to
colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
> Colorize Ignite console output
> --
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: prod-propsal.png
>
>
> Recently completed Ignite [migration to use
> log4j2|https://issues.apache.org/jira/browse/IGNITE-16650]. So we can use
> ["highlight" conversion
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to
> colorize the output.
> Initial proposal for production console output (pretty similar to spring
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {noformat}
> pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink,
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold,
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
> %m%n"/>
> {noformat}
> For the test framework, there is a suggestion - to color the output of each
> node with its own color. Apparently this can't be done without adding your
> own plugin for log4j.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17442) Colorize Ignite console output
[
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17442:
--
Description:
Recently completed Ignite migration to use log4j2. So we can use ["highlight"
conversion
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to
colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
was:
Recently completed Ignite migration to use log4j2. So we can use ["highlight"
conversion
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout]
to colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
> Colorize Ignite console output
> --
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: prod-propsal.png
>
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight"
> conversion
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to
> colorize the output.
> Initial proposal for production console output (pretty similar to spring
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {noformat}
> pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink,
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold,
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
> %m%n"/>
> {noformat}
> For the test framework, there is a suggestion - to color the output of each
> node with its own color. Apparently this can't be done without adding your
> own plugin for log4j.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17442) Colorize Ignite console output
[
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17442:
--
Description:
Recently completed Ignite migration to use log4j2. So we can use ["highlight"
conversion
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout]
to colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
was:
Recently completed Ignite [migration to use
log4j2|https://issues.apache.org/jira/browse/IGNITE-16650]. So we can use
highlight conversion pattern to colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
> Colorize Ignite console output
> --
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: prod-propsal.png
>
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight"
> conversion
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout]
> to colorize the output.
> Initial proposal for production console output (pretty similar to spring
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {noformat}
> pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink,
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold,
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
> %m%n"/>
> {noformat}
> For the test framework, there is a suggestion - to color the output of each
> node with its own color. Apparently this can't be done without adding your
> own plugin for log4j.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17442) Colorize Ignite console output
[
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17442:
--
Description:
Recently completed Ignite [migration to use
log4j2|https://issues.apache.org/jira/browse/IGNITE-16650]. So we can use
highlight conversion pattern to colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
was:
Recently completed Ignite migration to use log4j2. So we can use highlight
conversion pattern to colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
> Colorize Ignite console output
> --
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: prod-propsal.png
>
>
> Recently completed Ignite [migration to use
> log4j2|https://issues.apache.org/jira/browse/IGNITE-16650]. So we can use
> highlight conversion pattern to colorize the output.
> Initial proposal for production console output (pretty similar to spring
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {noformat}
> pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink,
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold,
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
> %m%n"/>
> {noformat}
> For the test framework, there is a suggestion - to color the output of each
> node with its own color. Apparently this can't be done without adding your
> own plugin for log4j.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17442) Colorize Ignite console output
[
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17442:
--
Summary: Colorize Ignite console output (was: Colorize Ignite console
output.)
> Colorize Ignite console output
> --
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: prod-propsal.png
>
>
> Recently completed Ignite migration to use log4j2. So we can use highlight
> conversion pattern to colorize the output.
> Initial proposal for production console output (pretty similar to spring
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {noformat}
> pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink,
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold,
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
> %m%n"/>
> {noformat}
> For the test framework, there is a suggestion - to color the output of each
> node with its own color. Apparently this can't be done without adding your
> own plugin for log4j.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17442) Colorize Ignite console output.
[
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17442:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Colorize Ignite console output.
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: prod-propsal.png
>
>
> Recently completed Ignite migration to use log4j2. So we can use highlight
> conversion pattern to colorize the output.
> Initial proposal for production console output (pretty similar to spring
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {noformat}
> pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink,
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold,
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
> %m%n"/>
> {noformat}
> For the test framework, there is a suggestion - to color the output of each
> node with its own color. Apparently this can't be done without adding your
> own plugin for log4j.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17442) Colorize Ignite console output.
[
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17442:
--
Description:
Recently completed Ignite migration to use log4j2. So we can use highlight
conversion pattern to colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
was:
Recently completed Ignite migration to use log4j2. So we can use highlight
conversion pattern to colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
> Colorize Ignite console output.
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: prod-propsal.png
>
>
> Recently completed Ignite migration to use log4j2. So we can use highlight
> conversion pattern to colorize the output.
> Initial proposal for production console output (pretty similar to spring
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {noformat}
> pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink,
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold,
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
> %m%n"/>
> {noformat}
> For the test framework, there is a suggestion - to color the output of each
> node with its own color. Apparently this can't be done without adding your
> own plugin for log4j.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17442) Colorize Ignite console output.
Pavel Pereslegin created IGNITE-17442:
-
Summary: Colorize Ignite console output.
Key: IGNITE-17442
URL: https://issues.apache.org/jira/browse/IGNITE-17442
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Pereslegin
Assignee: Pavel Pereslegin
Attachments: prod-propsal.png
Recently completed Ignite migration to use log4j2. So we can use highlight
conversion pattern to colorize the output.
Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png!
Pattern for log4j 2.18+
{noformat}
{noformat}
For the test framework, there is a suggestion - to color the output of each
node with its own color. Apparently this can't be done without adding your own
plugin for log4j.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-14326) Resetting Ignite cache entry TTL
[
https://issues.apache.org/jira/browse/IGNITE-14326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17573030#comment-17573030
]
Stanislav Lukyanov commented on IGNITE-14326:
-
[~kukushal] I think you'll get exactly the behavior you need if you use an
`EntryProcessor` that changes nothing and returns nothing. The value will be
touched, the new TTL will be set based on the `ExpiryPolicy`, nothing will be
touched, and no value will be returned.
If this WA has any unfortunate side effects (e.g. fetching a value onto the
heap), it's better to remove the side effects than introduce a new API (e.g.
make the `EntryProcessor` fetch value onto the heap lazily).
> Resetting Ignite cache entry TTL
>
>
> Key: IGNITE-14326
> URL: https://issues.apache.org/jira/browse/IGNITE-14326
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Stephen Darlington
>Priority: Major
> Labels: cggg
> Original Estimate: 64h
> Remaining Estimate: 64h
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to refresh the TTL without first retrieving the record, which
> is slow and resource consuming if an entry is large.
> Provide a method to reset Ignite cache entry TTL.
> Suggested API (to be discussed with community):
> {{IgniteCache#touch(key)}}: resets the TTL using the latest TTL value or does
> nothing if no TTL was specified for the key.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17356) Implementation of metric source for Ignite Compute
[ https://issues.apache.org/jira/browse/IGNITE-17356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-17356: -- Description: Following metrics could be useful for Ignite compute: - total number of tasks that are supposed to be executed locally - number of completed tasks that were executed locally What is needed to achieve this: - Define metrics source class and metrics holder class for ignite compute. - Define all metric variables in the holder class, if needed. - Implement initialization logic which is responsible for creation of actual instances of metrics and building an immutable instance of metrics set (will be executed on metrics enabling). Implement additional clean up logic if needed (will be executed on metrics disabled). - Define methods that implement desirable manipulations with metrics. Every such method must check the state of the metrics source (enabled\disabled) by testing the holder reference to null (some kind of guard) before modifying a metric value. Read holder reference only once and use it in scope of the method in order to avoid data races. - Metrics source should be registered in metrics registry on component start and should be unregistered on component stop. Initial metrics source state (enabled\disabled) should be set according to configuration for each particular component. Add logic related with metrics values modification (add invocations of metrics source methods). was: What is needed to achieve this: - Define metrics source class and metrics holder class for ignite compute. - Define all metric variables in the holder class, if needed. - Implement initialization logic which is responsible for creation of actual instances of metrics and building an immutable instance of metrics set (will be executed on metrics enabling). Implement additional clean up logic if needed (will be executed on metrics disabled). - Define methods that implement desirable manipulations with metrics. Every such method must check the state of the metrics source (enabled\disabled) by testing the holder reference to null (some kind of guard) before modifying a metric value. Read holder reference only once and use it in scope of the method in order to avoid data races. - Metrics source should be registered in metrics registry on component start and should be unregistered on component stop. Initial metrics source state (enabled\disabled) should be set according to configuration for each particular component. Add logic related with metrics values modification (add invocations of metrics source methods). > Implementation of metric source for Ignite Compute > -- > > Key: IGNITE-17356 > URL: https://issues.apache.org/jira/browse/IGNITE-17356 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Following metrics could be useful for Ignite compute: > - total number of tasks that are supposed to be executed locally > - number of completed tasks that were executed locally > What is needed to achieve this: > - Define metrics source class and metrics holder class for ignite compute. > - Define all metric variables in the holder class, if needed. > - Implement initialization logic which is responsible for creation of actual > instances of metrics and building an immutable instance of metrics set (will > be executed on metrics enabling). Implement additional clean up logic if > needed (will be executed on metrics disabled). > - Define methods that implement desirable manipulations with metrics. Every > such method must check the state of the metrics source (enabled\disabled) by > testing the holder reference to null (some kind of guard) before modifying a > metric value. Read holder reference only once and use it in scope of the > method in order to avoid data races. > - Metrics source should be registered in metrics registry on component start > and should be unregistered on component stop. Initial metrics source state > (enabled\disabled) should be set according to configuration for each > particular component. > Add logic related with metrics values modification (add invocations of > metrics source methods). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17356) Implementation of metric source for Ignite Compute
[ https://issues.apache.org/jira/browse/IGNITE-17356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-17356: -- Description: What is needed to achieve this: - Define metrics source class and metrics holder class for ignite compute. - Define all metric variables in the holder class, if needed. - Implement initialization logic which is responsible for creation of actual instances of metrics and building an immutable instance of metrics set (will be executed on metrics enabling). Implement additional clean up logic if needed (will be executed on metrics disabled). - Define methods that implement desirable manipulations with metrics. Every such method must check the state of the metrics source (enabled\disabled) by testing the holder reference to null (some kind of guard) before modifying a metric value. Read holder reference only once and use it in scope of the method in order to avoid data races. - Metrics source should be registered in metrics registry on component start and should be unregistered on component stop. Initial metrics source state (enabled\disabled) should be set according to configuration for each particular component. Add logic related with metrics values modification (add invocations of metrics source methods). was:TBD > Implementation of metric source for Ignite Compute > -- > > Key: IGNITE-17356 > URL: https://issues.apache.org/jira/browse/IGNITE-17356 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > What is needed to achieve this: > - Define metrics source class and metrics holder class for ignite compute. > - Define all metric variables in the holder class, if needed. > - Implement initialization logic which is responsible for creation of actual > instances of metrics and building an immutable instance of metrics set (will > be executed on metrics enabling). Implement additional clean up logic if > needed (will be executed on metrics disabled). > - Define methods that implement desirable manipulations with metrics. Every > such method must check the state of the metrics source (enabled\disabled) by > testing the holder reference to null (some kind of guard) before modifying a > metric value. Read holder reference only once and use it in scope of the > method in order to avoid data races. > - Metrics source should be registered in metrics registry on component start > and should be unregistered on component stop. Initial metrics source state > (enabled\disabled) should be set according to configuration for each > particular component. > Add logic related with metrics values modification (add invocations of > metrics source methods). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-14487) Table view bulk methods refactoring
[ https://issues.apache.org/jira/browse/IGNITE-14487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-14487: - Assignee: Andrey Mashenkov > Table view bulk methods refactoring > --- > > Key: IGNITE-14487 > URL: https://issues.apache.org/jira/browse/IGNITE-14487 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Original Estimate: 120h > Remaining Estimate: 120h > > org.apache.ignite.internal.table.RecordBinaryViewImpl#wrap use streams that > have performance impact. Let's rewrite it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17356) Implementation of metric source for Ignite Compute
[ https://issues.apache.org/jira/browse/IGNITE-17356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-17356: -- Summary: Implementation of metric source for Ignite Compute (was: Implementation of metric source for RAFT groups or group members) > Implementation of metric source for Ignite Compute > -- > > Key: IGNITE-17356 > URL: https://issues.apache.org/jira/browse/IGNITE-17356 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17438) Unable to sum decimal values which have non-default precision
[
https://issues.apache.org/jira/browse/IGNITE-17438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-17438:
Component/s: sql
> Unable to sum decimal values which have non-default precision
> -
>
> Key: IGNITE-17438
> URL: https://issues.apache.org/jira/browse/IGNITE-17438
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.14
>Reporter: Ivan Gagarkin
>Priority: Critical
>
> Found the bug when creating unit tests.
> Steps to reproduce:
> {code:java}
> cache.query(new SqlFieldsQuery(
> """
> | CREATE TABLE numbers (
> |id LONG,
> |val DOUBLE,
> |int_val LONG,
> |decimal_val DECIMAL(5, 5),
> |PRIMARY KEY (id)) WITH "backups=1"
> """.stripMargin)).getAll
> cache.query(qry.setArgs(18L.asInstanceOf[JLong], new
> java.math.BigDecimal(2.5))).getAll
> cache.query(qry.setArgs(19L.asInstanceOf[JLong], new
> java.math.BigDecimal(3.5))).getAll
> cache.query(qry.setArgs(20L.asInstanceOf[JLong], new
> java.math.BigDecimal(4.5))).getAll
> cache.query(qry.setArgs(21L.asInstanceOf[JLong], new
> java.math.BigDecimal(4.5))).getAll
> cache.query(new SqlFieldsQuery("SELECT SUM(decimal_val) FROM numbers WHERE id
> IN (18, 19, 20)")).getAll{code}
> Result:
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Numeric
> value out of range: "5"; SQL statement:
> SELECT
> CAST(CAST(SUM(__C0_0) AS DECIMAL(5, 5)) AS DECIMAL(5, 5)) __C0_0
> FROM PUBLIC.__T0 [22003-197] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17428) Race between creating table and getting table, between creating schema and getting schema
[
https://issues.apache.org/jira/browse/IGNITE-17428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17428:
-
Description:
Current version of TableManager#tableAsyncInternal can possibly not detect
table that is being created while tableAsyncInternal is called. Scenario:
- tableAsyncInternal checks tablesByIdVv.latest() and there is no table
- the table creation started, table metadata appears in meta storage
- TableEvent.CREATE is fired
- tableAsyncInternal registers a listener for TableEvent.CREATE (after it is
fired for corresponding table)
- tableAsyncInternal checks tablesByIdVv.latest() once again and there still is
no table, because the table creation is not completed
- {{!isTableConfigured(id)}} condition returns *false* as the table is present
in meta storage
- {{if (tbl != null && getTblFut.complete(tbl) || !isTableConfigured(id) &&
getTblFut.complete(null))}} evaluates *false* and the future created fot
getTable never completes.
Possibly we should use VersionedValue#whenComplete instead of creating listener
for event. The table is present in map wrapped in versioned value only when the
table creation is completed, and whenComplete allows to create a callback to
check the table presence.
The same problem is presented for {{SchemaManager}} when we get schema in
{{SchemaManager#tableSchema}}
Possible fix for {{SchemaManager}} is to use this pattern
{code:java}
registriesVv.whenComplete((token, val, e) -> {
if (schemaVer <= val.get(tblId).lastSchemaVersion()) {
fut.complete(getSchemaDescriptorLocally(schemaVer, tblCfg));
}
});
{code}
instead of creating listener for CREATE event. The same approach can be used
for {{TableManager}}
was:
Current version of TableManager#tableAsyncInternal can possibly not detect
table that is being created while tableAsyncInternal is called. Scenario:
- tableAsyncInternal checks tablesByIdVv.latest() and there is no table
- the table creation started, table metadata appears in meta storage
- TableEvent.CREATE is fired
- tableAsyncInternal registers a listener for TableEvent.CREATE (after it is
fired for corresponding table)
- tableAsyncInternal checks tablesByIdVv.latest() once again and there still is
no table, because the table creation is not completed
- {{!isTableConfigured(id)}} condition returns *false* as the table is present
in meta storage
- {{if (tbl != null && getTblFut.complete(tbl) || !isTableConfigured(id) &&
getTblFut.complete(null))}} evaluates *false* and the future created fot
getTable never completes.
Possibly we should use VersionedValue#whenComplete instead of creating listener
for event. The table is present in map wrapped in versioned value only when the
table creation is completed, and whenComplete allows to create a callback to
check the table presence.
The same problem is presented for {{SchemaManager}} when we get schema in
{{SchemaManager#tableSchema}}
> Race between creating table and getting table, between creating schema and
> getting schema
> -
>
> Key: IGNITE-17428
> URL: https://issues.apache.org/jira/browse/IGNITE-17428
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Current version of TableManager#tableAsyncInternal can possibly not detect
> table that is being created while tableAsyncInternal is called. Scenario:
> - tableAsyncInternal checks tablesByIdVv.latest() and there is no table
> - the table creation started, table metadata appears in meta storage
> - TableEvent.CREATE is fired
> - tableAsyncInternal registers a listener for TableEvent.CREATE (after it is
> fired for corresponding table)
> - tableAsyncInternal checks tablesByIdVv.latest() once again and there still
> is no table, because the table creation is not completed
> - {{!isTableConfigured(id)}} condition returns *false* as the table is
> present in meta storage
> - {{if (tbl != null && getTblFut.complete(tbl) || !isTableConfigured(id) &&
> getTblFut.complete(null))}} evaluates *false* and the future created fot
> getTable never completes.
> Possibly we should use VersionedValue#whenComplete instead of creating
> listener for event. The table is present in map wrapped in versioned value
> only when the table creation is completed, and whenComplete allows to create
> a callback to check the table presence.
> The same problem is presented for {{SchemaManager}} when we get schema in
> {{SchemaManager#tableSchema}}
> Possible fix for {{SchemaManager}} is to use this pattern
> {code:java}
> registriesVv.whenComplete((token, val, e) -> {
> if (schemaVer <= val.get(tblId).lastSchemaVersion()) {
>
[jira] [Updated] (IGNITE-17428) Race between creating table and getting table, between creating schema and getting schema
[
https://issues.apache.org/jira/browse/IGNITE-17428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17428:
-
Description:
Current version of TableManager#tableAsyncInternal can possibly not detect
table that is being created while tableAsyncInternal is called. Scenario:
- tableAsyncInternal checks tablesByIdVv.latest() and there is no table
- the table creation started, table metadata appears in meta storage
- TableEvent.CREATE is fired
- tableAsyncInternal registers a listener for TableEvent.CREATE (after it is
fired for corresponding table)
- tableAsyncInternal checks tablesByIdVv.latest() once again and there still is
no table, because the table creation is not completed
- {{!isTableConfigured(id)}} condition returns *false* as the table is present
in meta storage
- {{if (tbl != null && getTblFut.complete(tbl) || !isTableConfigured(id) &&
getTblFut.complete(null))}} evaluates *false* and the future created fot
getTable never completes.
Possibly we should use VersionedValue#whenComplete instead of creating listener
for event. The table is present in map wrapped in versioned value only when the
table creation is completed, and whenComplete allows to create a callback to
check the table presence.
The same problem is presented for {{SchemaManager}} when we get schema in
{{SchemaManager#tableSchema}}
was:
Current version of TableManager#tableAsyncInternal can possibly not detect
table that is being created while tableAsyncInternal is called. Scenario:
- tableAsyncInternal checks tablesByIdVv.latest() and there is no table
- the table creation started, table metadata appears in meta storage
- TableEvent.CREATE is fired
- tableAsyncInternal registers a listener for TableEvent.CREATE (after it is
fired for corresponding table)
- tableAsyncInternal checks tablesByIdVv.latest() once again and there still is
no table, because the table creation is not completed
- {{!isTableConfigured(id)}} condition returns *false* as the table is present
in meta storage
- {{if (tbl != null && getTblFut.complete(tbl) || !isTableConfigured(id) &&
getTblFut.complete(null))}} evaluates *false* and the future created fot
getTable never completes.
Possibly we should use VersionedValue#whenComplete instead of creating listener
for event. The table is present in map wrapped in versioned value only when the
table creation is completed, and whenComplete allows to create a callback to
check the table presence.
> Race between creating table and getting table, between creating schema and
> getting schema
> -
>
> Key: IGNITE-17428
> URL: https://issues.apache.org/jira/browse/IGNITE-17428
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Current version of TableManager#tableAsyncInternal can possibly not detect
> table that is being created while tableAsyncInternal is called. Scenario:
> - tableAsyncInternal checks tablesByIdVv.latest() and there is no table
> - the table creation started, table metadata appears in meta storage
> - TableEvent.CREATE is fired
> - tableAsyncInternal registers a listener for TableEvent.CREATE (after it is
> fired for corresponding table)
> - tableAsyncInternal checks tablesByIdVv.latest() once again and there still
> is no table, because the table creation is not completed
> - {{!isTableConfigured(id)}} condition returns *false* as the table is
> present in meta storage
> - {{if (tbl != null && getTblFut.complete(tbl) || !isTableConfigured(id) &&
> getTblFut.complete(null))}} evaluates *false* and the future created fot
> getTable never completes.
> Possibly we should use VersionedValue#whenComplete instead of creating
> listener for event. The table is present in map wrapped in versioned value
> only when the table creation is completed, and whenComplete allows to create
> a callback to check the table presence.
> The same problem is presented for {{SchemaManager}} when we get schema in
> {{SchemaManager#tableSchema}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17428) Race between creating table and getting table, between creating schema and getting schema
[
https://issues.apache.org/jira/browse/IGNITE-17428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17428:
-
Summary: Race between creating table and getting table, between creating
schema and getting schema (was: Race between table create and table get,
between creating schema and getting schema in )
> Race between creating table and getting table, between creating schema and
> getting schema
> -
>
> Key: IGNITE-17428
> URL: https://issues.apache.org/jira/browse/IGNITE-17428
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Current version of TableManager#tableAsyncInternal can possibly not detect
> table that is being created while tableAsyncInternal is called. Scenario:
> - tableAsyncInternal checks tablesByIdVv.latest() and there is no table
> - the table creation started, table metadata appears in meta storage
> - TableEvent.CREATE is fired
> - tableAsyncInternal registers a listener for TableEvent.CREATE (after it is
> fired for corresponding table)
> - tableAsyncInternal checks tablesByIdVv.latest() once again and there still
> is no table, because the table creation is not completed
> - {{!isTableConfigured(id)}} condition returns *false* as the table is
> present in meta storage
> - {{if (tbl != null && getTblFut.complete(tbl) || !isTableConfigured(id) &&
> getTblFut.complete(null))}} evaluates *false* and the future created fot
> getTable never completes.
> Possibly we should use VersionedValue#whenComplete instead of creating
> listener for event. The table is present in map wrapped in versioned value
> only when the table creation is completed, and whenComplete allows to create
> a callback to check the table presence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17428) Race between table create and table get, between creating schema and getting schema in
[
https://issues.apache.org/jira/browse/IGNITE-17428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17428:
-
Summary: Race between table create and table get, between creating schema
and getting schema in (was: Race between table create and table get)
> Race between table create and table get, between creating schema and getting
> schema in
> ---
>
> Key: IGNITE-17428
> URL: https://issues.apache.org/jira/browse/IGNITE-17428
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Current version of TableManager#tableAsyncInternal can possibly not detect
> table that is being created while tableAsyncInternal is called. Scenario:
> - tableAsyncInternal checks tablesByIdVv.latest() and there is no table
> - the table creation started, table metadata appears in meta storage
> - TableEvent.CREATE is fired
> - tableAsyncInternal registers a listener for TableEvent.CREATE (after it is
> fired for corresponding table)
> - tableAsyncInternal checks tablesByIdVv.latest() once again and there still
> is no table, because the table creation is not completed
> - {{!isTableConfigured(id)}} condition returns *false* as the table is
> present in meta storage
> - {{if (tbl != null && getTblFut.complete(tbl) || !isTableConfigured(id) &&
> getTblFut.complete(null))}} evaluates *false* and the future created fot
> getTable never completes.
> Possibly we should use VersionedValue#whenComplete instead of creating
> listener for event. The table is present in map wrapped in versioned value
> only when the table creation is completed, and whenComplete allows to create
> a callback to check the table presence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17441) Revise SQL related resolved tickets but still presented mentions in code AI3
[ https://issues.apache.org/jira/browse/IGNITE-17441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-17441: -- Assignee: Yury Gerzhedovich > Revise SQL related resolved tickets but still presented mentions in code AI3 > > > Key: IGNITE-17441 > URL: https://issues.apache.org/jira/browse/IGNITE-17441 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > We have a bunch of resolved tickes which still present as TODO in AI3 code. > Let's get it right. > List of issues: > https://issues.apache.org/jira/browse/IGNITE-14636 > https://issues.apache.org/jira/browse/IGNITE-14730 > https://issues.apache.org/jira/browse/IGNITE-15031 > https://issues.apache.org/jira/browse/IGNITE-15412 > https://issues.apache.org/jira/browse/IGNITE-15584 > https://issues.apache.org/jira/browse/IGNITE-1 > https://issues.apache.org/jira/browse/IGNITE-16468 > https://issues.apache.org/jira/browse/IGNITE-16967 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17441) Revise SQL related resolved tickets but still presented mentions in code AI3
[ https://issues.apache.org/jira/browse/IGNITE-17441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17441: --- Component/s: sql > Revise SQL related resolved tickets but still presented mentions in code AI3 > > > Key: IGNITE-17441 > URL: https://issues.apache.org/jira/browse/IGNITE-17441 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > We have a bunch of resolved tickes which still present as TODO in AI3 code. > Let's get it right. > List of issues: > https://issues.apache.org/jira/browse/IGNITE-14636 > https://issues.apache.org/jira/browse/IGNITE-14730 > https://issues.apache.org/jira/browse/IGNITE-15031 > https://issues.apache.org/jira/browse/IGNITE-15412 > https://issues.apache.org/jira/browse/IGNITE-15584 > https://issues.apache.org/jira/browse/IGNITE-1 > https://issues.apache.org/jira/browse/IGNITE-16468 > https://issues.apache.org/jira/browse/IGNITE-16967 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17441) Revise SQL related resolved tickets but still presented mentions in code AI3
[ https://issues.apache.org/jira/browse/IGNITE-17441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17441: --- Description: We have a bunch of resolved tickes which still present as TODO in AI3 code. Let's get it right. List of issues: https://issues.apache.org/jira/browse/IGNITE-14636 https://issues.apache.org/jira/browse/IGNITE-14730 https://issues.apache.org/jira/browse/IGNITE-15031 https://issues.apache.org/jira/browse/IGNITE-15412 https://issues.apache.org/jira/browse/IGNITE-15584 https://issues.apache.org/jira/browse/IGNITE-1 https://issues.apache.org/jira/browse/IGNITE-16468 https://issues.apache.org/jira/browse/IGNITE-16967 was: We have a bunch of resolved tickes which still present as TODO in AI3 code. Let's get it right. List of issues: https://issues.apache.org/jira/browse/IGNITE-14730 https://issues.apache.org/jira/browse/IGNITE-15031 https://issues.apache.org/jira/browse/IGNITE-15412 https://issues.apache.org/jira/browse/IGNITE-15584 https://issues.apache.org/jira/browse/IGNITE-16468 https://issues.apache.org/jira/browse/IGNITE-16967 > Revise SQL related resolved tickets but still presented mentions in code AI3 > > > Key: IGNITE-17441 > URL: https://issues.apache.org/jira/browse/IGNITE-17441 > Project: Ignite > Issue Type: Improvement >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > We have a bunch of resolved tickes which still present as TODO in AI3 code. > Let's get it right. > List of issues: > https://issues.apache.org/jira/browse/IGNITE-14636 > https://issues.apache.org/jira/browse/IGNITE-14730 > https://issues.apache.org/jira/browse/IGNITE-15031 > https://issues.apache.org/jira/browse/IGNITE-15412 > https://issues.apache.org/jira/browse/IGNITE-15584 > https://issues.apache.org/jira/browse/IGNITE-1 > https://issues.apache.org/jira/browse/IGNITE-16468 > https://issues.apache.org/jira/browse/IGNITE-16967 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17441) Revise SQL related resolved tickets but still presented mentions in code AI3
[ https://issues.apache.org/jira/browse/IGNITE-17441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17441: --- Labels: ignite-3 (was: ) > Revise SQL related resolved tickets but still presented mentions in code AI3 > > > Key: IGNITE-17441 > URL: https://issues.apache.org/jira/browse/IGNITE-17441 > Project: Ignite > Issue Type: Improvement >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > We have a bunch of resolved tickes which still present as TODO in AI3 code. > Let's get it right. > List of issues: > https://issues.apache.org/jira/browse/IGNITE-14730 > https://issues.apache.org/jira/browse/IGNITE-15031 > https://issues.apache.org/jira/browse/IGNITE-15412 > https://issues.apache.org/jira/browse/IGNITE-15584 > https://issues.apache.org/jira/browse/IGNITE-16468 > https://issues.apache.org/jira/browse/IGNITE-16967 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17441) Revise SQL related resolved tickets but still presented mentions in code AI3
Yury Gerzhedovich created IGNITE-17441: -- Summary: Revise SQL related resolved tickets but still presented mentions in code AI3 Key: IGNITE-17441 URL: https://issues.apache.org/jira/browse/IGNITE-17441 Project: Ignite Issue Type: Improvement Reporter: Yury Gerzhedovich We have a bunch of resolved tickes which still present as TODO in AI3 code. Let's get it right. List of issues: https://issues.apache.org/jira/browse/IGNITE-14730 https://issues.apache.org/jira/browse/IGNITE-15031 https://issues.apache.org/jira/browse/IGNITE-15412 https://issues.apache.org/jira/browse/IGNITE-15584 https://issues.apache.org/jira/browse/IGNITE-16468 https://issues.apache.org/jira/browse/IGNITE-16967 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17440) SQL API should use Statements parameters in Ignite 3
Yury Gerzhedovich created IGNITE-17440: -- Summary: SQL API should use Statements parameters in Ignite 3 Key: IGNITE-17440 URL: https://issues.apache.org/jira/browse/IGNITE-17440 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich We don't use any parameters from Statements except a query text for execution query throuht Session. So no any parameters like a timeout, schema and so one is used. Need to implement pass the parameters to server and start use it. Start point is org.apache.ignite.internal.sql.api.SessionImpl#executeAsync -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17439) Small enhancements for BinaryTuple
Aleksey Demakov created IGNITE-17439: Summary: Small enhancements for BinaryTuple Key: IGNITE-17439 URL: https://issues.apache.org/jira/browse/IGNITE-17439 Project: Ignite Issue Type: Improvement Components: ignite-3 Reporter: Aleksey Demakov Assignee: Aleksey Demakov Fix For: 3.0.0-alpha6 In the initial BinaryTuple implementation there are a few places where the code could be improved. E.g. in one place there is a field that could be declared final, in another place there is a method that is quite useless, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17347) Add port parameters to Ignite3 CLI node start command
[ https://issues.apache.org/jira/browse/IGNITE-17347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev updated IGNITE-17347: -- Description: Currently Ignite3 CLI node start command only provides a way to set different port parameters via supplying a different configuration file. This makes it somewhat cumbersome to start multple nodes on the same machine. Let's provide --port and --rest-port parameters to the node start command to make it easier. In order to properly test a cluster on the same machine, --join parameter is also needed which will provide a list of seed nodes to join physical topology. was: Currently Ignite3 CLI node start command only provides a way to set different port parameters via supplying a different configuration file. This makes it somewhat cumbersome to start multple nodes on the same machine. Let's provide --port and --rest-port parameters to the node start command to make it easier. > Add port parameters to Ignite3 CLI node start command > - > > Key: IGNITE-17347 > URL: https://issues.apache.org/jira/browse/IGNITE-17347 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Yury Yudin >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite3 > > Currently Ignite3 CLI node start command only provides a way to set different > port parameters via supplying a different configuration file. This makes it > somewhat cumbersome to start multple nodes on the same machine. > Let's provide --port and --rest-port parameters to the node start command to > make it easier. > In order to properly test a cluster on the same machine, --join parameter is > also needed which will provide a list of seed nodes to join physical topology. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17438) Unable to sum decimal values which have non-default precision
[
https://issues.apache.org/jira/browse/IGNITE-17438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-17438:
---
Description:
Found the bug when creating unit tests.
Steps to reproduce:
{code:java}
cache.query(new SqlFieldsQuery(
"""
| CREATE TABLE numbers (
|id LONG,
|val DOUBLE,
|int_val LONG,
|decimal_val DECIMAL(5, 5),
|PRIMARY KEY (id)) WITH "backups=1"
""".stripMargin)).getAll
cache.query(qry.setArgs(18L.asInstanceOf[JLong], new
java.math.BigDecimal(2.5))).getAll
cache.query(qry.setArgs(19L.asInstanceOf[JLong], new
java.math.BigDecimal(3.5))).getAll
cache.query(qry.setArgs(20L.asInstanceOf[JLong], new
java.math.BigDecimal(4.5))).getAll
cache.query(qry.setArgs(21L.asInstanceOf[JLong], new
java.math.BigDecimal(4.5))).getAll
cache.query(new SqlFieldsQuery("SELECT SUM(decimal_val) FROM numbers WHERE id
IN (18, 19, 20)")).getAll{code}
Result:
{code:java}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Numeric
value out of range: "5"; SQL statement:
SELECT
CAST(CAST(SUM(__C0_0) AS DECIMAL(5, 5)) AS DECIMAL(5, 5)) __C0_0
FROM PUBLIC.__T0 [22003-197] {code}
was:
Version: the current master branch
Found the bug when creating unit tests.
Steps to reproduce:
{code:java}
cache.query(new SqlFieldsQuery(
"""
| CREATE TABLE numbers (
|id LONG,
|val DOUBLE,
|int_val LONG,
|decimal_val DECIMAL(5, 5),
|PRIMARY KEY (id)) WITH "backups=1"
""".stripMargin)).getAll
cache.query(qry.setArgs(18L.asInstanceOf[JLong], new
java.math.BigDecimal(2.5))).getAll
cache.query(qry.setArgs(19L.asInstanceOf[JLong], new
java.math.BigDecimal(3.5))).getAll
cache.query(qry.setArgs(20L.asInstanceOf[JLong], new
java.math.BigDecimal(4.5))).getAll
cache.query(qry.setArgs(21L.asInstanceOf[JLong], new
java.math.BigDecimal(4.5))).getAll
cache.query(new SqlFieldsQuery("SELECT SUM(decimal_val) FROM numbers WHERE id
IN (18, 19, 20)")).getAll{code}
Result:
{code:java}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Numeric
value out of range: "5"; SQL statement:
SELECT
CAST(CAST(SUM(__C0_0) AS DECIMAL(5, 5)) AS DECIMAL(5, 5)) __C0_0
FROM PUBLIC.__T0 [22003-197] {code}
> Unable to sum decimal values which have non-default precision
> -
>
> Key: IGNITE-17438
> URL: https://issues.apache.org/jira/browse/IGNITE-17438
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Ivan Gagarkin
>Priority: Critical
>
> Found the bug when creating unit tests.
> Steps to reproduce:
> {code:java}
> cache.query(new SqlFieldsQuery(
> """
> | CREATE TABLE numbers (
> |id LONG,
> |val DOUBLE,
> |int_val LONG,
> |decimal_val DECIMAL(5, 5),
> |PRIMARY KEY (id)) WITH "backups=1"
> """.stripMargin)).getAll
> cache.query(qry.setArgs(18L.asInstanceOf[JLong], new
> java.math.BigDecimal(2.5))).getAll
> cache.query(qry.setArgs(19L.asInstanceOf[JLong], new
> java.math.BigDecimal(3.5))).getAll
> cache.query(qry.setArgs(20L.asInstanceOf[JLong], new
> java.math.BigDecimal(4.5))).getAll
> cache.query(qry.setArgs(21L.asInstanceOf[JLong], new
> java.math.BigDecimal(4.5))).getAll
> cache.query(new SqlFieldsQuery("SELECT SUM(decimal_val) FROM numbers WHERE id
> IN (18, 19, 20)")).getAll{code}
> Result:
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Numeric
> value out of range: "5"; SQL statement:
> SELECT
> CAST(CAST(SUM(__C0_0) AS DECIMAL(5, 5)) AS DECIMAL(5, 5)) __C0_0
> FROM PUBLIC.__T0 [22003-197] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17438) Unable to sum decimal values which have non-default precision
[
https://issues.apache.org/jira/browse/IGNITE-17438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-17438:
---
Affects Version/s: 2.14
> Unable to sum decimal values which have non-default precision
> -
>
> Key: IGNITE-17438
> URL: https://issues.apache.org/jira/browse/IGNITE-17438
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Ivan Gagarkin
>Priority: Critical
>
> Version: the current master branch
> Found the bug when creating unit tests.
> Steps to reproduce:
> {code:java}
> cache.query(new SqlFieldsQuery(
> """
> | CREATE TABLE numbers (
> |id LONG,
> |val DOUBLE,
> |int_val LONG,
> |decimal_val DECIMAL(5, 5),
> |PRIMARY KEY (id)) WITH "backups=1"
> """.stripMargin)).getAll
> cache.query(qry.setArgs(18L.asInstanceOf[JLong], new
> java.math.BigDecimal(2.5))).getAll
> cache.query(qry.setArgs(19L.asInstanceOf[JLong], new
> java.math.BigDecimal(3.5))).getAll
> cache.query(qry.setArgs(20L.asInstanceOf[JLong], new
> java.math.BigDecimal(4.5))).getAll
> cache.query(qry.setArgs(21L.asInstanceOf[JLong], new
> java.math.BigDecimal(4.5))).getAll
> cache.query(new SqlFieldsQuery("SELECT SUM(decimal_val) FROM numbers WHERE id
> IN (18, 19, 20)")).getAll{code}
> Result:
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Numeric
> value out of range: "5"; SQL statement:
> SELECT
> CAST(CAST(SUM(__C0_0) AS DECIMAL(5, 5)) AS DECIMAL(5, 5)) __C0_0
> FROM PUBLIC.__T0 [22003-197] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17438) Unable to sum decimal values which have non-default precision
Ivan Gagarkin created IGNITE-17438:
--
Summary: Unable to sum decimal values which have non-default
precision
Key: IGNITE-17438
URL: https://issues.apache.org/jira/browse/IGNITE-17438
Project: Ignite
Issue Type: Bug
Reporter: Ivan Gagarkin
Version: the current master branch
Found the bug when creating unit tests.
Steps to reproduce:
{code:java}
cache.query(new SqlFieldsQuery(
"""
| CREATE TABLE numbers (
|id LONG,
|val DOUBLE,
|int_val LONG,
|decimal_val DECIMAL(5, 5),
|PRIMARY KEY (id)) WITH "backups=1"
""".stripMargin)).getAll
cache.query(qry.setArgs(18L.asInstanceOf[JLong], new
java.math.BigDecimal(2.5))).getAll
cache.query(qry.setArgs(19L.asInstanceOf[JLong], new
java.math.BigDecimal(3.5))).getAll
cache.query(qry.setArgs(20L.asInstanceOf[JLong], new
java.math.BigDecimal(4.5))).getAll
cache.query(qry.setArgs(21L.asInstanceOf[JLong], new
java.math.BigDecimal(4.5))).getAll
cache.query(new SqlFieldsQuery("SELECT SUM(decimal_val) FROM numbers WHERE id
IN (18, 19, 20)")).getAll{code}
Result:
{code:java}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Numeric
value out of range: "5"; SQL statement:
SELECT
CAST(CAST(SUM(__C0_0) AS DECIMAL(5, 5)) AS DECIMAL(5, 5)) __C0_0
FROM PUBLIC.__T0 [22003-197] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15550) Calcite engine. Support collections constuction from the query
[
https://issues.apache.org/jira/browse/IGNITE-15550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-15550:
---
Labels: calcite calcite3-required ignite-3 (was: calcite calcite2-required
calcite3-required ignite-3)
> Calcite engine. Support collections constuction from the query
> --
>
> Key: IGNITE-15550
> URL: https://issues.apache.org/jira/browse/IGNITE-15550
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Daschinsky
>Priority: Minor
> Labels: calcite, calcite3-required, ignite-3
> Fix For: 2.14
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, queries like:
>
> {noformat}
> SELECT MAP(SELECT 'a', 1)
> SELECT ARRAY(SELECT 1){noformat}
> Can't be executed, since logical plan contains \{{Collect}} relational
> operator and there is no rule and no physical operator to convert this
> logical operator.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17433) SQL API: When cursor is closed, internal exception is thrown from fetchNextPage
[ https://issues.apache.org/jira/browse/IGNITE-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572970#comment-17572970 ] Pavel Tupitsyn commented on IGNITE-17433: - Merged to main: b7c793f780968d2e01012544b609b296e684cadf > SQL API: When cursor is closed, internal exception is thrown from > fetchNextPage > --- > > Key: IGNITE-17433 > URL: https://issues.apache.org/jira/browse/IGNITE-17433 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > * Introduce error code for closed cursor scenario > * Fix client side to throw the same exception too > * Add shared tests to ItSqlAsynchronousApiTest, ItSqlSynchronousApiTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17316) Thin client pluggable affnity function to use partition awareness
[
https://issues.apache.org/jira/browse/IGNITE-17316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572963#comment-17572963
]
Ignite TC Bot commented on IGNITE-17316:
{panel:title=Branch: [pull/10140/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10140/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6702522]]
* {color:#013220}ClientTestSuite:
ThinClientPartitionAwarenessResourceReleaseTest.testResourcesReleasedAfterCacheDestroyed
- PASSED{color}
* {color:#013220}ClientTestSuite:
ThinClientPartitionAwarenessStableTopologyTest.testPartitionedCustomAffinityCacheWithMapper
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6701404buildTypeId=IgniteTests24Java8_RunAll]
> Thin client pluggable affnity function to use partition awareness
> -
>
> Key: IGNITE-17316
> URL: https://issues.apache.org/jira/browse/IGNITE-17316
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.13
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> We should provie a pluggable affinity for the thin client, thus using the
> partition awareness features become possible on only for
> {{RendezvousAffinityFunction}}.
> Dev-list discussion:
> https://lists.apache.org/thread/7n7zbcgw59voxyr08ct3zx2ss5g8q9wh
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16787) Sql calcite. Bump calcite version up to 1.30
[ https://issues.apache.org/jira/browse/IGNITE-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-16787: - Fix Version/s: 2.14 > Sql calcite. Bump calcite version up to 1.30 > > > Key: IGNITE-16787 > URL: https://issues.apache.org/jira/browse/IGNITE-16787 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Seems it would helpful to bump calcite dependency up to > [1.30|https://calcite.apache.org/docs/history.html#v1-30-0] ver. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17437) SQL. Support LISTAGG (aka GROUP_CONCAT, STRING_AGG) aggregate function for ignite 3
Yury Gerzhedovich created IGNITE-17437: -- Summary: SQL. Support LISTAGG (aka GROUP_CONCAT, STRING_AGG) aggregate function for ignite 3 Key: IGNITE-17437 URL: https://issues.apache.org/jira/browse/IGNITE-17437 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich LISTAGG function implemented for Ignite 2, however for Ignite 3 need to rethink design of the solution. TBD: reasons why we want to do it differently. Let's investigate possible ways to implement it. As a result need to implement it, create ticket to document it and unmute the test_order_variable_size_payload.test_ignore test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17436) CacheGroupReencryptionTest#testReencryptionOnUnstableTopology fails if checkpoint is skipped on node stop
Aleksandr Polovtcev created IGNITE-17436:
Summary:
CacheGroupReencryptionTest#testReencryptionOnUnstableTopology fails if
checkpoint is skipped on node stop
Key: IGNITE-17436
URL: https://issues.apache.org/jira/browse/IGNITE-17436
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Steps to reproduce: add {{@WithSystemProperty(key =
IGNITE_PDS_SKIP_CHECKPOINT_ON_NODE_STOP, value = "true")}} annotation to
{{CacheGroupReencryptionTest#testReencryptionOnUnstableTopology}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-16559) Node's log contains "Failed to refresh a leader" messages.
[
https://issues.apache.org/jira/browse/IGNITE-16559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-16559:
Assignee: Sergey Uttsel
> Node's log contains "Failed to refresh a leader" messages.
> ---
>
> Key: IGNITE-16559
> URL: https://issues.apache.org/jira/browse/IGNITE-16559
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> We noticed that when we run
> {{ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand}} on TC it is
> possible that log contain such messages:
> {noformat}
> 2022-02-15 12:36:43:568 +0300
> [ERROR][%ItMixedQueriesTest_null_1%Raft-Group-Client-0][RaftGroupServiceImpl]
> Failed to refresh a leader
> [groupId=8e71fc5e-6b24-4b69-ba5a-6eae4c2165cf_part_16]
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:502)
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.lambda$accept$1(RaftGroupServiceImpl.java:544)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.concurrent.TimeoutException
> {noformat}
> Possible root cause:
> Seems, that we get TimeoutException when we try to get a leader from a client
> for a group, for which leader has not been elected yet. If you check the
> logs, you can see, that we get timeout exception and after that leader for
> the corresponding group has been elected.
> Note that we have only one node and 10 partitions for a table in the test,
> but raft leaders are elected sequentially on a node, so electing 10 leaders
> for raft groups on one node might take a little bit longer.
> Possible solution:
> Increase timeout for a client to get a leader for the first time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17407) The snapshot rate limit does not work correctly when set to values greater than 100 MB per second.
[
https://issues.apache.org/jira/browse/IGNITE-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572864#comment-17572864
]
Pavel Pereslegin commented on IGNITE-17407:
---
[~NSAmelchev],
thanks for the review!
> The snapshot rate limit does not work correctly when set to values greater
> than 100 MB per second.
>
>
> Key: IGNITE-17407
> URL: https://issues.apache.org/jira/browse/IGNITE-17407
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The snapshot rate limit does not work correctly when set to values greater
> than 100 MB per second.
> Currently, the snapshot transfer rate is limited by the BasicRateLimiter.
> Testing shows that limiter is unable to give more than ~119 millions permits
> per second.
> {code:java}
> long dataSize = U.GB;
> BasicRateLimiter limiter = new BasicRateLimiter(dataSize / 2);
> int blockSize =
> IgniteSnapshotManager.SNAPSHOT_LIMITED_TRANSFER_BLOCK_SIZE_BYTES;
> long start = System.currentTimeMillis();
> for (long i = 0; i < dataSize; i+=blockSize)
> limiter.acquire(blockSize);
> long totalSec =
> TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis() - start);
> System.out.println("Speed= " + (dataSize / totalSec));
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17407) The snapshot rate limit does not work correctly when set to values greater than 100 MB per second.
[
https://issues.apache.org/jira/browse/IGNITE-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572862#comment-17572862
]
Ignite TC Bot commented on IGNITE-17407:
{panel:title=Branch: [pull/10167/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10167/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6700902]]
* {color:#013220}IgniteBasicTestSuite: BasicRateLimiterTest.testRateLimit -
PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
BasicRateLimiterTest.testRateLimitMultithreaded - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6701878buildTypeId=IgniteTests24Java8_RunAll]
> The snapshot rate limit does not work correctly when set to values greater
> than 100 MB per second.
>
>
> Key: IGNITE-17407
> URL: https://issues.apache.org/jira/browse/IGNITE-17407
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The snapshot rate limit does not work correctly when set to values greater
> than 100 MB per second.
> Currently, the snapshot transfer rate is limited by the BasicRateLimiter.
> Testing shows that limiter is unable to give more than ~119 millions permits
> per second.
> {code:java}
> long dataSize = U.GB;
> BasicRateLimiter limiter = new BasicRateLimiter(dataSize / 2);
> int blockSize =
> IgniteSnapshotManager.SNAPSHOT_LIMITED_TRANSFER_BLOCK_SIZE_BYTES;
> long start = System.currentTimeMillis();
> for (long i = 0; i < dataSize; i+=blockSize)
> limiter.acquire(blockSize);
> long totalSec =
> TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis() - start);
> System.out.println("Speed= " + (dataSize / totalSec));
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17407) The snapshot rate limit does not work correctly when set to values greater than 100 MB per second.
[
https://issues.apache.org/jira/browse/IGNITE-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17407:
--
Labels: ise (was: )
> The snapshot rate limit does not work correctly when set to values greater
> than 100 MB per second.
>
>
> Key: IGNITE-17407
> URL: https://issues.apache.org/jira/browse/IGNITE-17407
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The snapshot rate limit does not work correctly when set to values greater
> than 100 MB per second.
> Currently, the snapshot transfer rate is limited by the BasicRateLimiter.
> Testing shows that limiter is unable to give more than ~119 millions permits
> per second.
> {code:java}
> long dataSize = U.GB;
> BasicRateLimiter limiter = new BasicRateLimiter(dataSize / 2);
> int blockSize =
> IgniteSnapshotManager.SNAPSHOT_LIMITED_TRANSFER_BLOCK_SIZE_BYTES;
> long start = System.currentTimeMillis();
> for (long i = 0; i < dataSize; i+=blockSize)
> limiter.acquire(blockSize);
> long totalSec =
> TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis() - start);
> System.out.println("Speed= " + (dataSize / totalSec));
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
