[jira] [Updated] (IGNITE-22244) Incorrect error message for config show command
[ https://issues.apache.org/jira/browse/IGNITE-22244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22244: --- Description: [defaultNode]> node config show sql Unknown error Conversion = '|' The error should be like: no such config root "sql". same error for this command: node config show -u http://localhost:10300 was: [defaultNode]> node config show sql Unknown error Conversion = '|' The error should be like: no such config root "sql". > Incorrect error message for config show command > --- > > Key: IGNITE-22244 > URL: https://issues.apache.org/jira/browse/IGNITE-22244 > Project: Ignite > Issue Type: Bug > Components: cli >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > [defaultNode]> node config show sql > Unknown error > Conversion = '|' > The error should be like: no such config root "sql". > same error for this command: node config show -u http://localhost:10300 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22244) Incorrect error message for config show command
Aleksandr created IGNITE-22244: -- Summary: Incorrect error message for config show command Key: IGNITE-22244 URL: https://issues.apache.org/jira/browse/IGNITE-22244 Project: Ignite Issue Type: Bug Components: cli Reporter: Aleksandr [defaultNode]> node config show sql Unknown error Conversion = '|' The error should be like: no such config root "sql". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22181) BigDecimal scale is lost during create table
Aleksandr created IGNITE-22181:
--
Summary: BigDecimal scale is lost during create table
Key: IGNITE-22181
URL: https://issues.apache.org/jira/browse/IGNITE-22181
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr
Given a pojo
{code:java}
@Table
public static class PojoClass {
@Id
private Integer i;
private BigDecimal b;
public Integer getI() {
return i;
}
public void setI(int i) {
this.i = i;
}
public BigDecimal getB() {
return b;
}
public void setB(BigDecimal b) {
this.b = b;
}
{code}
I create a table from it with this call:
{code:java}
client.catalog().create(PojoClass.class).execute();
{code}
Then I insert one record and read it:
{code:java}
var table = client.tables().table(PojoClass.class.getSimpleName());
var pojo = new PojoClass();
pojo.setI(44);
pojo.setB(new BigDecimal("123.45")); // <-- NOTE
var pojoRecordView = table.recordView(PojoClass.class);
pojoRecordView.insert(null, pojo);
var keyPojo = new PojoClass();
keyPojo.setI(44);
assertThat(pojoRecordView.get(null, keyPojo), equalTo(pojo)); <-- THIS FAILS
{code}
The assertion is failed due the scale (2) is lost for the BigDecimal field
during the table creation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22174) Design for UserObjectSerialization
Aleksandr created IGNITE-22174: -- Summary: Design for UserObjectSerialization Key: IGNITE-22174 URL: https://issues.apache.org/jira/browse/IGNITE-22174 Project: Ignite Issue Type: Task Reporter: Aleksandr As a result the IEP should be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22174) Design for UserObjectSerialization
[ https://issues.apache.org/jira/browse/IGNITE-22174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22174: -- Assignee: Aleksandr > Design for UserObjectSerialization > -- > > Key: IGNITE-22174 > URL: https://issues.apache.org/jira/browse/IGNITE-22174 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > > As a result the IEP should be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19848) User object serialization
[ https://issues.apache.org/jira/browse/IGNITE-19848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-19848: -- Assignee: Aleksandr > User object serialization > - > > Key: IGNITE-19848 > URL: https://issues.apache.org/jira/browse/IGNITE-19848 > Project: Ignite > Issue Type: Epic >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21321) Review short options in CLI
[ https://issues.apache.org/jira/browse/IGNITE-21321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840711#comment-17840711 ] Aleksandr commented on IGNITE-21321: https://issues.apache.org/jira/browse/IGNITE-22108 > Review short options in CLI > --- > > Key: IGNITE-21321 > URL: https://issues.apache.org/jira/browse/IGNITE-21321 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > As the CLI grows we see that sometimes there are some clashes in short > options. We have to review all our short options and define the list of these > options. For example, -u means "user" or "url" depending on the context. This > is confusing. > As a result, I would expect the refactoring of short options and dropping > clashes. Also, the command descriptions should be reviewed and improved. The > CLI should be self-descriptive and there should be no need to open a web doc > in most cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22108) Rename options in CLI
[ https://issues.apache.org/jira/browse/IGNITE-22108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22108: -- Assignee: Aleksandr > Rename options in CLI > - > > Key: IGNITE-22108 > URL: https://issues.apache.org/jira/browse/IGNITE-22108 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > The original CLI IEP offers both long and short options for some commands, > for example > --cluster-endpoint-url localhost:8080 and > -u localhost:8080 > The CLI is becoming more complex than it was before. We add new commands and > new options constantly. Now we can observe some confusions in short options > across some commands. > The proposal for CLI short options is to define the following conventions: > - Use exactly one letter for the short options. > - Do not overwrite the one if it is already defined for some command. > - Use short options only for commands that will probably be used frequently. > Proposed short options: > -n for node-name > -h for help > -v for verbose > -u for user > -p for password > All other short options should be dropped. > Also some common options might be shorten: > - cluster-endpoint-url, node-url → url > - cluster-config → config > - cluster-config-file → config-file > - script-file → file > - cluster-name, node-name → name > - meta-storage-node → ms-node -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22108) Rename options in CLI
Aleksandr created IGNITE-22108: -- Summary: Rename options in CLI Key: IGNITE-22108 URL: https://issues.apache.org/jira/browse/IGNITE-22108 Project: Ignite Issue Type: Task Components: cli Reporter: Aleksandr The original CLI IEP offers both long and short options for some commands, for example --cluster-endpoint-url localhost:8080 and -u localhost:8080 The CLI is becoming more complex than it was before. We add new commands and new options constantly. Now we can observe some confusions in short options across some commands. The proposal for CLI short options is to define the following conventions: - Use exactly one letter for the short options. - Do not overwrite the one if it is already defined for some command. - Use short options only for commands that will probably be used frequently. Proposed short options: -n for node-name -h for help -v for verbose -u for user -p for password All other short options should be dropped. Also some common options might be shorten: - cluster-endpoint-url, node-url → url - cluster-config → config - cluster-config-file → config-file - script-file → file - cluster-name, node-name → name - meta-storage-node → ms-node -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22087) Compute Phase 3: batches, pipelines [Design]
[ https://issues.apache.org/jira/browse/IGNITE-22087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22087: -- Assignee: Aleksandr > Compute Phase 3: batches, pipelines [Design] > > > Key: IGNITE-22087 > URL: https://issues.apache.org/jira/browse/IGNITE-22087 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Design the batching processing and pipelines for mapreduce. As a result the > IEP should be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22087) Compute Phase 3: batches, pipelines [Design]
Aleksandr created IGNITE-22087: -- Summary: Compute Phase 3: batches, pipelines [Design] Key: IGNITE-22087 URL: https://issues.apache.org/jira/browse/IGNITE-22087 Project: Ignite Issue Type: Task Reporter: Aleksandr Design the batching processing and pipelines for mapreduce. As a result the IEP should be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21850) Fix LogSinkTest
[
https://issues.apache.org/jira/browse/IGNITE-21850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-21850:
--
Assignee: Aleksandr
> Fix LogSinkTest
> ---
>
> Key: IGNITE-21850
> URL: https://issues.apache.org/jira/browse/IGNITE-21850
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> The test is disabled because it fails on CI
> {code:java}
> java.nio.file.NoSuchFileException:
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/eventlog/build/event.log
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:182)
> at java.base/java.nio.channels.FileChannel.open(FileChannel.java:292)
> at java.base/java.nio.channels.FileChannel.open(FileChannel.java:345)
> at java.base/java.nio.file.Files.lines(Files.java:4038)
> at java.base/java.nio.file.Files.lines(Files.java:4130)
> at
> org.apache.ignite.internal.eventlog.sink.LogSinkTest.readLines(LogSinkTest.java:103)
> at
> org.apache.ignite.internal.eventlog.sink.LogSinkTest.lambda$logsToFile$2(LogSinkTest.java:80)
> at
> org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:248)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:235)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19949) Completers don't work properly in case of when different completers have the same action option
[
https://issues.apache.org/jira/browse/IGNITE-19949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-19949:
--
Assignee: Aleksandr
> Completers don't work properly in case of when different completers have the
> same action option
> ---
>
> Key: IGNITE-19949
> URL: https://issues.apache.org/jira/browse/IGNITE-19949
> Project: Ignite
> Issue Type: Bug
> Components: cli
>Reporter: Ivan Gagarkin
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> Completers don't work when they have different commands but the same option
> {code:java}
> @Test
> void sameOptionDifferentCompleters() {
> // Given
> registry.register(
> CompleterConf.builder()
> .command("command", "subcommand1")
> .enableOptions("--to")
> .exclusiveEnableOptions().build(),
> words -> completer1
> );
> registry.register(
> CompleterConf.builder()
> .command("command", "subcommand2")
> .enableOptions("--to")
> .exclusiveEnableOptions().build(),
> words -> completer2);
> // Then
> assertThat(registry.findCompleters(words("command", "subcommand1",
> "--to")), containsInAnyOrder(completer1));
> // And
> assertThat(registry.findCompleters(words("command", "subcommand2",
> "--to")), containsInAnyOrder(completer2));
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21905) Add integration tests for eventlog configuration
[ https://issues.apache.org/jira/browse/IGNITE-21905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-21905: -- Assignee: Aleksandr > Add integration tests for eventlog configuration > > > Key: IGNITE-21905 > URL: https://issues.apache.org/jira/browse/IGNITE-21905 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Now we have a lack of integration tests for eventlog feature. There are > multiple constraints for the configuration that should be tested: the linkt > to the channel from the sink should be valid (on any config change), the set > of events in channel should be valid event types. > Also we should write integration tests for the configuration changes on > running cluster and prove that the evenlog feature reflects any configuration > changes without cluster restart.r -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21905) Add integration tests for eventlog configuration
Aleksandr created IGNITE-21905: -- Summary: Add integration tests for eventlog configuration Key: IGNITE-21905 URL: https://issues.apache.org/jira/browse/IGNITE-21905 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Now we have a lack of integration tests for eventlog feature. There are multiple constraints for the configuration that should be tested: the linkt to the channel from the sink should be valid (on any config change), the set of events in channel should be valid event types. Also we should write integration tests for the configuration changes on running cluster and prove that the evenlog feature reflects any configuration changes without cluster restart.r -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21904) Improve serializers architecture
Aleksandr created IGNITE-21904: -- Summary: Improve serializers architecture Key: IGNITE-21904 URL: https://issues.apache.org/jira/browse/IGNITE-21904 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Now the serialization for events are done in single class and this is not extendible. For example, if some module wants to add its own event, it is hard to figure out how to register a serializer for that. We should rework the architecture of the serialization in the eventlog module in order to make it open for extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21321) Review short options in CLI
[ https://issues.apache.org/jira/browse/IGNITE-21321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-21321: -- Assignee: Aleksandr > Review short options in CLI > --- > > Key: IGNITE-21321 > URL: https://issues.apache.org/jira/browse/IGNITE-21321 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > As the CLI grows we see that sometimes there are some clashes in short > options. We have to review all our short options and define the list of these > options. For example, -u means "user" or "url" depending on the context. This > is confusing. > As a result, I would expect the refactoring of short options and dropping > clashes. Also, the command descriptions should be reviewed and improved. The > CLI should be self-descriptive and there should be no need to open a web doc > in most cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21850) Fix LogSinkTest
Aleksandr created IGNITE-21850:
--
Summary: Fix LogSinkTest
Key: IGNITE-21850
URL: https://issues.apache.org/jira/browse/IGNITE-21850
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr
The test is disabled because it fails on CI
{code:java}
java.nio.file.NoSuchFileException:
/opt/buildagent/work/b8d4df1365f1f1e5/modules/eventlog/build/event.log
at
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
at
java.base/sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:182)
at java.base/java.nio.channels.FileChannel.open(FileChannel.java:292)
at java.base/java.nio.channels.FileChannel.open(FileChannel.java:345)
at java.base/java.nio.file.Files.lines(Files.java:4038)
at java.base/java.nio.file.Files.lines(Files.java:4130)
at
org.apache.ignite.internal.eventlog.sink.LogSinkTest.readLines(LogSinkTest.java:103)
at
org.apache.ignite.internal.eventlog.sink.LogSinkTest.lambda$logsToFile$2(LogSinkTest.java:80)
at
org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53)
at
org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:248)
at
org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:235)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
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)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21846) Exclude IDEA-generated comments from style checks
[
https://issues.apache.org/jira/browse/IGNITE-21846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-21846.
Resolution: Fixed
Merged into main: 1ac8094b4cef05cfcf202c15420299c18eb26ae7
> Exclude IDEA-generated comments from style checks
> -
>
> Key: IGNITE-21846
> URL: https://issues.apache.org/jira/browse/IGNITE-21846
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Vadim Pakhnushev
>Assignee: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Inserting {{//noinspection}} comments using IDEA intentions results in failed
> checkstyle build. We should exclude these.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21665) Implement EventLog
[ https://issues.apache.org/jira/browse/IGNITE-21665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-21665: -- Assignee: Aleksandr > Implement EventLog > -- > > Key: IGNITE-21665 > URL: https://issues.apache.org/jira/browse/IGNITE-21665 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Given FileSink and CONNECTION_ESTABLISHED/CONNECTION_CLOSED events > implemented we have to be able to configure a channel for it with > CONNECTION_ESTABLISHED and CONNECTION_CLOSED events. Besides the > configuration the EventLog itself should be implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21813) checkstyle-suppressions.xml is not working
[ https://issues.apache.org/jira/browse/IGNITE-21813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-21813: -- Assignee: Aleksandr > checkstyle-suppressions.xml is not working > -- > > Key: IGNITE-21813 > URL: https://issues.apache.org/jira/browse/IGNITE-21813 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > It turned out that the checkstyle-supressions.xml and > checkstyle-disabled-modules.xml are not visible for the checktyle plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21813) checkstyle-suppressions.xml is not working
Aleksandr created IGNITE-21813: -- Summary: checkstyle-suppressions.xml is not working Key: IGNITE-21813 URL: https://issues.apache.org/jira/browse/IGNITE-21813 Project: Ignite Issue Type: Bug Reporter: Aleksandr It turned out that the checkstyle-supressions.xml and checkstyle-disabled-modules.xml are not visible for the checktyle plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21812) Add automatic product version resolve
Aleksandr created IGNITE-21812: -- Summary: Add automatic product version resolve Key: IGNITE-21812 URL: https://issues.apache.org/jira/browse/IGNITE-21812 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Now the product version is hardcoded in EventBuilder but we can fetch the product version automatically from the environment that can be formed during the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21652) Extend PMD ruleset to check more codestyle rules not covered by checkstyle
[ https://issues.apache.org/jira/browse/IGNITE-21652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr resolved IGNITE-21652. Resolution: Fixed Thanks for the contribution, merged into main: b7a31da88c202c10ac0596516e1f4ed91c9b4b8a > Extend PMD ruleset to check more codestyle rules not covered by checkstyle > -- > > Key: IGNITE-21652 > URL: https://issues.apache.org/jira/browse/IGNITE-21652 > Project: Ignite > Issue Type: Improvement > Environment: While working >Reporter: Viacheslav Blinov >Assignee: Viacheslav Blinov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > While Working on IGNITE-20981 some of the rules while being useful requred > extra time to be fit into project, namely: > > > > > > > > > > > ref="category/java/codestyle.xml/FieldDeclarationsShouldBeAtStartOfClass" /> > > > > > This task is to consider them -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21666) Define base events
[ https://issues.apache.org/jira/browse/IGNITE-21666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-21666: -- Assignee: Aleksandr > Define base events > -- > > Key: IGNITE-21666 > URL: https://issues.apache.org/jira/browse/IGNITE-21666 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > The base events should be defined with fields: > - EventType > - User > - Time > - Type-specific fields > Also two event types are defined in this ticket: CONNECTION_ESTABLISHED, > CONNECTION_CLOSED. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21569) Introduce Spotbugs checks
[ https://issues.apache.org/jira/browse/IGNITE-21569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826046#comment-17826046 ] Aleksandr commented on IGNITE-21569: Thank you for the great job, merged into main: 0bd66707244d4e26ad547c087444a97677287cb5 > Introduce Spotbugs checks > - > > Key: IGNITE-21569 > URL: https://issues.apache.org/jira/browse/IGNITE-21569 > Project: Ignite > Issue Type: Improvement >Reporter: Viacheslav Blinov >Assignee: Viacheslav Blinov >Priority: Major > Labels: ignite-3, spotbugs > Fix For: 3.0.0-beta2 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Spotbugs can bring additional value to static code analysis of ignite: > # Remove modernizer plugin and migrate its rules with Spotbugs rule > DM_DEFAULT_ENCODING > # Escape analysis for unclosed Closable instances (OS_OPEN_STREAM, > OS_OPEN_STREAM_EXCEPTION_PATH) > # Checks for misusages of InputStream.read and skip (RR_NOT_CHECKED, > SR_NOT_CHECKED) > There are other reasonable rules Ignite could also benefit from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21735) Upgrade table rendering library
Aleksandr created IGNITE-21735: -- Summary: Upgrade table rendering library Key: IGNITE-21735 URL: https://issues.apache.org/jira/browse/IGNITE-21735 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr We use outdated library for tables rendering in cli (FlipTables). The new version of this library is https://github.com/JakeWharton/picnic The reason why I've started looking at a new library was that we are not able to render ANSI colors inside table's cells. ANSI tags break the calculation logic of borders. We should try to use a new library to render tables with ANSI. I am afraid the same problem for this lib but at least we've tried. In case the problem is not solved, I propose forking of the original library and fixing the problem with ANSI colors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21723) CLI profiles improvements
[ https://issues.apache.org/jira/browse/IGNITE-21723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-21723: --- Description: I've played around with our CLI profiles and configuration here is some thoughts: - Why do "defaults" and "secrets" files do not have ".ini" file type? the lack of this makes it impossible for editors to understand the file type. - Why "defaults" file stores all profiles? For example, vanilla CLI application creates "defaults" file and it is fine. There is a "default" profile configurations under "[default]" ini section and this is fine. But when I create new profile through CLI, say, "apakh" and change a couple of properties, I see "[apakh]" section in the "defaults" file and this is strange. I do not want to see all profile's configurations in the same file named "defaults". - Why do I see empty values for the configurations from "secrets" file when execute "cli config show"? - Why the ordering in properties is mixed when I call "cli config show"? There is a mess and it is hard to find a property I am interested in. - Why do we put "ignite." prefix to every property? Is there any reason for adding a prefix "ignite" to the CLI for "Ignite"? - Why "secrets" file has -rwx-- rights? (+x). - And the most interesting one. Why do we use ".ini" format for configuring our CLI application that is supposed to be use in *unix systems (mostly). I propose the following changes. Introduce a directory-oriented profile management. -- ignitecli/ profiles/ -- default/ config.ini secrets.ini -- apakh/ config.ini secrets.ini Add ".ini" filetype Remove "ignite" prefix from all configuration keys. Do not mix the "cli config show" output. was: I've played around with our CLI profiles and configuration here is some thoughts: - Why do "defaults" and "secrets" files do not have ".ini" file type? the lack of this makes it impossible for editors to understand the file type. - Why "defaults" file stores all profiles? For example, vanilla CLI application creates "defaults" file and it is fine. There is a "default" profile configurations under "[default]" ini section and this is fine. But when I create new profile through CLI, say, "apakh" and change a couple of properties, I see "[apakh]" section in the "defaults" file and this is strange. I do not want to see all profile's configurations in the same file named "defaults". - Why do I see empty values for the configurations from "secrets" file when execute "cli config show"? - Why the ordering in properties is mixed when I call "cli config show"? There is a mess and it is hard to find a property I am interested in. - Why do we put "ignite." prefix to every property? Is there any reason for adding a prefix "ignite" to the CLI for "Ignite"? - And the most interesting one. Why do we use ".ini" format for configuring our CLI application that is supposed to be use in *unix systems (mostly). I propose the following changes. Introduce a directory-oriented profile management. -- ignitecli/ profiles/ -- default/ config.ini secrets.ini -- apakh/ config.ini secrets.ini Add ".ini" filetype Do not mix the "cli config show" output. > CLI profiles improvements > - > > Key: IGNITE-21723 > URL: https://issues.apache.org/jira/browse/IGNITE-21723 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > I've played around with our CLI profiles and configuration here is some > thoughts: > - Why do "defaults" and "secrets" files do not have ".ini" file type? the > lack of this makes it impossible for editors to understand the file type. > - Why "defaults" file stores all profiles? For example, vanilla CLI > application creates "defaults" file and it is fine. There is a "default" > profile configurations under "[default]" ini section and this is fine. But > when I create new profile through CLI, say, "apakh" and change a couple of > properties, I see "[apakh]" section in the "defaults" file and this is > strange. I do not want to see all profile's configurations in the same file > named "defaults". > - Why do I see empty values for the configurations from "secrets" file when > execute "cli config show"? > - Why the ordering in properties is mixed when I call "cli config show"? > There is a mess and it is hard to find a property I am interested in. > - Why do we put "ignite." prefix to every property? Is there any reason for > adding a prefix "ignite" to the CLI for "Ignite"? > - Why "secrets" file has -rwx-- rights? (+x). > - And the most interesting one. Why do we use ".ini" format for
[jira] [Updated] (IGNITE-21723) CLI profiles improvements
[ https://issues.apache.org/jira/browse/IGNITE-21723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-21723: --- Description: I've played around with our CLI profiles and configuration here is some thoughts: - Why do "defaults" and "secrets" files do not have ".ini" file type? the lack of this makes it impossible for editors to understand the file type. - Why "defaults" file stores all profiles? For example, vanilla CLI application creates "defaults" file and it is fine. There is a "default" profile configurations under "[default]" ini section and this is fine. But when I create new profile through CLI, say, "apakh" and change a couple of properties, I see "[apakh]" section in the "defaults" file and this is strange. I do not want to see all profile's configurations in the same file named "defaults". - Why do I see empty values for the configurations from "secrets" file when execute "cli config show"? - Why the ordering in properties is mixed when I call "cli config show"? There is a mess and it is hard to find a property I am interested in. - Why do we put "ignite." prefix to every property? Is there any reason for adding a prefix "ignite" to the CLI for "Ignite"? - And the most interesting one. Why do we use ".ini" format for configuring our CLI application that is supposed to be use in *unix systems (mostly). I propose the following changes. Introduce a directory-oriented profile management. -- ignitecli/ profiles/ -- default/ config.ini secrets.ini -- apakh/ config.ini secrets.ini Add ".ini" filetype Do not mix the "cli config show" output. was: I've played around with our CLI profiles and configuration here is some thoughts: - Why do "defaults" and "secrets" files do not have ".ini" file type? the lack of this makes it impossible for editors to understand the file type. - Why "defaults" file stores all profiles? For example, vanilla CLI application creates "defaults" file and it is fine. There is a "default" profile configurations under "[default]" ini section and this is fine. But when I create new profile through CLI, say, "apakh" and change a couple of properties, I see "[apakh]" section in the "defaults" file and this is strange. I do not want to see all profile's configurations in the same file named "defaults". - Why do I see empty values for the configurations from "secrets" file when execute "cli config show"? - Why the ordering in properties is mixed when I call "cli config show"? There is a mess and it is hard to find a property I am interested in. - And the most interesting one. Why do we use ".ini" format for configuring our CLI application that is supposed to be use in *unix systems (mostly). I propose the following changes. Introduce a directory-oriented profile management. -- ignitecli/ profiles/ -- default/ config.ini secrets.ini -- apakh/ config.ini secrets.ini Add ".ini" filetype Do not mix the "cli config show" output. > CLI profiles improvements > - > > Key: IGNITE-21723 > URL: https://issues.apache.org/jira/browse/IGNITE-21723 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > I've played around with our CLI profiles and configuration here is some > thoughts: > - Why do "defaults" and "secrets" files do not have ".ini" file type? the > lack of this makes it impossible for editors to understand the file type. > - Why "defaults" file stores all profiles? For example, vanilla CLI > application creates "defaults" file and it is fine. There is a "default" > profile configurations under "[default]" ini section and this is fine. But > when I create new profile through CLI, say, "apakh" and change a couple of > properties, I see "[apakh]" section in the "defaults" file and this is > strange. I do not want to see all profile's configurations in the same file > named "defaults". > - Why do I see empty values for the configurations from "secrets" file when > execute "cli config show"? > - Why the ordering in properties is mixed when I call "cli config show"? > There is a mess and it is hard to find a property I am interested in. > - Why do we put "ignite." prefix to every property? Is there any reason for > adding a prefix "ignite" to the CLI for "Ignite"? > - And the most interesting one. Why do we use ".ini" format for configuring > our CLI application that is supposed to be use in *unix systems (mostly). > I propose the following changes. > Introduce a directory-oriented profile management. > -- ignitecli/ > profiles/ > -- default/ > config.ini > secrets.ini >
[jira] [Created] (IGNITE-21723) CLI profiles improvements
Aleksandr created IGNITE-21723: -- Summary: CLI profiles improvements Key: IGNITE-21723 URL: https://issues.apache.org/jira/browse/IGNITE-21723 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr I've played around with our CLI profiles and configuration here is some thoughts: - Why do "defaults" and "secrets" files do not have ".ini" file type? the lack of this makes it impossible for editors to understand the file type. - Why "defaults" file stores all profiles? For example, vanilla CLI application creates "defaults" file and it is fine. There is a "default" profile configurations under "[default]" ini section and this is fine. But when I create new profile through CLI, say, "apakh" and change a couple of properties, I see "[apakh]" section in the "defaults" file and this is strange. I do not want to see all profile's configurations in the same file named "defaults". - Why do I see empty values for the configurations from "secrets" file when execute "cli config show"? - Why the ordering in properties is mixed when I call "cli config show"? There is a mess and it is hard to find a property I am interested in. - And the most interesting one. Why do we use ".ini" format for configuring our CLI application that is supposed to be use in *unix systems (mostly). I propose the following changes. Introduce a directory-oriented profile management. -- ignitecli/ profiles/ -- default/ config.ini secrets.ini -- apakh/ config.ini secrets.ini Add ".ini" filetype Do not mix the "cli config show" output. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21719) Add syntax highlighting into CLI
Aleksandr created IGNITE-21719: -- Summary: Add syntax highlighting into CLI Key: IGNITE-21719 URL: https://issues.apache.org/jira/browse/IGNITE-21719 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr We can use tree-sitter to highlight SQL, HOCON, and INI outputs. I would like to introduce the experimental syntax highlighting and disable it by default (cli.ignite.highlighing = false). Note: as a first iteration we are going to support only standart SQL syntax and HOCON. We can improve it by defining our own parser that supports ignite-specific keywords. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21707) Update openapi-generator
[ https://issues.apache.org/jira/browse/IGNITE-21707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-21707: -- Assignee: Aleksandr > Update openapi-generator > > > Key: IGNITE-21707 > URL: https://issues.apache.org/jira/browse/IGNITE-21707 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3-cli-tool > Time Spent: 10m > Remaining Estimate: 0h > > We use 5.x version of https://github.com/OpenAPITools/openapi-generator but > the latest one is 7.x -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21707) Update openapi-generator
Aleksandr created IGNITE-21707: -- Summary: Update openapi-generator Key: IGNITE-21707 URL: https://issues.apache.org/jira/browse/IGNITE-21707 Project: Ignite Issue Type: Improvement Reporter: Aleksandr We use 5.x version of https://github.com/OpenAPITools/openapi-generator but the latest one is 7.x -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21674) Subcommand completion is broken in CLI
Aleksandr created IGNITE-21674: -- Summary: Subcommand completion is broken in CLI Key: IGNITE-21674 URL: https://issues.apache.org/jira/browse/IGNITE-21674 Project: Ignite Issue Type: Bug Components: cli Reporter: Aleksandr Steps to reproduce: - build cli from main - run interactive mode - (all commands are suggested, it is ok) - choose "cluster" - only one subcommand are completed (all cluster * subcommands expected) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21666) Define base events
Aleksandr created IGNITE-21666: -- Summary: Define base events Key: IGNITE-21666 URL: https://issues.apache.org/jira/browse/IGNITE-21666 Project: Ignite Issue Type: Improvement Reporter: Aleksandr The base events should be defined with fields: - EventType - User - Time - Type-specific fields Also two event types are defined in this ticket: CONNECTION_ESTABLISHED, CONNECTION_CLOSED. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21665) Implement EventLog
[ https://issues.apache.org/jira/browse/IGNITE-21665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-21665: --- Description: Given FileSink and CONNECTION_ESTABLISHED/CONNECTION_CLOSED events implemented we have to be able to configure a channel for it with CONNECTION_ESTABLISHED and CONNECTION_CLOSED events. Besides the configuration the EventLog itself should be implemented. was: Given FileSink implemented we have to be able to configure a channel for it with CONNECTION_ESTABLISHED and CONNECTION_CLOSED events. Besides the configuration the EventLog itself should be implemented. > Implement EventLog > -- > > Key: IGNITE-21665 > URL: https://issues.apache.org/jira/browse/IGNITE-21665 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > > Given FileSink and CONNECTION_ESTABLISHED/CONNECTION_CLOSED events > implemented we have to be able to configure a channel for it with > CONNECTION_ESTABLISHED and CONNECTION_CLOSED events. Besides the > configuration the EventLog itself should be implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21665) Implement EventLog
Aleksandr created IGNITE-21665: -- Summary: Implement EventLog Key: IGNITE-21665 URL: https://issues.apache.org/jira/browse/IGNITE-21665 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Given FileSink implemented we have to be able to configure a channel for it with CONNECTION_ESTABLISHED and CONNECTION_CLOSED events. Besides the configuration the EventLog itself should be implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21529) Implement Log Sink for EventLog
[ https://issues.apache.org/jira/browse/IGNITE-21529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-21529: --- Description: This is a user-configurable entity that is configured via cluster configuration. A Sink defines where events from Channel(s) should be sent to. Examples: logger sink, kafka sink, webhook sink, table sink. Sink has one method that can be called by channel: write(Event). Write does not guarantee that the Event is really written and won’t be lost. But a user can configure a sink that does flush on every write (log4j with synchronous appender and immediateFlush = true). The eventlog.sinks..type = “log” defines the Log Sink where is the name of the unique cluster-wide name. NamedList should be used to define sinks and their names. Here are properties that are Log Sink specific: category (what appender should be used, default: system) level (what logging level should be used, default: INFO). As a result of this ticket there should be a cluster configuration for the File Sink and a base set of EventTypes. was: The first option to write events is to write them to FS. It seems like Logging framework can help us to avoid writing our own. The writing should not be blocking and should not affect the performance of the system. As a result of this ticket internal unit should be implemented. This unit can be configured (where in what format) to write "some" objects. External configurations and Events itself will be implemented later. > Implement Log Sink for EventLog > --- > > Key: IGNITE-21529 > URL: https://issues.apache.org/jira/browse/IGNITE-21529 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > This is a user-configurable entity that is configured via cluster > configuration. A Sink defines where events from Channel(s) should be sent to. > Examples: logger sink, kafka sink, webhook sink, table sink. Sink has one > method that can be called by channel: write(Event). Write does not guarantee > that the Event is really written and won’t be lost. But a user can configure > a sink that does flush on every write (log4j with synchronous appender and > immediateFlush = true). > The eventlog.sinks..type = “log” defines the Log Sink where is > the name of the unique cluster-wide name. NamedList should be used to define > sinks and their names. Here are properties that are Log Sink specific: > category (what appender should be used, default: system) > level (what logging level should be used, default: INFO). > As a result of this ticket there should be a cluster configuration for the > File Sink and a base set of EventTypes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21529) Implement Log Sink for EventLog
[ https://issues.apache.org/jira/browse/IGNITE-21529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-21529: --- Summary: Implement Log Sink for EventLog (was: Implement separate file writer for EventLog) > Implement Log Sink for EventLog > --- > > Key: IGNITE-21529 > URL: https://issues.apache.org/jira/browse/IGNITE-21529 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > The first option to write events is to write them to FS. It seems like > Logging framework can help us to avoid writing our own. The writing should > not be blocking and should not affect the performance of the system. > As a result of this ticket internal unit should be implemented. This unit can > be configured (where in what format) to write "some" objects. External > configurations and Events itself will be implemented later. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21528) Eventlog
[ https://issues.apache.org/jira/browse/IGNITE-21528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-21528: --- Description: https://cwiki.apache.org/confluence/display/IGNITE/IEP-119%3A+Eventlog > Eventlog > > > Key: IGNITE-21528 > URL: https://issues.apache.org/jira/browse/IGNITE-21528 > Project: Ignite > Issue Type: Epic >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-119%3A+Eventlog -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21528) Eventlog
[ https://issues.apache.org/jira/browse/IGNITE-21528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-21528: --- Epic Name: IEP-119: Eventlog (was: EventLog) Summary: Eventlog (was: EventLog for Apache Ignite 3) > Eventlog > > > Key: IGNITE-21528 > URL: https://issues.apache.org/jira/browse/IGNITE-21528 > Project: Ignite > Issue Type: Epic >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21622) Add .editorconfig to the repo
Aleksandr created IGNITE-21622: -- Summary: Add .editorconfig to the repo Key: IGNITE-21622 URL: https://issues.apache.org/jira/browse/IGNITE-21622 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Sometimes I see missing EOF in the PR. I would like to add an .editorconfig to the repo in order to avoid mentioning in everytime in PR. https://editorconfig.org - collect useful options in .editorconfig that will speedup a review process - present them to the community - integrate the config into repository - write documentation if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21529) Implement separate file writer for EventLog
[ https://issues.apache.org/jira/browse/IGNITE-21529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-21529: -- Assignee: Aleksandr > Implement separate file writer for EventLog > --- > > Key: IGNITE-21529 > URL: https://issues.apache.org/jira/browse/IGNITE-21529 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > The first option to write events is to write them to FS. It seems like > Logging framework can help us to avoid writing our own. The writing should > not be blocking and should not affect the performance of the system. > As a result of this ticket internal unit should be implemented. This unit can > be configured (where in what format) to write "some" objects. External > configurations and Events itself will be implemented later. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21529) Implement separate file writer for EventLog
Aleksandr created IGNITE-21529: -- Summary: Implement separate file writer for EventLog Key: IGNITE-21529 URL: https://issues.apache.org/jira/browse/IGNITE-21529 Project: Ignite Issue Type: Improvement Reporter: Aleksandr The first option to write events is to write them to FS. It seems like Logging framework can help us to avoid writing our own. The writing should not be blocking and should not affect the performance of the system. As a result of this ticket internal unit should be implemented. This unit can be configured (where in what format) to write "some" objects. External configurations and Events itself will be implemented later. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21528) EventLog for Apache Ignite 3
Aleksandr created IGNITE-21528: -- Summary: EventLog for Apache Ignite 3 Key: IGNITE-21528 URL: https://issues.apache.org/jira/browse/IGNITE-21528 Project: Ignite Issue Type: Epic Reporter: Aleksandr -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19608) Startup errors are ignored in ignite3db script
[
https://issues.apache.org/jira/browse/IGNITE-19608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-19608:
--
Assignee: Aleksandr (was: Mikhail Pochatkin)
> Startup errors are ignored in ignite3db script
> --
>
> Key: IGNITE-19608
> URL: https://issues.apache.org/jira/browse/IGNITE-19608
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1, 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Aleksandr
>Priority: Blocker
> Labels: cli, ignite-3
>
> Ignite3 node is started by `bin/ignite3db` shell script. Unfortunately, this
> script follows some shell scripting bad practices that makes troubleshooting
> harder when something goes wrong.
> Particullary, there are following issues:
> 1. No guarding bash options (like `nounset`, `errexit`, or `pipefile`) is set.
> 2. When starting Java application, its stderr and stdout are redirected into
> `/dev/null`.
> {code:bash}
> CMD="${JAVA_CMD_WITH_ARGS} ${APPLICATION_ARGS}"
> $CMD >>/dev/null 2>&1 ${IGNITE_HOME}/pid
> {code}
> Just for comparison: [control.sh in
> AI2|https://github.com/apache/ignite/blob/master/bin/control.sh] do not
> suffer from such behavior. This should be fixed in AI3 too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21510) Doc: how to start multiple nodes in the same machine
[ https://issues.apache.org/jira/browse/IGNITE-21510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-21510: -- Assignee: Aleksandr > Doc: how to start multiple nodes in the same machine > > > Key: IGNITE-21510 > URL: https://issues.apache.org/jira/browse/IGNITE-21510 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > Add documentation about how to start more then one node in the same machine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21510) Doc: how to start multiple nodes in the same machine
Aleksandr created IGNITE-21510: -- Summary: Doc: how to start multiple nodes in the same machine Key: IGNITE-21510 URL: https://issues.apache.org/jira/browse/IGNITE-21510 Project: Ignite Issue Type: Improvement Components: build Reporter: Aleksandr Add documentation about how to start more then one node in the same machine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21322) Support SQL multi statements
[ https://issues.apache.org/jira/browse/IGNITE-21322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-21322: -- Assignee: Aleksandr > Support SQL multi statements > > > Key: IGNITE-21322 > URL: https://issues.apache.org/jira/browse/IGNITE-21322 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > The SQL engine now supports executing of multi statements. We have to support > it in the CLI, especially in non-interactive mode (string input and file > input). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21377) Remove redundant tests
[
https://issues.apache.org/jira/browse/IGNITE-21377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-21377.
Resolution: Fixed
Thank you, merged into main: 7bfef7efded59c0c2890a0a83ea5a302881c8102
> Remove redundant tests
> --
>
> Key: IGNITE-21377
> URL: https://issues.apache.org/jira/browse/IGNITE-21377
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ItNotInitializedClusterRestTest}} has several tests that are duplicated in
> the {{{}ItClusterStateHttpServerFilterNotInitializedTest{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21322) Support SQL multi statements
Aleksandr created IGNITE-21322: -- Summary: Support SQL multi statements Key: IGNITE-21322 URL: https://issues.apache.org/jira/browse/IGNITE-21322 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr The SQL engine now supports executing of multi statements. We have to support it in the CLI, especially in non-interactive mode (string input and file input). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21321) Review short options in CLI
Aleksandr created IGNITE-21321: -- Summary: Review short options in CLI Key: IGNITE-21321 URL: https://issues.apache.org/jira/browse/IGNITE-21321 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr As the CLI grows we see that sometimes there are some clashes in short options. We have to review all our short options and define the list of these options. For example, -u means "user" or "url" depending on the context. This is confusing. As a result, I would expect the refactoring of short options and dropping clashes. Also, the command descriptions should be reviewed and improved. The CLI should be self-descriptive and there should be no need to open a web doc in most cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21320) Log HTTP headers on --verbose
Aleksandr created IGNITE-21320: -- Summary: Log HTTP headers on --verbose Key: IGNITE-21320 URL: https://issues.apache.org/jira/browse/IGNITE-21320 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr We have `--verbose` option for every command. This option is aimed to help in understanding what is going on. In most cases, it turns the logging of HTTP requests on. But this logging is not as verbose as it could be. Now we can see only HTTP verbs, paths, and response codes. I propose adding HTTP headers and HTTP body to these logs. This could help in debugging. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21319) Review REST API
Aleksandr created IGNITE-21319: -- Summary: Review REST API Key: IGNITE-21319 URL: https://issues.apache.org/jira/browse/IGNITE-21319 Project: Ignite Issue Type: Improvement Components: rest Reporter: Aleksandr I think it is time to review every endpoint we have and say if it can be simplified/improved. Key points to take a look at: - paths consistency (versioning, nouns, verbs, etc) - parameters - problems - error codes - Open API documentation Also, the UX with swagger UI should be checked. Swagger UI should be self-descriptive and allow a user to play around with the API easily. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21242) Update micronaut and remove workaround in RestComponent
Aleksandr created IGNITE-21242: -- Summary: Update micronaut and remove workaround in RestComponent Key: IGNITE-21242 URL: https://issues.apache.org/jira/browse/IGNITE-21242 Project: Ignite Issue Type: Improvement Components: rest Reporter: Aleksandr The fix for Micronaut is merged and will be available in an upcoming release. We have to adopt it and get rid of the workaround in RestComponent. https://github.com/micronaut-projects/micronaut-core/pull/10143 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21219) Write memory leak tests
[ https://issues.apache.org/jira/browse/IGNITE-21219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-21219: --- Description: Compute jobs handling logic is getting harder to track every reference we have. It seems like we can easily introduce a memory leak. I wonder if we have some microbenchmarks that prove the absence of memory leak in the compute component. Important note: the simulation of leaving and joining the cluster of several nodes (candidates, workers) should be done as well. was:Compute jobs handling logic is getting harder to track every reference we have. It seems like we can easily introduce a memory leak. I wonder if we have some microbenchmarks that prove the absence of memory leak in the compute component. > Write memory leak tests > --- > > Key: IGNITE-21219 > URL: https://issues.apache.org/jira/browse/IGNITE-21219 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Compute jobs handling logic is getting harder to track every reference we > have. It seems like we can easily introduce a memory leak. I wonder if we > have some microbenchmarks that prove the absence of memory leak in the > compute component. > Important note: the simulation of leaving and joining the cluster of several > nodes (candidates, workers) should be done as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21220) Worker node recovery
Aleksandr created IGNITE-21220: -- Summary: Worker node recovery Key: IGNITE-21220 URL: https://issues.apache.org/jira/browse/IGNITE-21220 Project: Ignite Issue Type: Improvement Reporter: Aleksandr There is a case when the worker node executing some job has left the logical topology. This node has to identify this situation and stop all running jobs. We must not have the situation when the worker left the topology, the coordinator restarted the job on another node, then the first worker joined the topology and two instances of the job are running on the cluster. Maybe we do not allow this but we have a lack of tests here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21219) Write memory leak tests
Aleksandr created IGNITE-21219: -- Summary: Write memory leak tests Key: IGNITE-21219 URL: https://issues.apache.org/jira/browse/IGNITE-21219 Project: Ignite Issue Type: Improvement Components: compute Reporter: Aleksandr Compute jobs handling logic is getting harder to track every reference we have. It seems like we can easily introduce a memory leak. I wonder if we have some microbenchmarks that prove the absence of memory leak in the compute component. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20850) Worker node shutdown failover
[ https://issues.apache.org/jira/browse/IGNITE-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-20850: -- Assignee: Aleksandr > Worker node shutdown failover > - > > Key: IGNITE-20850 > URL: https://issues.apache.org/jira/browse/IGNITE-20850 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In this case, the job execution stops and you need to restart it. In this > case, the coordinator will see that the worker node has turned off and all > the tasks that this coordinator sent for execution must be redistributed to > other nodes. In this context, it does not matter what state the tasks were > in, in the queue or in the process of execution, we do not offer a safepoint > mechanism, and all states of jobs can be written to the cache, so when a task > is launched on another worker node, it will be able to read from the cache > the state that the job I wrote it down last time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20850) Worker node shutdown failover
[ https://issues.apache.org/jira/browse/IGNITE-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-20850: -- Assignee: (was: Aleksandr) > Worker node shutdown failover > - > > Key: IGNITE-20850 > URL: https://issues.apache.org/jira/browse/IGNITE-20850 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In this case, the job execution stops and you need to restart it. In this > case, the coordinator will see that the worker node has turned off and all > the tasks that this coordinator sent for execution must be redistributed to > other nodes. In this context, it does not matter what state the tasks were > in, in the queue or in the process of execution, we do not offer a safepoint > mechanism, and all states of jobs can be written to the cache, so when a task > is launched on another worker node, it will be able to read from the cache > the state that the job I wrote it down last time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20864) IgniteComputeImpl should use primary replica for executeColocated
[ https://issues.apache.org/jira/browse/IGNITE-20864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-20864: -- Assignee: Aleksandr (was: Pavel Tupitsyn) > IgniteComputeImpl should use primary replica for executeColocated > - > > Key: IGNITE-20864 > URL: https://issues.apache.org/jira/browse/IGNITE-20864 > Project: Ignite > Issue Type: Bug > Components: compute >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See IGNITE-20701 for more details. We should use primary replica instead of > leader to execute colocated computations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21109) Move LogicalTopologyServiceImplTest to cluster-management-module
Aleksandr created IGNITE-21109: -- Summary: Move LogicalTopologyServiceImplTest to cluster-management-module Key: IGNITE-21109 URL: https://issues.apache.org/jira/browse/IGNITE-21109 Project: Ignite Issue Type: Improvement Components: compute Reporter: Aleksandr LogicalTopologyServiceImplTest was moved into the compute module because it is located in the compute package. We have to move it back and change the package name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20850) Worker node shutdown failover
[ https://issues.apache.org/jira/browse/IGNITE-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-20850: -- Assignee: Aleksandr > Worker node shutdown failover > - > > Key: IGNITE-20850 > URL: https://issues.apache.org/jira/browse/IGNITE-20850 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > In this case, the job execution stops and you need to restart it. In this > case, the coordinator will see that the worker node has turned off and all > the tasks that this coordinator sent for execution must be redistributed to > other nodes. In this context, it does not matter what state the tasks were > in, in the queue or in the process of execution, we do not offer a safepoint > mechanism, and all states of jobs can be written to the cache, so when a task > is launched on another worker node, it will be able to read from the cache > the state that the job I wrote it down last time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20829) Remove "basicAuthentication" prefix from JDBC url connection properties
[ https://issues.apache.org/jira/browse/IGNITE-20829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-20829: --- Description: It looks confusing for the user to put basicAuthenticationUsername and basicAuthenticationPassword properties into jdbc connection string. I propose rename them into user/password. (was: It looks confusing for the user to put basicAuthenticationUsername and basicAuthenticationPassword properties into jdbc connection string. I propose rename them into username/password.) > Remove "basicAuthentication" prefix from JDBC url connection properties > --- > > Key: IGNITE-20829 > URL: https://issues.apache.org/jira/browse/IGNITE-20829 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > It looks confusing for the user to put basicAuthenticationUsername and > basicAuthenticationPassword properties into jdbc connection string. I propose > rename them into user/password. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20829) Remove "basicAuthentication" prefix from JDBC url connection properties
Aleksandr created IGNITE-20829: -- Summary: Remove "basicAuthentication" prefix from JDBC url connection properties Key: IGNITE-20829 URL: https://issues.apache.org/jira/browse/IGNITE-20829 Project: Ignite Issue Type: Improvement Components: jdbc Reporter: Aleksandr It looks confusing for the user to put basicAuthenticationUsername and basicAuthenticationPassword properties into jdbc connection string. I propose rename them into username/password. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20819) Concurrent micronaut server startup fails sometimes
[ https://issues.apache.org/jira/browse/IGNITE-20819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-20819: -- Assignee: Aleksandr > Concurrent micronaut server startup fails sometimes > --- > > Key: IGNITE-20819 > URL: https://issues.apache.org/jira/browse/IGNITE-20819 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We see the flaky tests in CI with the root cause described here: > https://github.com/micronaut-projects/micronaut-core/issues/10091 > We have to use a workaround with a global lock for a while. After the issue > in the upstream is fixed, we can drop the workaround. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20819) Concurrent micronaut server startup fails sometimes
Aleksandr created IGNITE-20819: -- Summary: Concurrent micronaut server startup fails sometimes Key: IGNITE-20819 URL: https://issues.apache.org/jira/browse/IGNITE-20819 Project: Ignite Issue Type: Bug Reporter: Aleksandr We see the flaky tests in CI with the root cause described here: https://github.com/micronaut-projects/micronaut-core/issues/10091 We have to use a workaround with a global lock for a while. After the issue in the upstream is fixed, we can drop the workaround. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20806) Add --format option to the configuration commands
Aleksandr created IGNITE-20806: -- Summary: Add --format option to the configuration commands Key: IGNITE-20806 URL: https://issues.apache.org/jira/browse/IGNITE-20806 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr Now commands `cluster/node config show` display the configuration in JSON format. It might be handy in some cases but by default, it should be displayed in HOCON format (without "). I propose adding a new --format option to these commands and specifying two types of values for it: json and hocon (default). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20798) Verify every endpoint works in Swagger UI
Aleksandr created IGNITE-20798:
--
Summary: Verify every endpoint works in Swagger UI
Key: IGNITE-20798
URL: https://issues.apache.org/jira/browse/IGNITE-20798
Project: Ignite
Issue Type: Improvement
Components: rest
Reporter: Aleksandr
After IGNITE-20783 is done there is a docker-compose file that launches swagger
ui. The thing is that I've tested a couple of endpoints manually but now I can
see that some of them are not working in swagger ui. For example, try to fetch
the node configuration.
The problem is that there is a lack of content-type annotations in the api
definitions and "Content-Type" header must be enabled for CORS.
The goal of this issue is to check every endpoint available in Swagger UI and
fix all issues that happens there. And add "Content-Type" for CORS.
result.put("micronaut.server.cors.configurations.web.allowed-headers",
List.of("Authorization", "Content-Type"));
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20787) Extract interface from TableImpl
[
https://issues.apache.org/jira/browse/IGNITE-20787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-20787.
Resolution: Fixed
Thanks for the refactoring, merged into main:
f6c60f533d908ecf53c4df24238a26b31039f35d
> Extract interface from TableImpl
>
>
> Key: IGNITE-20787
> URL: https://issues.apache.org/jira/browse/IGNITE-20787
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There's a public API {{Table}} and {{IgniteTables}} and corresponding
> internal {{TableImpl}} {{IgniteTablesInternal}} but the {{TableImpl}} is not
> an interface which leaks to other modules and complicates further
> refactorings. We should extract an interface from it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20783) Add swagger ui docker compose file
[ https://issues.apache.org/jira/browse/IGNITE-20783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-20783: -- Assignee: Aleksandr > Add swagger ui docker compose file > -- > > Key: IGNITE-20783 > URL: https://issues.apache.org/jira/browse/IGNITE-20783 > Project: Ignite > Issue Type: Improvement > Components: rest >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > To improve the experience during the REST API testing I propose introducing > docker compose with swagger ui. Take into account that we have to support > basic auth there and enable CORS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20783) Add swagger ui docker compose file
Aleksandr created IGNITE-20783: -- Summary: Add swagger ui docker compose file Key: IGNITE-20783 URL: https://issues.apache.org/jira/browse/IGNITE-20783 Project: Ignite Issue Type: Improvement Components: rest Reporter: Aleksandr To improve the experience during the REST API testing I propose introducing docker compose with swagger ui. Take into account that we have to support basic auth there and enable CORS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20751) Update micronaut and open API generator versions
[ https://issues.apache.org/jira/browse/IGNITE-20751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-20751: -- Assignee: Aleksandr > Update micronaut and open API generator versions > > > Key: IGNITE-20751 > URL: https://issues.apache.org/jira/browse/IGNITE-20751 > Project: Ignite > Issue Type: Improvement > Components: rest >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > There is a new major micrionaut version 4 and micronaut-openapi also has a > major version 5. The issue is that micronaut 4 is targeted for java 17. We do > not compile to java 17 yet. So, we have to update micronaut up to the latest > 3.x version and micronaut-openapi up to 4.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20751) Update micronaut and open API generator versions
Aleksandr created IGNITE-20751: -- Summary: Update micronaut and open API generator versions Key: IGNITE-20751 URL: https://issues.apache.org/jira/browse/IGNITE-20751 Project: Ignite Issue Type: Improvement Components: rest Reporter: Aleksandr There is a new major micrionaut version 4 and micronaut-openapi also has a major version 5. The issue is that micronaut 4 is targeted for java 17. We do not compile to java 17 yet. So, we have to update micronaut up to the latest 3.x version and micronaut-openapi up to 4.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20648) Can not init cluster with 21 java
Aleksandr created IGNITE-20648:
--
Summary: Can not init cluster with 21 java
Key: IGNITE-20648
URL: https://issues.apache.org/jira/browse/IGNITE-20648
Project: Ignite
Issue Type: Bug
Components: networking
Reporter: Aleksandr
To reproduce the issue:
1) build packages with 11 java
2) start node with 21 java
3) init cluster
The error:
{{023-10-13 14:41:48:887 +0400
[WARNING][%defaultNode%JRaft-Request-Processor-7][JRaftUtils] Uncaught
exception [thread=Thread[#195,%defaultNode%JRaft-R
equest-Processor-7,5,main]]
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.ignite.internal.util.GridUnsafe
at
org.apache.ignite.internal.network.direct.stream.DirectByteBufferStreamImplV1.setBuffer(DirectByteBufferStreamImplV1.java:201)
at
org.apache.ignite.internal.raft.util.OptimizedMarshaller.marshall(OptimizedMarshaller.java:94)
at
org.apache.ignite.internal.raft.util.ThreadLocalOptimizedMarshaller.marshall(ThreadLocalOptimizedMarshaller.java:42)
at
org.apache.ignite.raft.jraft.rpc.impl.ActionRequestProcessor.applyWrite(ActionRequestProcessor.java:122)
at
org.apache.ignite.raft.jraft.rpc.impl.ActionRequestProcessor.handleRequest(ActionRequestProcessor.java:92)
at
org.apache.ignite.raft.jraft.rpc.impl.InterceptingActionRequestProcessor.handleRequest(InterceptingActionRequestProcessor.java:48)
at
org.apache.ignite.raft.jraft.rpc.impl.InterceptingActionRequestProcessor.handleRequest(InterceptingActionRequestProcessor.java:31)
at
org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:194)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.ExceptionInInitializerError: Exception
java.lang.RuntimeException: Unable to set up byte buffer creation using
reflections :java.n
io.DirectByteBuffer.(long,int) [in thread
"%defaultNode%JRaft-Request-Processor-1"]
at
org.apache.ignite.internal.util.GridUnsafe.createNewDirectBufferCtor(GridUnsafe.java:1750)
at
org.apache.ignite.internal.util.GridUnsafe.createAndTestNewDirectBufferCtor(GridUnsafe.java:1704)
at
org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:164)
... 11 more}}
It looks like the same issue from AI2 IGNITE-19652
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20648) Can not init cluster with 21 java
[
https://issues.apache.org/jira/browse/IGNITE-20648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-20648:
---
Description:
To reproduce the issue:
1) build packages with 11 java
2) start node with 21 java
3) init cluster
The error:
{code:java}
023-10-13 14:41:48:887 +0400
[WARNING][%defaultNode%JRaft-Request-Processor-7][JRaftUtils] Uncaught
exception [thread=Thread[#195,%defaultNode%JRaft-R
equest-Processor-7,5,main]]
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.ignite.internal.util.GridUnsafe
at
org.apache.ignite.internal.network.direct.stream.DirectByteBufferStreamImplV1.setBuffer(DirectByteBufferStreamImplV1.java:201)
at
org.apache.ignite.internal.raft.util.OptimizedMarshaller.marshall(OptimizedMarshaller.java:94)
at
org.apache.ignite.internal.raft.util.ThreadLocalOptimizedMarshaller.marshall(ThreadLocalOptimizedMarshaller.java:42)
at
org.apache.ignite.raft.jraft.rpc.impl.ActionRequestProcessor.applyWrite(ActionRequestProcessor.java:122)
at
org.apache.ignite.raft.jraft.rpc.impl.ActionRequestProcessor.handleRequest(ActionRequestProcessor.java:92)
at
org.apache.ignite.raft.jraft.rpc.impl.InterceptingActionRequestProcessor.handleRequest(InterceptingActionRequestProcessor.java:48)
at
org.apache.ignite.raft.jraft.rpc.impl.InterceptingActionRequestProcessor.handleRequest(InterceptingActionRequestProcessor.java:31)
at
org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:194)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.ExceptionInInitializerError: Exception
java.lang.RuntimeException: Unable to set up byte buffer creation using
reflections :java.n
io.DirectByteBuffer.(long,int) [in thread
"%defaultNode%JRaft-Request-Processor-1"]
at
org.apache.ignite.internal.util.GridUnsafe.createNewDirectBufferCtor(GridUnsafe.java:1750)
at
org.apache.ignite.internal.util.GridUnsafe.createAndTestNewDirectBufferCtor(GridUnsafe.java:1704)
at
org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:164)
... 11 more
{code}
It looks like the same issue from AI2 IGNITE-19652
was:
To reproduce the issue:
1) build packages with 11 java
2) start node with 21 java
3) init cluster
The error:
{{023-10-13 14:41:48:887 +0400
[WARNING][%defaultNode%JRaft-Request-Processor-7][JRaftUtils] Uncaught
exception [thread=Thread[#195,%defaultNode%JRaft-R
equest-Processor-7,5,main]]
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.ignite.internal.util.GridUnsafe
at
org.apache.ignite.internal.network.direct.stream.DirectByteBufferStreamImplV1.setBuffer(DirectByteBufferStreamImplV1.java:201)
at
org.apache.ignite.internal.raft.util.OptimizedMarshaller.marshall(OptimizedMarshaller.java:94)
at
org.apache.ignite.internal.raft.util.ThreadLocalOptimizedMarshaller.marshall(ThreadLocalOptimizedMarshaller.java:42)
at
org.apache.ignite.raft.jraft.rpc.impl.ActionRequestProcessor.applyWrite(ActionRequestProcessor.java:122)
at
org.apache.ignite.raft.jraft.rpc.impl.ActionRequestProcessor.handleRequest(ActionRequestProcessor.java:92)
at
org.apache.ignite.raft.jraft.rpc.impl.InterceptingActionRequestProcessor.handleRequest(InterceptingActionRequestProcessor.java:48)
at
org.apache.ignite.raft.jraft.rpc.impl.InterceptingActionRequestProcessor.handleRequest(InterceptingActionRequestProcessor.java:31)
at
org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:194)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.ExceptionInInitializerError: Exception
java.lang.RuntimeException: Unable to set up byte buffer creation using
reflections :java.n
io.DirectByteBuffer.(long,int) [in thread
"%defaultNode%JRaft-Request-Processor-1"]
at
org.apache.ignite.internal.util.GridUnsafe.createNewDirectBufferCtor(GridUnsafe.java:1750)
at
org.apache.ignite.internal.util.GridUnsafe.createAndTestNewDirectBufferCtor(GridUnsafe.java:1704)
at
org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:164)
... 11 more}}
It looks like the same issue from AI2 IGNITE-19652
> Can not init cluster with 21 java
> -
>
> Key: IGNITE-20648
> URL:
[jira] [Commented] (IGNITE-20512) REST API: Remove port range
[ https://issues.apache.org/jira/browse/IGNITE-20512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774583#comment-17774583 ] Aleksandr commented on IGNITE-20512: Hi, [~ptupitsyn]. Can you review the PR, please? > REST API: Remove port range > --- > > Key: IGNITE-20512 > URL: https://issues.apache.org/jira/browse/IGNITE-20512 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > See IGNITE-19601. We agreed to remove port range from client connector, the > same should be done for REST connector: > * Usually we know the exact port both on client and on server > * Other products don't have port ranges, this is unusual for the users to see > * It brings additional complexity and issues (see IGNITE-19571) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20639) Remove portRange from network configuration
Aleksandr created IGNITE-20639:
--
Summary: Remove portRange from network configuration
Key: IGNITE-20639
URL: https://issues.apache.org/jira/browse/IGNITE-20639
Project: Ignite
Issue Type: Task
Components: networking
Reporter: Aleksandr
The goal of IGNITE-20512 was to remove {{rest.portRange}} from REST server
configuration and force the user to set up the port directly in {{rest.port}}
configuration. That makes the configuration robust and easier to understand.
I've noticed that we also have {{network.portRange}} configuration that looks
weird now. It gets even stranger when we configure the node discovery part:
{{network.nodeFilter.netClusterNodes: [localhost:3344, localhost:3345]}} . We
have to specify peers with the direct address but configure the current address
with a range.
I propose to get rid of {{portRange}} in {{network}} section as well as we did
it in {{rest}} and {{clientConnector}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20591) Connect to another cluster does not work from interactive mode
[ https://issues.apache.org/jira/browse/IGNITE-20591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-20591: --- Description: I had two nodes (10300 and 10400), initialized one node, and wanted to initialize the second one. It seems like connecting to another node does not work if you are already connected to some. > Connect to another cluster does not work from interactive mode > -- > > Key: IGNITE-20591 > URL: https://issues.apache.org/jira/browse/IGNITE-20591 > Project: Ignite > Issue Type: Bug > Components: cli >Affects Versions: 3.0.0-beta2 >Reporter: Aleksandr >Priority: Major > Attachments: Screenshot 2023-10-06 at 19.19.19.png > > > I had two nodes (10300 and 10400), initialized one node, and wanted to > initialize the second one. It seems like connecting to another node does not > work if you are already connected to some. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20591) Connect to another cluster does not work from interactive mode
Aleksandr created IGNITE-20591: -- Summary: Connect to another cluster does not work from interactive mode Key: IGNITE-20591 URL: https://issues.apache.org/jira/browse/IGNITE-20591 Project: Ignite Issue Type: Bug Components: cli Affects Versions: 3.0.0-beta2 Reporter: Aleksandr Attachments: Screenshot 2023-10-06 at 19.19.19.png -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20351) Log responce error in Rest test
Aleksandr created IGNITE-20351: -- Summary: Log responce error in Rest test Key: IGNITE-20351 URL: https://issues.apache.org/jira/browse/IGNITE-20351 Project: Ignite Issue Type: Task Components: rest Reporter: Aleksandr Assignee: Aleksandr Now ItAuthenticationTest.isRestAvailable does not log responses in case they get errors on response code assert. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20254) Refactor CLI exception handling
Aleksandr created IGNITE-20254:
--
Summary: Refactor CLI exception handling
Key: IGNITE-20254
URL: https://issues.apache.org/jira/browse/IGNITE-20254
Project: Ignite
Issue Type: Task
Components: cli
Reporter: Aleksandr
Now the CLI handles exceptions by finding a proper handler by the exception
type. But REST client throws the same exception all the time and CLI exception
handler becomes messy.
I would like to refactor the CLI exception handling mechanism in a way that we
can associate a handler with Ignite error code.
Now ExceptionHandler interface has
public Class applicableException() {
return Throwable.class;
}
But it would be useful to have one more method
public Class applicableErrorCode() {
return "IGN-...-2"; // for example
}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20082) Fix ODBC package
[
https://issues.apache.org/jira/browse/IGNITE-20082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755450#comment-17755450
]
Aleksandr commented on IGNITE-20082:
Thank you for the contribution, merged into main:
2c22342bb131a610af4c622c99127bf52aa102ea
> Fix ODBC package
> -
>
> Key: IGNITE-20082
> URL: https://issues.apache.org/jira/browse/IGNITE-20082
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 1. Missing {{/usr/lib/libignite3-odbc.so.3}} inside DEB\RPM packages
> 2. Incorrect {{unixodbc}} package name in DEB package requirement
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20179) CLI should provide user-friendly list options
[
https://issues.apache.org/jira/browse/IGNITE-20179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-20179:
---
Description:
We have several command options that should accept a list of strings, for
example {{cluster init --cmg-nodes}}. cmg-nodes can accept a single sting,
string with comma-separated node names without a space, and finally, can be
repeated.
Imagine you are a user that types a command
{{[defaultNode]> cluster init --cluster-name my --meta-storage-node defaultNode
--cmg-node defaultNode, defaultNode2}}
And get the error:
Unmatched argument at index 7: 'defaultNode2'
That is not clear what is wrong but the reason is that you typed a space before
the comma.
I suggest rethinking the way CLI supports lists of strings and offering a more
user-friendly solution. Probably, we have to redefine our own jline3 parser. I
would expect and least a clear error message about what is wrong and how to fix
it.
Another challenge here is to improve autocompletion in interactive mode.
Imagine I want to use completion against a cluster of two nodes node1 and
node2:
{{[defaultNode]> cluster init --cluster-name my --meta-storage-node node1
--meta-storage-node node2}}
On TAB1 I can see the completion of 2 variants: node1 and node2. That is
correct. On TAB2 I expect to see only node2 completion but I still see node1
and node2. That is not correct, because the list of nodes is not expected to
contain duplicates.
As a result of this ticket, I expect:
- correct errors with examples
- correct completions
- a common solution to be used in all commands that need lists of string
was:
We have several command options that should accept a list of strings, for
example {{cluster init --cmg-nodes}}. cmg-nodes can accept a single sting,
string with comma-separated node names without a space, and finally, can be
repeated.
Imagine you are a user that types a command
{{[defaultNode]> cluster init --cluster-name my --meta-storage-node defaultNode
--cmg-node defaultNode, defaultNode2}}
And get the error:
Unmatched argument at index 7: 'defaultNode2'
That is not clear what is wrong but the reason is that you typed a space before
the comma.
I suggest rethinking the way CLI supports lists of strings and offering a more
user-friendly solution. Probably, we have to redefine our own jline3 parser. I
would expect and least a clear error message about what is wrong and how to fix
it.
Another challenge here is to improve autocompletion in interactive mode.
Imagine I want to use completion against a cluster of two nodes node1 and
node2:
{{[defaultNode]> cluster init --cluster-name my --meta-storage-node node1
--meta-storage-node node2}}
On TAB1 I can see the completion of 2 variants: node1 and node2. That is
correct. On TAB2 I expect to see only node2 completion but I still see node1
and node2. That is not correct, because the list of nodes is not expected to
contain duplicates.
> CLI should provide user-friendly list options
> -
>
> Key: IGNITE-20179
> URL: https://issues.apache.org/jira/browse/IGNITE-20179
> Project: Ignite
> Issue Type: Task
> Components: cli
>Affects Versions: 3.0.0-beta1
>Reporter: Aleksandr
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
>
> We have several command options that should accept a list of strings, for
> example {{cluster init --cmg-nodes}}. cmg-nodes can accept a single sting,
> string with comma-separated node names without a space, and finally, can be
> repeated.
> Imagine you are a user that types a command
> {{[defaultNode]> cluster init --cluster-name my --meta-storage-node
> defaultNode --cmg-node defaultNode, defaultNode2}}
> And get the error:
> Unmatched argument at index 7: 'defaultNode2'
> That is not clear what is wrong but the reason is that you typed a space
> before the comma.
> I suggest rethinking the way CLI supports lists of strings and offering a
> more user-friendly solution. Probably, we have to redefine our own jline3
> parser. I would expect and least a clear error message about what is wrong
> and how to fix it.
> Another challenge here is to improve autocompletion in interactive mode.
> Imagine I want to use completion against a cluster of two nodes node1
> and node2:
> {{[defaultNode]> cluster init --cluster-name my --meta-storage-node
> node1 --meta-storage-node node2}}
> On TAB1 I can see the completion of 2 variants: node1 and node2. That is
> correct. On TAB2 I expect to see only node2 completion but I still see node1
> and node2. That is not correct, because the list of nodes is not expected to
> contain duplicates.
> As a result of this ticket, I expect:
> - correct errors with examples
> - correct completions
> - a common solution to be used in all
[jira] [Updated] (IGNITE-20179) CLI should provide user-friendly list options
[
https://issues.apache.org/jira/browse/IGNITE-20179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-20179:
---
Description:
We have several command options that should accept a list of strings, for
example {{cluster init --cmg-nodes}}. cmg-nodes can accept a single sting,
string with comma-separated node names without a space, and finally, can be
repeated.
Imagine you are a user that types a command
{{[defaultNode]> cluster init --cluster-name my --meta-storage-node defaultNode
--cmg-node defaultNode, defaultNode2}}
And get the error:
Unmatched argument at index 7: 'defaultNode2'
That is not clear what is wrong but the reason is that you typed a space before
the comma.
I suggest rethinking the way CLI supports lists of strings and offering a more
user-friendly solution. Probably, we have to redefine our own jline3 parser. I
would expect and least a clear error message about what is wrong and how to fix
it.
Another challenge here is to improve autocompletion in interactive mode.
Imagine I want to use completion against a cluster of two nodes node1 and
node2:
{{[defaultNode]> cluster init --cluster-name my --meta-storage-node node1
--meta-storage-node node2}}
On TAB1 I can see the completion of 2 variants: node1 and node2. That is
correct. On TAB2 I expect to see only node2 completion but I still see node1
and node2. That is not correct, because the list of nodes is not expected to
contain duplicates.
was:
We have several command options that should accept a list of strings, for
example {{cluster init --cmg-nodes}}. cmg-nodes can accept a single sting,
string with comma-separated node names without a space, and finally, can be
repeated.
Imagine you are a user that types a command
{{[defaultNode]> cluster init --cluster-name my --meta-storage-node defaultNode
--cmg-node defaultNode, defaultNode2}}
And get the error:
Unmatched argument at index 7: 'defaultNode2'
That is not clear what is wrong but the reason is that you typed a space before
comma.
I suggest rethinking the way CLI supports lists of strings and offering a more
user-friendly solution. Probably, we have to redefine our own jline3 parser. I
would expect and least a clear error message about what is wrong and how to fix
it.
Another challenge here is to improve autocompletion in interactive mode.
Imagine I want to use completion against a cluster of two nodes node1 and
node2:
{{[defaultNode]> cluster init --cluster-name my --meta-storage-node node1
--meta-storage-no}}
> CLI should provide user-friendly list options
> -
>
> Key: IGNITE-20179
> URL: https://issues.apache.org/jira/browse/IGNITE-20179
> Project: Ignite
> Issue Type: Task
> Components: cli
>Affects Versions: 3.0.0-beta1
>Reporter: Aleksandr
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
>
> We have several command options that should accept a list of strings, for
> example {{cluster init --cmg-nodes}}. cmg-nodes can accept a single sting,
> string with comma-separated node names without a space, and finally, can be
> repeated.
> Imagine you are a user that types a command
> {{[defaultNode]> cluster init --cluster-name my --meta-storage-node
> defaultNode --cmg-node defaultNode, defaultNode2}}
> And get the error:
> Unmatched argument at index 7: 'defaultNode2'
> That is not clear what is wrong but the reason is that you typed a space
> before the comma.
> I suggest rethinking the way CLI supports lists of strings and offering a
> more user-friendly solution. Probably, we have to redefine our own jline3
> parser. I would expect and least a clear error message about what is wrong
> and how to fix it.
> Another challenge here is to improve autocompletion in interactive mode.
> Imagine I want to use completion against a cluster of two nodes node1
> and node2:
> {{[defaultNode]> cluster init --cluster-name my --meta-storage-node
> node1 --meta-storage-node node2}}
> On TAB1 I can see the completion of 2 variants: node1 and node2. That is
> correct. On TAB2 I expect to see only node2 completion but I still see node1
> and node2. That is not correct, because the list of nodes is not expected to
> contain duplicates.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20179) CLI should provide user-friendly list options
[
https://issues.apache.org/jira/browse/IGNITE-20179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-20179:
---
Description:
We have several command options that should accept a list of strings, for
example {{cluster init --cmg-nodes}}. cmg-nodes can accept a single sting,
string with comma-separated node names without a space, and finally, can be
repeated.
Imagine you are a user that types a command
{{[defaultNode]> cluster init --cluster-name my --meta-storage-node defaultNode
--cmg-node defaultNode, defaultNode2}}
And get the error:
Unmatched argument at index 7: 'defaultNode2'
That is not clear what is wrong but the reason is that you typed a space before
comma.
I suggest rethinking the way CLI supports lists of strings and offering a more
user-friendly solution. Probably, we have to redefine our own jline3 parser. I
would expect and least a clear error message about what is wrong and how to fix
it.
Another challenge here is to improve autocompletion in interactive mode.
Imagine I want to use completion against a cluster of two nodes node1 and
node2:
{{[defaultNode]> cluster init --cluster-name my --meta-storage-node node1
--meta-storage-no}}
> CLI should provide user-friendly list options
> -
>
> Key: IGNITE-20179
> URL: https://issues.apache.org/jira/browse/IGNITE-20179
> Project: Ignite
> Issue Type: Task
> Components: cli
>Affects Versions: 3.0.0-beta1
>Reporter: Aleksandr
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
>
> We have several command options that should accept a list of strings, for
> example {{cluster init --cmg-nodes}}. cmg-nodes can accept a single sting,
> string with comma-separated node names without a space, and finally, can be
> repeated.
> Imagine you are a user that types a command
> {{[defaultNode]> cluster init --cluster-name my --meta-storage-node
> defaultNode --cmg-node defaultNode, defaultNode2}}
> And get the error:
> Unmatched argument at index 7: 'defaultNode2'
> That is not clear what is wrong but the reason is that you typed a space
> before comma.
> I suggest rethinking the way CLI supports lists of strings and offering a
> more user-friendly solution. Probably, we have to redefine our own jline3
> parser. I would expect and least a clear error message about what is wrong
> and how to fix it.
> Another challenge here is to improve autocompletion in interactive mode.
> Imagine I want to use completion against a cluster of two nodes node1
> and node2:
> {{[defaultNode]> cluster init --cluster-name my --meta-storage-node
> node1 --meta-storage-no}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20179) CLI should provide user-friendly list options
Aleksandr created IGNITE-20179: -- Summary: CLI should provide user-friendly list options Key: IGNITE-20179 URL: https://issues.apache.org/jira/browse/IGNITE-20179 Project: Ignite Issue Type: Task Components: cli Affects Versions: 3.0.0-beta1 Reporter: Aleksandr -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19953) Ignite 3 CLI: --verbose twice does not work
[ https://issues.apache.org/jira/browse/IGNITE-19953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-19953: -- Assignee: Aleksandr > Ignite 3 CLI: --verbose twice does not work > --- > > Key: IGNITE-19953 > URL: https://issues.apache.org/jira/browse/IGNITE-19953 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > Attachments: Screenshot 2023-07-11 at 16.10.43.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Just call any command with --verbose twice in REPL mode. The first one prints > HTTP trace, the second one no. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20158) CLI: cluster/node config update is not user friendly
[
https://issues.apache.org/jira/browse/IGNITE-20158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-20158:
---
Description:
The configuration update process can be painful because of the way CLI parses
the command line. For example,
{code:java}
[defaultNode]> cluster config update -u http://localhost:10300
"{aipersist.regions: [{name: persistent_region,size: 2560
0}],aimem.regions: [{name: btree_volatile_region,maxSize: 25600}]}"
IGN-CMN-65535 Trace ID: 5430a4a7-b24d-4861-89aa-fdb84a17b199
com.typesafe.config.ConfigException$Parse: String: 1: Key '"{aipersist.regions:
[{name: persistent_region,size: 25600}],aimem.regions: [{name:
btree_volatile_region,maxSize: 25600}]}"' may not be followed by token: end
of file
{code}
There is no way to understand what is going wrong.
I suggest improving the error text and showing the correct command example.
And we have to investigate the root cause of the issue and create a follow-up
ticket to fix the way CLI parses the command line. I expect the example command
to be valid.
We have to provide user-friendly response in any case.
was:
The configuration update process can be painful because of the way CLI parses
the command line. For example,
{code:java}
[defaultNode]> cluster config update -u http://localhost:10300
"{aipersist.regions: [{name: persistent_region,size: 2560
0}],aimem.regions: [{name: btree_volatile_region,maxSize: 25600}]}"
IGN-CMN-65535 Trace ID: 5430a4a7-b24d-4861-89aa-fdb84a17b199
com.typesafe.config.ConfigException$Parse: String: 1: Key '"{aipersist.regions:
[{name: persistent_region,size: 25600}],aimem.regions: [{name:
btree_volatile_region,maxSize: 25600}]}"' may not be followed by token: end
of file
{code}
There is no way to understand what is going wrong.
I suggest improving the error text and showing the correct command example.
And we have to investigate the root cause of the issue and create a follow-up
ticket to fix the way CLI parses the command line. I expect the example command
to be valid.
> CLI: cluster/node config update is not user friendly
>
>
> Key: IGNITE-20158
> URL: https://issues.apache.org/jira/browse/IGNITE-20158
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> The configuration update process can be painful because of the way CLI parses
> the command line. For example,
> {code:java}
> [defaultNode]> cluster config update -u http://localhost:10300
> "{aipersist.regions: [{name: persistent_region,size: 2560
> 0}],aimem.regions: [{name: btree_volatile_region,maxSize: 25600}]}"
> IGN-CMN-65535 Trace ID: 5430a4a7-b24d-4861-89aa-fdb84a17b199
> com.typesafe.config.ConfigException$Parse: String: 1: Key
> '"{aipersist.regions: [{name: persistent_region,size:
> 25600}],aimem.regions: [{name: btree_volatile_region,maxSize:
> 25600}]}"' may not be followed by token: end of file
> {code}
> There is no way to understand what is going wrong.
> I suggest improving the error text and showing the correct command example.
> And we have to investigate the root cause of the issue and create a follow-up
> ticket to fix the way CLI parses the command line. I expect the example
> command to be valid.
> We have to provide user-friendly response in any case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20158) CLI: cluster/node config update is not user friendly
Aleksandr created IGNITE-20158:
--
Summary: CLI: cluster/node config update is not user friendly
Key: IGNITE-20158
URL: https://issues.apache.org/jira/browse/IGNITE-20158
Project: Ignite
Issue Type: Task
Reporter: Aleksandr
The configuration update process can be painful because of the way CLI parses
the command line. For example,
{code:java}
[defaultNode]> cluster config update -u http://localhost:10300
"{aipersist.regions: [{name: persistent_region,size: 2560
0}],aimem.regions: [{name: btree_volatile_region,maxSize: 25600}]}"
IGN-CMN-65535 Trace ID: 5430a4a7-b24d-4861-89aa-fdb84a17b199
com.typesafe.config.ConfigException$Parse: String: 1: Key '"{aipersist.regions:
[{name: persistent_region,size: 25600}],aimem.regions: [{name:
btree_volatile_region,maxSize: 25600}]}"' may not be followed by token: end
of file
{code}
There is no way to understand what is going wrong.
I suggest improving the error text and showing the correct command example.
And we have to investigate the root cause of the issue and create a follow-up
ticket to fix the way CLI parses the command line. I expect the example command
to be valid.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20150) JDBC port not exposed in docker-compose.yml in Ignite 3
[
https://issues.apache.org/jira/browse/IGNITE-20150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-20150:
--
Assignee: Aleksandr (was: Ivan Zlenko)
> JDBC port not exposed in docker-compose.yml in Ignite 3
> ---
>
> Key: IGNITE-20150
> URL: https://issues.apache.org/jira/browse/IGNITE-20150
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0-beta2
>Reporter: Ivan Zlenko
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Ignite has an option to run cluster inside Docker container. To run several
> nodes we can use docker compose file. In repo exists pre-defined
> docker-compose.yml and example could be found in documentation. However both
> file from repo and docs contains one simple error: JDBC port is not exposed.
> So as soon as someone will try to enter SQL mode inside CLI following error
> will be received:
> {code}
> [node1]> sql
> 196609 Trace ID: 2c6f842d-2d08-4b51-b1cf-307e664dc9ff
> Connection failed
> Client failed to connect: Connection refused: localhost/127.0.0.1:10800
> {code}
> Adding 10800 into docker-compose file fixes that problem.
> On the side note: I'm not sure if it is necessary to expose ScaleCube ports
> externally. As far as I understand they exists only for internal
> communication between nodes and no one should connect to those ports
> externally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20150) JDBC port not exposed in docker-compose.yml in Ignite 3
[
https://issues.apache.org/jira/browse/IGNITE-20150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-20150:
--
Assignee: (was: Aleksandr)
> JDBC port not exposed in docker-compose.yml in Ignite 3
> ---
>
> Key: IGNITE-20150
> URL: https://issues.apache.org/jira/browse/IGNITE-20150
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0-beta2
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Ignite has an option to run cluster inside Docker container. To run several
> nodes we can use docker compose file. In repo exists pre-defined
> docker-compose.yml and example could be found in documentation. However both
> file from repo and docs contains one simple error: JDBC port is not exposed.
> So as soon as someone will try to enter SQL mode inside CLI following error
> will be received:
> {code}
> [node1]> sql
> 196609 Trace ID: 2c6f842d-2d08-4b51-b1cf-307e664dc9ff
> Connection failed
> Client failed to connect: Connection refused: localhost/127.0.0.1:10800
> {code}
> Adding 10800 into docker-compose file fixes that problem.
> On the side note: I'm not sure if it is necessary to expose ScaleCube ports
> externally. As far as I understand they exists only for internal
> communication between nodes and no one should connect to those ports
> externally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20150) JDBC port not exposed in docker-compose.yml in Ignite 3
[
https://issues.apache.org/jira/browse/IGNITE-20150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750796#comment-17750796
]
Aleksandr commented on IGNITE-20150:
[~ivan.zlenko] could you create follow-up ticket for the documentation?
> JDBC port not exposed in docker-compose.yml in Ignite 3
> ---
>
> Key: IGNITE-20150
> URL: https://issues.apache.org/jira/browse/IGNITE-20150
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0-beta2
>Reporter: Ivan Zlenko
>Assignee: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Ignite has an option to run cluster inside Docker container. To run several
> nodes we can use docker compose file. In repo exists pre-defined
> docker-compose.yml and example could be found in documentation. However both
> file from repo and docs contains one simple error: JDBC port is not exposed.
> So as soon as someone will try to enter SQL mode inside CLI following error
> will be received:
> {code}
> [node1]> sql
> 196609 Trace ID: 2c6f842d-2d08-4b51-b1cf-307e664dc9ff
> Connection failed
> Client failed to connect: Connection refused: localhost/127.0.0.1:10800
> {code}
> Adding 10800 into docker-compose file fixes that problem.
> On the side note: I'm not sure if it is necessary to expose ScaleCube ports
> externally. As far as I understand they exists only for internal
> communication between nodes and no one should connect to those ports
> externally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20150) JDBC port not exposed in docker-compose.yml in Ignite 3
[
https://issues.apache.org/jira/browse/IGNITE-20150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-20150:
--
Assignee: Ivan Zlenko
> JDBC port not exposed in docker-compose.yml in Ignite 3
> ---
>
> Key: IGNITE-20150
> URL: https://issues.apache.org/jira/browse/IGNITE-20150
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0-beta2
>Reporter: Ivan Zlenko
>Assignee: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Ignite has an option to run cluster inside Docker container. To run several
> nodes we can use docker compose file. In repo exists pre-defined
> docker-compose.yml and example could be found in documentation. However both
> file from repo and docs contains one simple error: JDBC port is not exposed.
> So as soon as someone will try to enter SQL mode inside CLI following error
> will be received:
> {code}
> [node1]> sql
> 196609 Trace ID: 2c6f842d-2d08-4b51-b1cf-307e664dc9ff
> Connection failed
> Client failed to connect: Connection refused: localhost/127.0.0.1:10800
> {code}
> Adding 10800 into docker-compose file fixes that problem.
> On the side note: I'm not sure if it is necessary to expose ScaleCube ports
> externally. As far as I understand they exists only for internal
> communication between nodes and no one should connect to those ports
> externally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20151) Minor fixes in Ignite 3 public documentation
Aleksandr created IGNITE-20151: -- Summary: Minor fixes in Ignite 3 public documentation Key: IGNITE-20151 URL: https://issues.apache.org/jira/browse/IGNITE-20151 Project: Ignite Issue Type: Task Components: documentation Reporter: Aleksandr # Search "Alpha" word, it is confused with Betha # Installing using docker: "Running In Memory Cluster?" - confusing. What does "In Memory means"? I would suggest get rid of this word. # Rename "REPL mode" to "Interactive mode" # In the CLI part: "Command options" is confused with "Interactive". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20150) JDBC port not exposed in docker-compose.yml in Ignite 3
[
https://issues.apache.org/jira/browse/IGNITE-20150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750695#comment-17750695
]
Aleksandr commented on IGNITE-20150:
As a result, the documentation ticket should be created as well.
> JDBC port not exposed in docker-compose.yml in Ignite 3
> ---
>
> Key: IGNITE-20150
> URL: https://issues.apache.org/jira/browse/IGNITE-20150
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0-beta2
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> Ignite has an option to run cluster inside Docker container. To run several
> nodes we can use docker compose file. In repo exists pre-defined
> docker-compose.yml and example could be found in documentation. However both
> file from repo and docs contains one simple error: JDBC port is not exposed.
> So as soon as someone will try to enter SQL mode inside CLI following error
> will be received:
> {code}
> [node1]> sql
> 196609 Trace ID: 2c6f842d-2d08-4b51-b1cf-307e664dc9ff
> Connection failed
> Client failed to connect: Connection refused: localhost/127.0.0.1:10800
> {code}
> Adding 10800 into docker-compose file fixes that problem.
> On the side note: I'm not sure if it is necessary to expose ScaleCube ports
> externally. As far as I understand they exists only for internal
> communication between nodes and no one should connect to those ports
> externally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20150) JDBC port not exposed in docker-compose.yml in Ignite 3
[
https://issues.apache.org/jira/browse/IGNITE-20150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-20150:
---
Labels: ignite-3 (was: )
> JDBC port not exposed in docker-compose.yml in Ignite 3
> ---
>
> Key: IGNITE-20150
> URL: https://issues.apache.org/jira/browse/IGNITE-20150
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0-beta2
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> Ignite has an option to run cluster inside Docker container. To run several
> nodes we can use docker compose file. In repo exists pre-defined
> docker-compose.yml and example could be found in documentation. However both
> file from repo and docs contains one simple error: JDBC port is not exposed.
> So as soon as someone will try to enter SQL mode inside CLI following error
> will be received:
> {code}
> [node1]> sql
> 196609 Trace ID: 2c6f842d-2d08-4b51-b1cf-307e664dc9ff
> Connection failed
> Client failed to connect: Connection refused: localhost/127.0.0.1:10800
> {code}
> Adding 10800 into docker-compose file fixes that problem.
> On the side note: I'm not sure if it is necessary to expose ScaleCube ports
> externally. As far as I understand they exists only for internal
> communication between nodes and no one should connect to those ports
> externally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-19985) Allow single empty line at the end of the SQL test script
[
https://issues.apache.org/jira/browse/IGNITE-19985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-19985.
Fix Version/s: 3.0.0-beta2
Resolution: Fixed
Thanks, merged into main: 45ab580e4ecd6d6e78599b06cd44c29eeb4c565d
> Allow single empty line at the end of the SQL test script
> -
>
> Key: IGNITE-19985
> URL: https://issues.apache.org/jira/browse/IGNITE-19985
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If SQL test script in the {{runner/src/integrationTest/sql}} ends with
> {{}} followed by the single line break, script runner throws NPE.
> Let's allow single line break meaning empty result set of the last query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19974) Ignite nodes are not stopped if cluster initialization fails
[ https://issues.apache.org/jira/browse/IGNITE-19974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-19974: --- Summary: Ignite nodes are not stopped if cluster initialization fails (was: IT. Ignite nodes are not stopped if cluster initialization fails) > Ignite nodes are not stopped if cluster initialization fails > > > Key: IGNITE-19974 > URL: https://issues.apache.org/jira/browse/IGNITE-19974 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > org.apache.ignite.internal.Cluster#shutdown doesn't stop nodes if > initialization fails. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19953) Ignite 3 CLI: --verbose twice does not work
Aleksandr created IGNITE-19953: -- Summary: Ignite 3 CLI: --verbose twice does not work Key: IGNITE-19953 URL: https://issues.apache.org/jira/browse/IGNITE-19953 Project: Ignite Issue Type: Bug Reporter: Aleksandr Attachments: Screenshot 2023-07-11 at 16.10.43.png Just call any command with --verbose twice in REPL mode. The first one prints HTTP trace, the second one no. -- This message was sent by Atlassian Jira (v8.20.10#820010)
