[jira] [Closed] (IGNITE-23091) Java Client: Automatic Pojo Serialization
[ https://issues.apache.org/jira/browse/IGNITE-23091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr closed IGNITE-23091. -- > Java Client: Automatic Pojo Serialization > - > > Key: IGNITE-23091 > URL: https://issues.apache.org/jira/browse/IGNITE-23091 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Time Spent: 2h > Remaining Estimate: 0h > > in https://issues.apache.org/jira/browse/IGNITE-22643 we supported > serialization of Tuples in Compute API. This feature opens the opportunity to > convert pojos to/from tuples so we can support automatic pojos serialization. > The goal of this ticket is to support automatic plain objects serialization > that have only native types defined as their fields. In other words, we are > not going to support nested pojos now. > As a result, the compute API supports POJOs automatic convertion into/from > tuples and "it just works". After this is done, tickets for other client > should be created as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-23091) Java Client: Automatic Pojo Serialization
[ https://issues.apache.org/jira/browse/IGNITE-23091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reopened IGNITE-23091: > Java Client: Automatic Pojo Serialization > - > > Key: IGNITE-23091 > URL: https://issues.apache.org/jira/browse/IGNITE-23091 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Time Spent: 2h > Remaining Estimate: 0h > > in https://issues.apache.org/jira/browse/IGNITE-22643 we supported > serialization of Tuples in Compute API. This feature opens the opportunity to > convert pojos to/from tuples so we can support automatic pojos serialization. > The goal of this ticket is to support automatic plain objects serialization > that have only native types defined as their fields. In other words, we are > not going to support nested pojos now. > As a result, the compute API supports POJOs automatic convertion into/from > tuples and "it just works". After this is done, tickets for other client > should be created as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-23091) Java Client: Automatic Pojo Serialization
[ https://issues.apache.org/jira/browse/IGNITE-23091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr resolved IGNITE-23091. Resolution: Done > Java Client: Automatic Pojo Serialization > - > > Key: IGNITE-23091 > URL: https://issues.apache.org/jira/browse/IGNITE-23091 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Time Spent: 2h > Remaining Estimate: 0h > > in https://issues.apache.org/jira/browse/IGNITE-22643 we supported > serialization of Tuples in Compute API. This feature opens the opportunity to > convert pojos to/from tuples so we can support automatic pojos serialization. > The goal of this ticket is to support automatic plain objects serialization > that have only native types defined as their fields. In other words, we are > not going to support nested pojos now. > As a result, the compute API supports POJOs automatic convertion into/from > tuples and "it just works". After this is done, tickets for other client > should be created as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-23100) Improve semantic of authenticateAsync
[
https://issues.apache.org/jira/browse/IGNITE-23100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-23100.
Resolution: Fixed
Merged into main: d32ef2e80cac654dea8fe26b0c75cd5d4ae62766
> Improve semantic of authenticateAsync
> -
>
> Key: IGNITE-23100
> URL: https://issues.apache.org/jira/browse/IGNITE-23100
> Project: Ignite
> Issue Type: Improvement
> Components: security
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> IGNITE-23000 changed authentication to asynchronous but the
> {{BasicAuthenticator.authenticateAsync}} sometimes throw an exception
> directly and sometimes returns a failed future. It should consistently return
> a failed future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23093) Java Client: Nested objects automatic conversion
Aleksandr created IGNITE-23093: -- Summary: Java Client: Nested objects automatic conversion Key: IGNITE-23093 URL: https://issues.apache.org/jira/browse/IGNITE-23093 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Given nested tuples supported in Compute API, we can use this mechanism to represent nested user objects as "tuple of tuples". As a result of this ticket I should be able to define complex object that contains the mixture of native types and tuples. And this object is automatically converted into/from tuple, so I do not need to define marshallers for such objects. After the java client part is done, the tickets for other clients are created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23092) Nested Tuple Serialization
Aleksandr created IGNITE-23092: -- Summary: Nested Tuple Serialization Key: IGNITE-23092 URL: https://issues.apache.org/jira/browse/IGNITE-23092 Project: Ignite Issue Type: Improvement Components: compute Reporter: Aleksandr Now we support only plain Tuples in automatic serialization in Compute API. It seems like nothing stops us from working with tuples fields that is not a "native" type but the Tuple. So, we can represent complicated objects as a "Tuple of Tuples". We can threat top-level tuple as a schema-described table row and nested tuples as binary tuples with schema inside. 1. Design the format of nested tuples serialization 2. Support the format in both compute and table api. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23091) Java Client: Automatic Pojo Serialization
Aleksandr created IGNITE-23091: -- Summary: Java Client: Automatic Pojo Serialization Key: IGNITE-23091 URL: https://issues.apache.org/jira/browse/IGNITE-23091 Project: Ignite Issue Type: Improvement Components: compute Reporter: Aleksandr in https://issues.apache.org/jira/browse/IGNITE-22643 we supported serialization of Tuples in Compute API. This feature opens the opportunity to convert pojos to/from tuples so we can support automatic pojos serialization. The goal of this ticket is to support automatic plain objects serialization that have only native types defined as their fields. In other words, we are not going to support nested pojos now. As a result, the compute API supports POJOs automatic convertion into/from tuples and "it just works". After this is done, tickets for other client should be created as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22781) Cli. Incorrect question during connect to a node
[
https://issues.apache.org/jira/browse/IGNITE-22781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877087#comment-17877087
]
Aleksandr commented on IGNITE-22781:
thank you for the fix, merged into main:
e1fa84c00e17b31320acc357cd3fbf4291ae0c8a
> Cli. Incorrect question during connect to a node
>
>
> Key: IGNITE-22781
> URL: https://issues.apache.org/jira/browse/IGNITE-22781
> Project: Ignite
> Issue Type: Improvement
> Components: cli
>Reporter: Iurii Gerzhedovich
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Try to run `connect` command in CLI, it shows a strange question
> {code:java}
> [defaultNode]> connect
> You are already connected to the http://localhost:10300, do you want to
> connect as ? [Y/n]
> Connected to http://localhost:10300
> [defaultNode]> {code}
> Seems need to validate that node address has been provided.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22777) Improve CLI usability
[
https://issues.apache.org/jira/browse/IGNITE-22777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-22777:
---
Description:
I've tried to use CLI in AI3, it's cool and a big improvement in usability
compared to AI2.
However, there are many places to make it more user-friendly and look better.
What I suggest:
- # -As a user, I should know that cluster need to be initialized. The first
action in CLI is to connect to a node. We know that cluster not inited, let's
show the suggestion to the user that it is required and show suggestions on
what needs to do. And do it for any command required initialized cluster,
instead of show strange errors like {{196609 Trace ID:
c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}- - (separate ticket created)
# When I see the usage of cluster init I see 2 mandatory parameters, but it is
hard to look, at due to them mixed with optional parameters - let's move all
mandatory parameters to the beginning. It related to any CLI commands, not only
to `cluster init`
# For all commands let's add the following options: #
## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage section
## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
## `descriptionHeading = "%n"` to split the first and the second parts
was:
I've tried to use CLI in AI3, it's cool and a big improvement in usability
compared to AI2.
However, there are many places to make it more user-friendly and look better.
What I suggest:
- # As a user, I should know that cluster need to be initialized. The first
action in CLI is to connect to a node. We know that cluster not inited, let's
show the suggestion to the user that it is required and show suggestions on
what needs to do. And do it for any command required initialized cluster,
instead of show strange errors like {{196609 Trace ID:
c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}
# When I see the usage of cluster init I see 2 mandatory parameters, but it is
hard to look, at due to them mixed with optional parameters - let's move all
mandatory parameters to the beginning. It related to any CLI commands, not only
to `cluster init`- (separate ticket created)
# For all commands let's add the following options: #
## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage section
## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
## `descriptionHeading = "%n"` to split the first and the second parts
> Improve CLI usability
> -
>
> Key: IGNITE-22777
> URL: https://issues.apache.org/jira/browse/IGNITE-22777
> Project: Ignite
> Issue Type: Improvement
>Reporter: Iurii Gerzhedovich
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I've tried to use CLI in AI3, it's cool and a big improvement in usability
> compared to AI2.
> However, there are many places to make it more user-friendly and look better.
> What I suggest:
> - # -As a user, I should know that cluster need to be initialized. The first
> action in CLI is to connect to a node. We know that cluster not inited, let's
> show the suggestion to the user that it is required and show suggestions on
> what needs to do. And do it for any command required initialized cluster,
> instead of show strange errors like {{196609 Trace ID:
> c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}- - (separate ticket created)
> # When I see the usage of cluster init I see 2 mandatory parameters, but it
> is hard to look, at due to them mixed with optional parameters - let's move
> all mandatory parameters to the beginning. It related to any CLI commands,
> not only to `cluster init`
> # For all commands let's add the following options: #
> ## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage
> section
> ## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
> ## `descriptionHeading = "%n"` to split the first and the second parts
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22777) Improve CLI usability
[
https://issues.apache.org/jira/browse/IGNITE-22777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-22777:
---
Description:
I've tried to use CLI in AI3, it's cool and a big improvement in usability
compared to AI2.
However, there are many places to make it more user-friendly and look better.
What I suggest:
- # As a user, I should know that cluster need to be initialized. The first
action in CLI is to connect to a node. We know that cluster not inited, let's
show the suggestion to the user that it is required and show suggestions on
what needs to do. And do it for any command required initialized cluster,
instead of show strange errors like {{196609 Trace ID:
c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}
# When I see the usage of cluster init I see 2 mandatory parameters, but it is
hard to look, at due to them mixed with optional parameters - let's move all
mandatory parameters to the beginning. It related to any CLI commands, not only
to `cluster init`- (separate ticket created)
# For all commands let's add the following options: #
## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage section
## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
## `descriptionHeading = "%n"` to split the first and the second parts
was:
I've tried to use CLI in AI3, it's cool and a big improvement in usability
compared to AI2.
However, there are many places to make it more user-friendly and look better.
What I suggest:
# As a user, I should know that cluster need to be initialized. The first
action in CLI is to connect to a node. We know that cluster not inited, let's
show the suggestion to the user that it is required and show suggestions on
what needs to do. And do it for any command required initialized cluster,
instead of show strange errors like {{196609 Trace ID:
c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}
# When I see the usage of cluster init I see 2 mandatory parameters, but it is
hard to look, at due to them mixed with optional parameters - let's move all
mandatory parameters to the beginning. It related to any CLI commands, not only
to `cluster init`
# For all commands let's add the following options: #
## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage section
## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
## `descriptionHeading = "%n"` to split the first and the second parts
> Improve CLI usability
> -
>
> Key: IGNITE-22777
> URL: https://issues.apache.org/jira/browse/IGNITE-22777
> Project: Ignite
> Issue Type: Improvement
>Reporter: Iurii Gerzhedovich
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I've tried to use CLI in AI3, it's cool and a big improvement in usability
> compared to AI2.
> However, there are many places to make it more user-friendly and look better.
> What I suggest:
> - # As a user, I should know that cluster need to be initialized. The first
> action in CLI is to connect to a node. We know that cluster not inited, let's
> show the suggestion to the user that it is required and show suggestions on
> what needs to do. And do it for any command required initialized cluster,
> instead of show strange errors like {{196609 Trace ID:
> c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}
> # When I see the usage of cluster init I see 2 mandatory parameters, but it
> is hard to look, at due to them mixed with optional parameters - let's move
> all mandatory parameters to the beginning. It related to any CLI commands,
> not only to `cluster init`- (separate ticket created)
> # For all commands let's add the following options: #
> ## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage
> section
> ## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
> ## `descriptionHeading = "%n"` to split the first and the second parts
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23070) Do not print logging info into terminal
Aleksandr created IGNITE-23070: -- Summary: Do not print logging info into terminal Key: IGNITE-23070 URL: https://issues.apache.org/jira/browse/IGNITE-23070 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr Now we print the following line during CLI start: SLF4J(I): Connected with provider of type [org.slf4j.jul.JULServiceProvider] Probably this is not what we want. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23069) --help option does not work in CLI
Aleksandr created IGNITE-23069: -- Summary: --help option does not work in CLI Key: IGNITE-23069 URL: https://issues.apache.org/jira/browse/IGNITE-23069 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr I've tried to explore the CLI features without any doc just through --help command. As a result I've noticed that we do not consider --help flag in almost all commands. For, example, try: cluster --help, cluster topology --help, cluster topology physical --help. We display help message only when the command has a lack of options. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22777) Improve CLI usability
[
https://issues.apache.org/jira/browse/IGNITE-22777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876652#comment-17876652
]
Aleksandr commented on IGNITE-22777:
I've created one more ticket for `cluster init` command because it's already
2.5k lines changed and I do not want to mix multiple fixes in one PR.
https://issues.apache.org/jira/browse/IGNITE-23068
> Improve CLI usability
> -
>
> Key: IGNITE-22777
> URL: https://issues.apache.org/jira/browse/IGNITE-22777
> Project: Ignite
> Issue Type: Improvement
>Reporter: Iurii Gerzhedovich
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I've tried to use CLI in AI3, it's cool and a big improvement in usability
> compared to AI2.
> However, there are many places to make it more user-friendly and look better.
> What I suggest:
> # As a user, I should know that cluster need to be initialized. The first
> action in CLI is to connect to a node. We know that cluster not inited, let's
> show the suggestion to the user that it is required and show suggestions on
> what needs to do. And do it for any command required initialized cluster,
> instead of show strange errors like {{196609 Trace ID:
> c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}
> # When I see the usage of cluster init I see 2 mandatory parameters, but it
> is hard to look, at due to them mixed with optional parameters - let's move
> all mandatory parameters to the beginning. It related to any CLI commands,
> not only to `cluster init`
> # For all commands let's add the following options: #
> ## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage
> section
> ## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
> ## `descriptionHeading = "%n"` to split the first and the second parts
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23068) Improve `cluster init` in CLI
Aleksandr created IGNITE-23068: -- Summary: Improve `cluster init` in CLI Key: IGNITE-23068 URL: https://issues.apache.org/jira/browse/IGNITE-23068 Project: Ignite Issue Type: Improvement Reporter: Aleksandr As a user, I should know that cluster need to be initialized. The first action in CLI is to connect to a node. We know that cluster not inited, let's show the suggestion to the user that it is required and show suggestions on what needs to do. And do it for any command required initialized cluster, instead of show strange errors like 196609 Trace ID: c5bc2dc3-7ed8-4191-b65a-559db9e680b1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23068) Improve `cluster init` in CLI
[ https://issues.apache.org/jira/browse/IGNITE-23068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-23068: --- Component/s: cli > Improve `cluster init` in CLI > - > > Key: IGNITE-23068 > URL: https://issues.apache.org/jira/browse/IGNITE-23068 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > As a user, I should know that cluster need to be initialized. The first > action in CLI is to connect to a node. We know that cluster not inited, let's > show the suggestion to the user that it is required and show suggestions on > what needs to do. And do it for any command required initialized cluster, > instead of show strange errors like 196609 Trace ID: > c5bc2dc3-7ed8-4191-b65a-559db9e680b1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23068) Improve `cluster init` in CLI
[ https://issues.apache.org/jira/browse/IGNITE-23068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-23068: --- Labels: ignite-3 (was: ) > Improve `cluster init` in CLI > - > > Key: IGNITE-23068 > URL: https://issues.apache.org/jira/browse/IGNITE-23068 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > As a user, I should know that cluster need to be initialized. The first > action in CLI is to connect to a node. We know that cluster not inited, let's > show the suggestion to the user that it is required and show suggestions on > what needs to do. And do it for any command required initialized cluster, > instead of show strange errors like 196609 Trace ID: > c5bc2dc3-7ed8-4191-b65a-559db9e680b1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23024) Review broadcast execution and marshallers
Aleksandr created IGNITE-23024: -- Summary: Review broadcast execution and marshallers Key: IGNITE-23024 URL: https://issues.apache.org/jira/browse/IGNITE-23024 Project: Ignite Issue Type: Improvement Components: compute Reporter: Aleksandr The problem is that when we call broadcast compute job (or any kind of job that is executed on the same node where the client code runs) in embedded move we get the following behavior: - job argument is marshalled on client, unmarshalled on server, job called - the result of the job is not marshalled by server when the embedded client is the same as the compute executor. This might be ok but the behavior must be consistent: If we marshal job arguments for the same node the we should marshal job result as well. Or do not marshal at all. As a result of this thicket we have to define the contract and support it. As an option we can discuss "not specified". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22995) ItEmbeddedMarshallingTest#broadcast may hang
[
https://issues.apache.org/jira/browse/IGNITE-22995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-22995:
--
Assignee: Aleksandr
> ItEmbeddedMarshallingTest#broadcast may hang
>
>
> Key: IGNITE-22995
> URL: https://issues.apache.org/jira/browse/IGNITE-22995
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_29502 (2).log
>
>
> Runner suite on TC main
> [failed|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8396272?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false&logView=flowAware]
> with Execution timeout several times
> {code:java}
> The build [Integration Tests]::[Module] Runner #29502 {buildId=8396242} has
> been running for more than 40 minutes. Terminating...
> 14:57:09 Execution timeout {code}
> The reason is likely ItEmbeddedMarshallingTest#broadcast hanging. Easily
> reproduced locally by adding @RepeatedTest(1000). Full TC logs in attachments.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22787) Support marshalers in MapReduce
[ https://issues.apache.org/jira/browse/IGNITE-22787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22787: --- Description: Compute API now supports marhalers as a part of JobDescriptor object. So we have to support the same api for MapReduce API. Here is the original IEP https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization was:Compute API now supports marhalers as a part of JobDescriptor object. So we have to support the same api for MapReduce API. > Support marshalers in MapReduce > --- > > Key: IGNITE-22787 > URL: https://issues.apache.org/jira/browse/IGNITE-22787 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Compute API now supports marhalers as a part of JobDescriptor object. So we > have to support the same api for MapReduce API. > Here is the original IEP > https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22777) Improve CLI usability
[
https://issues.apache.org/jira/browse/IGNITE-22777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-22777:
--
Assignee: Aleksandr
> Improve CLI usability
> -
>
> Key: IGNITE-22777
> URL: https://issues.apache.org/jira/browse/IGNITE-22777
> Project: Ignite
> Issue Type: Improvement
>Reporter: Iurii Gerzhedovich
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> I've tried to use CLI in AI3, it's cool and a big improvement in usability
> compared to AI2.
> However, there are many places to make it more user-friendly and look better.
> What I suggest:
> # As a user, I should know that cluster need to be initialized. The first
> action in CLI is to connect to a node. We know that cluster not inited, let's
> show the suggestion to the user that it is required and show suggestions on
> what needs to do. And do it for any command required initialized cluster,
> instead of show strange errors like {{196609 Trace ID:
> c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}
> # When I see the usage of cluster init I see 2 mandatory parameters, but it
> is hard to look, at due to them mixed with optional parameters - let's move
> all mandatory parameters to the beginning. It related to any CLI commands,
> not only to `cluster init`
> # For all commands let's add the following options: #
> ## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage
> section
> ## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
> ## `descriptionHeading = "%n"` to split the first and the second parts
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22854) Duplicates in help message
Aleksandr created IGNITE-22854: -- Summary: Duplicates in help message Key: IGNITE-22854 URL: https://issues.apache.org/jira/browse/IGNITE-22854 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr Attachments: image.png Several commands have duplicates in help message for options, see attachment. DoD: all commands are checked and all duplicates are dropped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22643) Binary Tuple with schema: implementation
[ https://issues.apache.org/jira/browse/IGNITE-22643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22643: -- Assignee: Aleksandr > Binary Tuple with schema: implementation > > > Key: IGNITE-22643 > URL: https://issues.apache.org/jira/browse/IGNITE-22643 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Implement the binary tuple with schema specification in Ignite and support in > listed apis. Acceptance criteria: I can create a Tuple in any way and pass it > to the kv (assuming schema is matching), I can pass the Tuple to the compute > API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22658) Obsolete documentation in IgniteCatalog
[ https://issues.apache.org/jira/browse/IGNITE-22658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867787#comment-17867787 ] Aleksandr commented on IGNITE-22658: Merged into main, thanks f665bb37200119c768d0a59146060785ac9192da > Obsolete documentation in IgniteCatalog > --- > > Key: IGNITE-22658 > URL: https://issues.apache.org/jira/browse/IGNITE-22658 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Maksim Myskov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > IgniteCatalog contains examples that are obsolete. They can be identified by > grepping for 'ignite.catalog().create'. > All these examples mention a method called execute(), but it's not there > anymore. Also, some of them mention methods called created() which don't seem > to exist as well. > Also, createZone() lacks javadoc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22787) Support marshalers in MapReduce
Aleksandr created IGNITE-22787: -- Summary: Support marshalers in MapReduce Key: IGNITE-22787 URL: https://issues.apache.org/jira/browse/IGNITE-22787 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Compute API now supports marhalers as a part of JobDescriptor object. So we have to support the same api for MapReduce API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22645) C++ Client Marshaler API
[
https://issues.apache.org/jira/browse/IGNITE-22645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-22645:
---
Description:
Compute API provides JobDescriptor in java
https://github.com/apache/ignite-3/blob/7dedc06ea25b9c63dcdfb69290c7862c754a0d8f/modules/api/src/main/java/org/apache/ignite/compute/JobDescriptor.java#L29
With this api I can define argument and result marshallers in the java client:
{code:java}
String result = compute.execute(
JobTarget.node(targetNode),
JobDescriptor.builder(ArgMarshalingJob.class)
.argumentMarshaller(new ArgumentStringMarshaller())
.resultMarshaller(new ResultStringUnMarshaller())
.build(),
"Input"
);
// ...
static class ArgumentStringMarshaller implements ByteArrayMarshaler {
@Override
public byte @Nullable [] marshal(@Nullable String object) {
return ByteArrayMarshaler.super.marshal(object +
":marshalledOnClient");
}
}
static class ResultStringUnMarshaller implements ByteArrayMarshaler
{
@Override
public @Nullable String unmarshal(byte @Nullable [] raw) {
return ByteArrayMarshaler.super.unmarshal(raw) +
":unmarshalledOnClient";
}
}
{code}
Argument marshaller is called on the client side during job argument packing,
so, the argument is sent as marshalled byte[]. Result marhaller unmarshalls the
result from the job from byte[] to the target type.
Invariant: If one has defined argument/result marshaller in JobDescriptor then
they must define argument/result marshaller in the compute job.
By default marshallers are null everywhere. Null means "No marshaller defined",
the existing serialization is used. More in IEP:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization
was:tbd
> C++ Client Marshaler API
>
>
> Key: IGNITE-22645
> URL: https://issues.apache.org/jira/browse/IGNITE-22645
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr
>Assignee: Igor Sapego
>Priority: Major
> Labels: ignite-3
>
> Compute API provides JobDescriptor in java
> https://github.com/apache/ignite-3/blob/7dedc06ea25b9c63dcdfb69290c7862c754a0d8f/modules/api/src/main/java/org/apache/ignite/compute/JobDescriptor.java#L29
>
> With this api I can define argument and result marshallers in the java
> client:
> {code:java}
> String result = compute.execute(
> JobTarget.node(targetNode),
> JobDescriptor.builder(ArgMarshalingJob.class)
> .argumentMarshaller(new ArgumentStringMarshaller())
> .resultMarshaller(new ResultStringUnMarshaller())
> .build(),
> "Input"
> );
> // ...
> static class ArgumentStringMarshaller implements ByteArrayMarshaler {
> @Override
> public byte @Nullable [] marshal(@Nullable String object) {
> return ByteArrayMarshaler.super.marshal(object +
> ":marshalledOnClient");
> }
> }
> static class ResultStringUnMarshaller implements
> ByteArrayMarshaler {
> @Override
> public @Nullable String unmarshal(byte @Nullable [] raw) {
> return ByteArrayMarshaler.super.unmarshal(raw) +
> ":unmarshalledOnClient";
> }
> }
> {code}
> Argument marshaller is called on the client side during job argument packing,
> so, the argument is sent as marshalled byte[]. Result marhaller unmarshalls
> the result from the job from byte[] to the target type.
> Invariant: If one has defined argument/result marshaller in JobDescriptor
> then they must define argument/result marshaller in the compute job.
> By default marshallers are null everywhere. Null means "No marshaller
> defined", the existing serialization is used. More in IEP:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22644) .NET Client Marshaler API
[
https://issues.apache.org/jira/browse/IGNITE-22644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-22644:
---
Description:
Compute API provides JobDescriptor in java
https://github.com/apache/ignite-3/blob/7dedc06ea25b9c63dcdfb69290c7862c754a0d8f/modules/api/src/main/java/org/apache/ignite/compute/JobDescriptor.java#L29
With this api I can define argument and result marshallers in the java client:
{code:java}
String result = compute.execute(
JobTarget.node(targetNode),
JobDescriptor.builder(ArgMarshalingJob.class)
.argumentMarshaller(new ArgumentStringMarshaller())
.resultMarshaller(new ResultStringUnMarshaller())
.build(),
"Input"
);
// ...
static class ArgumentStringMarshaller implements ByteArrayMarshaler {
@Override
public byte @Nullable [] marshal(@Nullable String object) {
return ByteArrayMarshaler.super.marshal(object +
":marshalledOnClient");
}
}
static class ResultStringUnMarshaller implements ByteArrayMarshaler
{
@Override
public @Nullable String unmarshal(byte @Nullable [] raw) {
return ByteArrayMarshaler.super.unmarshal(raw) +
":unmarshalledOnClient";
}
}
{code}
Argument marshaller is called on the client side during job argument packing,
so, the argument is sent as marshalled byte[]. Result marhaller unmarshalls the
result from the job from byte[] to the target type.
Invariant: If one has defined argument/result marshaller in JobDescriptor then
they must define argument/result marshaller in the compute job.
By default marshallers are null everywhere. Null means "No marshaller defined",
the existing serialization is used. More in IEP:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization
was:tbd
> .NET Client Marshaler API
> -
>
> Key: IGNITE-22644
> URL: https://issues.apache.org/jira/browse/IGNITE-22644
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
>
> Compute API provides JobDescriptor in java
> https://github.com/apache/ignite-3/blob/7dedc06ea25b9c63dcdfb69290c7862c754a0d8f/modules/api/src/main/java/org/apache/ignite/compute/JobDescriptor.java#L29
>
> With this api I can define argument and result marshallers in the java
> client:
> {code:java}
> String result = compute.execute(
> JobTarget.node(targetNode),
> JobDescriptor.builder(ArgMarshalingJob.class)
> .argumentMarshaller(new ArgumentStringMarshaller())
> .resultMarshaller(new ResultStringUnMarshaller())
> .build(),
> "Input"
> );
> // ...
> static class ArgumentStringMarshaller implements ByteArrayMarshaler {
> @Override
> public byte @Nullable [] marshal(@Nullable String object) {
> return ByteArrayMarshaler.super.marshal(object +
> ":marshalledOnClient");
> }
> }
> static class ResultStringUnMarshaller implements
> ByteArrayMarshaler {
> @Override
> public @Nullable String unmarshal(byte @Nullable [] raw) {
> return ByteArrayMarshaler.super.unmarshal(raw) +
> ":unmarshalledOnClient";
> }
> }
> {code}
> Argument marshaller is called on the client side during job argument packing,
> so, the argument is sent as marshalled byte[]. Result marhaller unmarshalls
> the result from the job from byte[] to the target type.
> Invariant: If one has defined argument/result marshaller in JobDescriptor
> then they must define argument/result marshaller in the compute job.
> By default marshallers are null everywhere. Null means "No marshaller
> defined", the existing serialization is used. More in IEP:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22658) Obsolete documentation in IgniteCatalog
[ https://issues.apache.org/jira/browse/IGNITE-22658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22658: -- Assignee: (was: Aleksandr) > Obsolete documentation in IgniteCatalog > --- > > Key: IGNITE-22658 > URL: https://issues.apache.org/jira/browse/IGNITE-22658 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > IgniteCatalog contains examples that are obsolete. They can be identified by > grepping for 'ignite.catalog().create'. > All these examples mention a method called execute(), but it's not there > anymore. Also, some of them mention methods called created() which don't seem > to exist as well. > Also, createZone() lacks javadoc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22646) Java Client Marshaler API
[ https://issues.apache.org/jira/browse/IGNITE-22646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22646: -- Assignee: Aleksandr > Java Client Marshaler API > - > > Key: IGNITE-22646 > URL: https://issues.apache.org/jira/browse/IGNITE-22646 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization > KV and Compute API should support marshalers. As a result of this ticket, I > should be able to define any marshaller from the user type to byte[] and call > mentioned APIs with them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22658) Obsolete documentation in IgniteCatalog
[ https://issues.apache.org/jira/browse/IGNITE-22658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22658: -- Assignee: Aleksandr > Obsolete documentation in IgniteCatalog > --- > > Key: IGNITE-22658 > URL: https://issues.apache.org/jira/browse/IGNITE-22658 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > IgniteCatalog contains examples that are obsolete. They can be identified by > grepping for 'ignite.catalog().create'. > All these examples mention a method called execute(), but it's not there > anymore. Also, some of them mention methods called created() which don't seem > to exist as well. > Also, createZone() lacks javadoc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22477) BinaryTuple serialization format: Specification
[ https://issues.apache.org/jira/browse/IGNITE-22477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr resolved IGNITE-22477. Resolution: Fixed https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization I've added the specification for plain inline schema but not for nested one. I think it is better to implement the plain part and then add support for nested types. > BinaryTuple serialization format: Specification > > > Key: IGNITE-22477 > URL: https://issues.apache.org/jira/browse/IGNITE-22477 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Specify the common binary tuple format that is going to be supported by Kv, > Record, and Compute apis. The specification should be defined in IEP. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22174) Design for UserObjectSerialization
[ https://issues.apache.org/jira/browse/IGNITE-22174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864358#comment-17864358 ] Aleksandr commented on IGNITE-22174: https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization > 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 > Labels: ignite-3 > > As a result the IEP should be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22394) Bad CLI error message when connecting to port 10800
[ https://issues.apache.org/jira/browse/IGNITE-22394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864359#comment-17864359 ] Aleksandr commented on IGNITE-22394: [~Mikhail Pochatkin] hi, I can not find the PR for this ticket but the status is PATCH AVAILABLE. > Bad CLI error message when connecting to port 10800 > --- > > Key: IGNITE-22394 > URL: https://issues.apache.org/jira/browse/IGNITE-22394 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > When attempting to connect to port 10800, you get an uninformative error > message: > > ``` > unexpected end of stream on http://localhost:10800/... > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22174) Design for UserObjectSerialization
[ https://issues.apache.org/jira/browse/IGNITE-22174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr resolved IGNITE-22174. Resolution: Fixed > 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 > Labels: ignite-3 > > As a result the IEP should be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22646) Java Client Marshaler API
[ https://issues.apache.org/jira/browse/IGNITE-22646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22646: --- Description: https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization KV and Compute API should support marshalers. As a result of this ticket, I should be able to define any marshaller from the user type to byte[] and call mentioned APIs with them. was:tbd > Java Client Marshaler API > - > > Key: IGNITE-22646 > URL: https://issues.apache.org/jira/browse/IGNITE-22646 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization > KV and Compute API should support marshalers. As a result of this ticket, I > should be able to define any marshaller from the user type to byte[] and call > mentioned APIs with them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22645) C++ Client Marshaler API
[ https://issues.apache.org/jira/browse/IGNITE-22645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22645: --- Labels: ignite-3 (was: ) > C++ Client Marshaler API > > > Key: IGNITE-22645 > URL: https://issues.apache.org/jira/browse/IGNITE-22645 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > tbd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22646) Java Client Marshaler API
[ https://issues.apache.org/jira/browse/IGNITE-22646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22646: --- Labels: ignite-3 (was: ) > Java Client Marshaler API > - > > Key: IGNITE-22646 > URL: https://issues.apache.org/jira/browse/IGNITE-22646 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > tbd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22644) .NET Client Marshaler API
[ https://issues.apache.org/jira/browse/IGNITE-22644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22644: --- Labels: ignite-3 (was: ) > .NET Client Marshaler API > - > > Key: IGNITE-22644 > URL: https://issues.apache.org/jira/browse/IGNITE-22644 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > tbd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22646) Java Client Marshaler API
Aleksandr created IGNITE-22646: -- Summary: Java Client Marshaler API Key: IGNITE-22646 URL: https://issues.apache.org/jira/browse/IGNITE-22646 Project: Ignite Issue Type: Improvement Reporter: Aleksandr tbd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22645) C++ Client Marshaler API
Aleksandr created IGNITE-22645: -- Summary: C++ Client Marshaler API Key: IGNITE-22645 URL: https://issues.apache.org/jira/browse/IGNITE-22645 Project: Ignite Issue Type: Improvement Reporter: Aleksandr tbd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22644) .NET Client Marshaler API
Aleksandr created IGNITE-22644: -- Summary: .NET Client Marshaler API Key: IGNITE-22644 URL: https://issues.apache.org/jira/browse/IGNITE-22644 Project: Ignite Issue Type: Improvement Reporter: Aleksandr tbd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22477) BinaryTuple serialization format: Specification
[ https://issues.apache.org/jira/browse/IGNITE-22477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22477: -- Assignee: Aleksandr > BinaryTuple serialization format: Specification > > > Key: IGNITE-22477 > URL: https://issues.apache.org/jira/browse/IGNITE-22477 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Specify the common binary tuple format that is going to be supported by Kv, > Record, and Compute apis. The specification should be defined in IEP. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22477) BinaryTuple serialization format: Specification
[ https://issues.apache.org/jira/browse/IGNITE-22477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22477: --- Summary: BinaryTuple serialization format: Specification (was: BinaryTuple serialization format: Specification and Implementation ) > BinaryTuple serialization format: Specification > > > Key: IGNITE-22477 > URL: https://issues.apache.org/jira/browse/IGNITE-22477 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Specify the common binary tuple format that is going to be supported by Kv, > Record, and Compute apis. The specification should be defined in IEP. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22643) Binary Tuple with schema: implementation
Aleksandr created IGNITE-22643: -- Summary: Binary Tuple with schema: implementation Key: IGNITE-22643 URL: https://issues.apache.org/jira/browse/IGNITE-22643 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Implement the binary tuple with schema specification in Ignite and support in listed apis. Acceptance criteria: I can create a Tuple in any way and pass it to the kv (assuming schema is matching), I can pass the Tuple to the compute API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22477) BinaryTuple serialization format: Specification and Implementation
[ https://issues.apache.org/jira/browse/IGNITE-22477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22477: --- Description: Specify the common binary tuple format that is going to be supported by Kv, Record, and Compute apis. The specification should be defined in IEP. The second part of this ticket is to implement this specification in Ignite and support in listed apis. Acceptance criteria: I can create a Tuple in any way and pass it to the kv (assuming schema is matching), I can pass the Tuple to the compute API. was: The first part of this ticket is to specify the common binary tuple format that is going to be supported by Kv, Record, and Compute apis. The specification should be defined in IEP. The second part of this ticket is to implement this specification in Ignite and support in listed apis. Acceptance criteria: I can create a Tuple in any way and pass it to the kv (assuming schema is matching), I can pass the Tuple to the compute API. > BinaryTuple serialization format: Specification and Implementation > --- > > Key: IGNITE-22477 > URL: https://issues.apache.org/jira/browse/IGNITE-22477 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Specify the common binary tuple format that is going to be supported by Kv, > Record, and Compute apis. The specification should be defined in IEP. > The second part of this ticket is to implement this specification in Ignite > and support in listed apis. Acceptance criteria: I can create a Tuple in any > way and pass it to the kv (assuming schema is matching), I can pass the Tuple > to the compute API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22477) BinaryTuple serialization format: Specification and Implementation
[ https://issues.apache.org/jira/browse/IGNITE-22477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22477: --- Description: Specify the common binary tuple format that is going to be supported by Kv, Record, and Compute apis. The specification should be defined in IEP. was: Specify the common binary tuple format that is going to be supported by Kv, Record, and Compute apis. The specification should be defined in IEP. The second part of this ticket is to implement this specification in Ignite and support in listed apis. Acceptance criteria: I can create a Tuple in any way and pass it to the kv (assuming schema is matching), I can pass the Tuple to the compute API. > BinaryTuple serialization format: Specification and Implementation > --- > > Key: IGNITE-22477 > URL: https://issues.apache.org/jira/browse/IGNITE-22477 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Specify the common binary tuple format that is going to be supported by Kv, > Record, and Compute apis. The specification should be defined in IEP. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22596) Fix ItThinClientComputeTest
Aleksandr created IGNITE-22596: -- Summary: Fix ItThinClientComputeTest Key: IGNITE-22596 URL: https://issues.apache.org/jira/browse/IGNITE-22596 Project: Ignite Issue Type: Bug Components: compute Reporter: Aleksandr testExecuteMapReduceExceptionPropagation is flaky if started as part of ItThinClientComputeTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22577) Fix remote node test in Compute
Aleksandr created IGNITE-22577: -- Summary: Fix remote node test in Compute Key: IGNITE-22577 URL: https://issues.apache.org/jira/browse/IGNITE-22577 Project: Ignite Issue Type: Bug Components: compute Reporter: Aleksandr After the Compute API changed, we have to rewrite some tests (see disabled with this ticket). The problem is that we use CountDownLatch in remote jobs that we can not serialize by default. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22430) Rename JobStatus to JobState and vice versa
[ https://issues.apache.org/jira/browse/IGNITE-22430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856791#comment-17856791 ] Aleksandr commented on IGNITE-22430: Thanks, merged into main: 79aad62d346ef5e8f7ce413a9347d769ba22b43b > Rename JobStatus to JobState and vice versa > --- > > Key: IGNITE-22430 > URL: https://issues.apache.org/jira/browse/IGNITE-22430 > Project: Ignite > Issue Type: Improvement > Components: compute >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > * *o.a.i.compute.JobStatus* -> *JobState* > * *JobState* -> *JobStatus* > *Status* is more suitable for enums. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22441) Add parameter object to Data Streamer
[ https://issues.apache.org/jira/browse/IGNITE-22441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856768#comment-17856768 ] Aleksandr commented on IGNITE-22441: [~ptupitsyn] ok > Add parameter object to Data Streamer > - > > Key: IGNITE-22441 > URL: https://issues.apache.org/jira/browse/IGNITE-22441 > Project: Ignite > Issue Type: Improvement > Components: compute, streaming >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Similar to IGNITE-22425, add parameter object to DataStreamer to simplify the > signature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22532) --metastorage-group should be optional
[
https://issues.apache.org/jira/browse/IGNITE-22532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-22532:
---
Labels: ignite-3 (was: )
> --metastorage-group should be optional
> --
>
> Key: IGNITE-22532
> URL: https://issues.apache.org/jira/browse/IGNITE-22532
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> {code:bash}
> node1]> cluster init --cluster-name=TEST
> --cluster-management-group=node1,node2,node3
> Missing required options: '--metastorage-group=',
> '--name='
> Usage: cluster init [-hv] --name= [--url=]
> [--cluster-management-group=[, name>...]]... --metastorage-group=[, name>...] [--metastorage-group=[, name>...]]... [--config= | --config-file=]
> Initializes an Ignite cluster
> --cluster-management-group=[,...]
> Names of nodes (use comma-separated list of node
>names '--cluster-management-group node1, node2'
>to specify more than one node) those will host
>the Cluster Management Group.If omitted, then
>--meta-store-node values will also supply the
>nodes for the Cluster Management Group.
> --config= Cluster configuration that will be applied during
>the cluster initialization
> --config-file= Path to cluster configuration file
> -h, --help Show help for the specified command
> --metastorage-group=[,...]
> Metastorage group nodes (use comma-separated list
>of node names '--metastorage-group node1,
> node2'
>to specify more than one node) that will host
>the Meta Storage.If the --metastorage-group
>parameter is omitted, the same nodes will also
>host the Cluster Management Group.
> --name= Human-readable name of the cluster
> --url= URL of cluster endpoint. It can be any node
> URL.If
>not set, then the default URL from the profile
>settings will be used
> -v, --verbose Show additional information: logs, REST
> calls.This
>flag is useful for debugging
> [node1]>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22532) --metastorage-group should be optional
Aleksandr created IGNITE-22532:
--
Summary: --metastorage-group should be optional
Key: IGNITE-22532
URL: https://issues.apache.org/jira/browse/IGNITE-22532
Project: Ignite
Issue Type: Improvement
Reporter: Aleksandr
{code:bash}
node1]> cluster init --cluster-name=TEST
--cluster-management-group=node1,node2,node3
Missing required options: '--metastorage-group=',
'--name='
Usage: cluster init [-hv] --name= [--url=]
[--cluster-management-group=[,...]]... --metastorage-group=[,...] [--metastorage-group=[,...]]... [--config= | --config-file=]
Initializes an Ignite cluster
--cluster-management-group=[,...]
Names of nodes (use comma-separated list of node
names '--cluster-management-group node1, node2'
to specify more than one node) those will host
the Cluster Management Group.If omitted, then
--meta-store-node values will also supply the
nodes for the Cluster Management Group.
--config= Cluster configuration that will be applied during
the cluster initialization
--config-file= Path to cluster configuration file
-h, --help Show help for the specified command
--metastorage-group=[,...]
Metastorage group nodes (use comma-separated list
of node names '--metastorage-group node1, node2'
to specify more than one node) that will host
the Meta Storage.If the --metastorage-group
parameter is omitted, the same nodes will also
host the Cluster Management Group.
--name= Human-readable name of the cluster
--url= URL of cluster endpoint. It can be any node URL.If
not set, then the default URL from the profile
settings will be used
-v, --verbose Show additional information: logs, REST calls.This
flag is useful for debugging
[node1]>
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22508) Support Pojos in ComputeJob
Aleksandr created IGNITE-22508: -- Summary: Support Pojos in ComputeJob Key: IGNITE-22508 URL: https://issues.apache.org/jira/browse/IGNITE-22508 Project: Ignite Issue Type: Improvement Reporter: Aleksandr After IGNITE-22477 is done, we have to support pojo serde into/from BinaryTuple. PlatformTestRunner.ColocationHashJob should be enabled also. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22478) Change Compute API
[
https://issues.apache.org/jira/browse/IGNITE-22478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-22478:
---
Description:
It seems like execute(Object... args) is an overkill for the "basic" compute
api. We agreed that we are going to support the only one input argument in the
low-level API. The goal of this ticket is to refactor the existing API so that
we will have:
ComputeJob {
R execute(ExcecutionContext ctx, T input)
}
The type of the I is primitive for this ticket. We are not going to think: "How
do we pass complex objects?". This will be solved in following tickets.
was:
It seems like execute(Object... args) is an overkill for the "basic" compute
api. We agreed that we are going to support the only one input argument in the
low-level API. The goal of this ticket is to refactor the existing API so that
we will have:
ComputeJob {
O execute(ExcecutionContext ctx, I input)
}
The type of the I is primitive for this ticket. We are not going to think: "How
do we pass complex objects?". This will be solved in following tickets.
> Change Compute API
> --
>
> Key: IGNITE-22478
> URL: https://issues.apache.org/jira/browse/IGNITE-22478
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> It seems like execute(Object... args) is an overkill for the "basic" compute
> api. We agreed that we are going to support the only one input argument in
> the low-level API. The goal of this ticket is to refactor the existing API so
> that we will have:
> ComputeJob {
> R execute(ExcecutionContext ctx, T input)
> }
> The type of the I is primitive for this ticket. We are not going to think:
> "How do we pass complex objects?". This will be solved in following tickets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22478) Change Compute API
[
https://issues.apache.org/jira/browse/IGNITE-22478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-22478:
--
Assignee: Aleksandr
> Change Compute API
> --
>
> Key: IGNITE-22478
> URL: https://issues.apache.org/jira/browse/IGNITE-22478
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> It seems like execute(Object... args) is an overkill for the "basic" compute
> api. We agreed that we are going to support the only one input argument in
> the low-level API. The goal of this ticket is to refactor the existing API so
> that we will have:
> ComputeJob {
> O execute(ExcecutionContext ctx, I input)
> }
> The type of the I is primitive for this ticket. We are not going to think:
> "How do we pass complex objects?". This will be solved in following tickets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22477) BinaryTuple serialization format: Specification and Implementation
[ https://issues.apache.org/jira/browse/IGNITE-22477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22477: --- Labels: ignite-3 (was: ) > BinaryTuple serialization format: Specification and Implementation > --- > > Key: IGNITE-22477 > URL: https://issues.apache.org/jira/browse/IGNITE-22477 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > The first part of this ticket is to specify the common binary tuple format > that is going to be supported by Kv, Record, and Compute apis. The > specification should be defined in IEP. > The second part of this ticket is to implement this specification in Ignite > and support in listed apis. Acceptance criteria: I can create a Tuple in any > way and pass it to the kv (assuming schema is matching), I can pass the Tuple > to the compute API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22478) Change Compute API
Aleksandr created IGNITE-22478:
--
Summary: Change Compute API
Key: IGNITE-22478
URL: https://issues.apache.org/jira/browse/IGNITE-22478
Project: Ignite
Issue Type: Improvement
Components: compute
Reporter: Aleksandr
It seems like execute(Object... args) is an overkill for the "basic" compute
api. We agreed that we are going to support the only one input argument in the
low-level API. The goal of this ticket is to refactor the existing API so that
we will have:
ComputeJob {
O execute(ExcecutionContext ctx, I input)
}
The type of the I is primitive for this ticket. We are not going to think: "How
do we pass complex objects?". This will be solved in following tickets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22477) BinaryTuple serialization format: Specification and Implementation
Aleksandr created IGNITE-22477: -- Summary: BinaryTuple serialization format: Specification and Implementation Key: IGNITE-22477 URL: https://issues.apache.org/jira/browse/IGNITE-22477 Project: Ignite Issue Type: Improvement Components: compute Reporter: Aleksandr The first part of this ticket is to specify the common binary tuple format that is going to be supported by Kv, Record, and Compute apis. The specification should be defined in IEP. The second part of this ticket is to implement this specification in Ignite and support in listed apis. Acceptance criteria: I can create a Tuple in any way and pass it to the kv (assuming schema is matching), I can pass the Tuple to the compute API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (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 resolved IGNITE-22244. Resolution: Fixed merged into main 9823caf4614c41df55265b8c20813e31424cc76c > 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 >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > [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] [Reopened] (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 reopened IGNITE-22244: corner case found when config has "100%" > 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 >Assignee: 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-22438) ItFileTransferTest if flaky
Aleksandr created IGNITE-22438: -- Summary: ItFileTransferTest if flaky Key: IGNITE-22438 URL: https://issues.apache.org/jira/browse/IGNITE-22438 Project: Ignite Issue Type: Bug Reporter: Aleksandr https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8179425?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildTestsSection=true&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&expandCode+Inspection=true&expandBuildChangesSection=true https://ci.ignite.apache.org/test/-4823697508851206864?currentProjectId=ApacheIgnite3xGradle_Test_IntegrationTests&expandTestHistoryChartSection=true The test is flaky. Looks like this commit is the one after which we observe failures. But the changes are not related. https://github.com/apache/ignite-3/commit/b594483b22d473ed55af7552757c32e54d445175 The investigation needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22296) Normalize --cmg-node and --meta-storage-node options in CLI
[ https://issues.apache.org/jira/browse/IGNITE-22296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22296: -- Assignee: Aleksandr > Normalize --cmg-node and --meta-storage-node options in CLI > --- > > Key: IGNITE-22296 > URL: https://issues.apache.org/jira/browse/IGNITE-22296 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > In https://issues.apache.org/jira/browse/IGNITE-22108 I've proposed to use > --ms-node instead --meta-storage-node but it looks like this is > misleading/confusing for the user. > There is also --cmg-node option that does not self-explained. The proposal of > this issue is to rename --cmg-node to --cluster-management-group and > --meta-storage-node to --metastorage-group. > The second proposal is to use comma-separated list to define nodes. Here is > the example: > --cluster-management-group node1, node2, node3 --metastorage-group node3, > node5. > This means that we remove the support for repeating options, the following > command is not valid anymore: cluster init --cmg-node node1 --cmg-node node2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (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 resolved IGNITE-22244. Resolution: Cannot Reproduce Can not get this error on the latest main build. > 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 >Assignee: 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] [Assigned] (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 reassigned IGNITE-22244: -- Assignee: Aleksandr > 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 >Assignee: 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-22409) Fix README and Javadoc for eventlog
Aleksandr created IGNITE-22409: -- Summary: Fix README and Javadoc for eventlog Key: IGNITE-22409 URL: https://issues.apache.org/jira/browse/IGNITE-22409 Project: Ignite Issue Type: Improvement Reporter: Aleksandr After events are renamed, the README and javadoc should be fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22181) BigDecimal scale is lost during create table
[
https://issues.apache.org/jira/browse/IGNITE-22181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850639#comment-17850639
]
Aleksandr commented on IGNITE-22181:
[~vkolodin] thank you for the clarification.
It seems like the default scale (0) is the correct one and we have to specify
the scale and precision explicitly. [~jooger] looks like this is not an issue,
you can close it.
> 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
>Priority: Major
> Labels: ignite-3
>
> 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-22366) Create start scripts for windows
Aleksandr created IGNITE-22366: -- Summary: Create start scripts for windows Key: IGNITE-22366 URL: https://issues.apache.org/jira/browse/IGNITE-22366 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Both CLI and DB packages should be possible to start in Windows. Also, the readme file and devnotes should be updated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22365) Node status "starting" is confusing
Aleksandr created IGNITE-22365: -- Summary: Node status "starting" is confusing Key: IGNITE-22365 URL: https://issues.apache.org/jira/browse/IGNITE-22365 Project: Ignite Issue Type: Improvement Reporter: Aleksandr The "starting" does not reflect a real state of the node. Is it not started because what? Is it waiting for what? We should rethink the naming. ignite3 node status [..., starting] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22364) start script improvement
Aleksandr created IGNITE-22364: -- Summary: start script improvement Key: IGNITE-22364 URL: https://issues.apache.org/jira/browse/IGNITE-22364 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Starting ignite several times with the same configuration should not work but in does: ./bin/ignite3db start ./bin/ignite3db start ./bin/ignite3db start ./bin/ignite3db start -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22363) Format ignite-config.conf
Aleksandr created IGNITE-22363: -- Summary: Format ignite-config.conf Key: IGNITE-22363 URL: https://issues.apache.org/jira/browse/IGNITE-22363 Project: Ignite Issue Type: Improvement Reporter: Aleksandr By default, the formatting in ignite-config.conf file is not readable. At least, we have to put space around =. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22362) IGNITE_HOME should be described
Aleksandr created IGNITE-22362: -- Summary: IGNITE_HOME should be described Key: IGNITE-22362 URL: https://issues.apache.org/jira/browse/IGNITE-22362 Project: Ignite Issue Type: Improvement Reporter: Aleksandr I want to set working directory path without looking into the online doc. I have not found this parameter in config. Probably, we have to think about the first UX regarding IGNITE_HOME. What is that? Why should user set this? I would expect something like that on the first start: ./bin/ignite3db start > IGNITE_HOME is not set, would you like to set is to ()? > If you want to change the default path, go to -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22361) Add descriptions to ignite-config.conf
Aleksandr created IGNITE-22361: -- Summary: Add descriptions to ignite-config.conf Key: IGNITE-22361 URL: https://issues.apache.org/jira/browse/IGNITE-22361 Project: Ignite Issue Type: Improvement Reporter: Aleksandr etc/ignite-config.conf should contain comments that user can read and understand what is the configuration key responsible for. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22339) Ignite3 CLI: DEB and RPM packages have no CLI script inside
[
https://issues.apache.org/jira/browse/IGNITE-22339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-22339:
--
Assignee: Aleksandr
> Ignite3 CLI: DEB and RPM packages have no CLI script inside
> ---
>
> Key: IGNITE-22339
> URL: https://issues.apache.org/jira/browse/IGNITE-22339
> Project: Ignite
> Issue Type: Bug
> Components: build
>Reporter: Ivan Artiukhov
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
>
> Ignite3, rev. {{edae5218a68b8e7d2bcbd662c1613e8448ac9065}}
>
> Problem: both {{ignite3-cli_3.0.0~SNAPSHOT_all.deb}} and
> {{ignite3-cli-3.0.0~SNAPSHOT.noarch.rpm}} do not install a script to run CLI
> on a target machine.
> DEB on Debian 12 virtual machine:
> {noformat}
> vagrant@bookworm:~$ sudo apt install ./ignite3-cli_3.0.0~SNAPSHOT_all.deb
> ...
> vagrant@bookworm:~$ dpkg -L ignite3-cli
> /usr
> /usr/share
> /usr/share/bash-completion
> /usr/share/bash-completion/completions
> /usr/share/bash-completion/completions/ignite_completion.sh
> /usr/lib
> /usr/lib/ignite3
> /usr/lib/ignite3/ignite-cli-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/ignite-jdbc-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/ignite-client-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/ignite-client-common-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/ignite-binary-tuple-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/ignite-marshaller-common-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/ignite-metrics-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/ignite-catalog-dsl-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/ignite-configuration-api-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/ignite-core-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/tree-sitter-sql-gh-pages.jar
> /usr/lib/ignite3/tree-sitter-json-0.21.0.jar
> /usr/lib/ignite3/tree-sitter-0.22.5.jar
> /usr/lib/ignite3/fliptables-1.1.1.jar
> /usr/lib/ignite3/picocli-shell-jline3-4.7.5.jar
> /usr/lib/ignite3/progressbar-0.9.4.jar
> /usr/lib/ignite3/jline-3.26.1.jar
> /usr/lib/ignite3/jline-console-3.26.1.jar
> /usr/lib/ignite3/micronaut-validation-3.10.3.jar
> /usr/lib/ignite3/micronaut-picocli-4.4.0.jar
> /usr/lib/ignite3/micronaut-runtime-3.10.3.jar
> /usr/lib/ignite3/micronaut-jackson-databind-3.10.3.jar
> /usr/lib/ignite3/micronaut-jackson-core-3.10.3.jar
> /usr/lib/ignite3/micronaut-json-core-3.10.3.jar
> /usr/lib/ignite3/micronaut-http-3.10.3.jar
> /usr/lib/ignite3/micronaut-context-3.10.3.jar
> /usr/lib/ignite3/micronaut-aop-3.10.3.jar
> /usr/lib/ignite3/micronaut-inject-3.10.3.jar
> /usr/lib/ignite3/jansi-2.4.1.jar
> /usr/lib/ignite3/picocli-4.7.5.jar
> /usr/lib/ignite3/jackson-datatype-jdk8-2.15.0.jar
> /usr/lib/ignite3/jackson-datatype-jsr310-2.15.0.jar
> /usr/lib/ignite3/jackson-databind-2.17.1.jar
> /usr/lib/ignite3/config-1.4.3.jar
> /usr/lib/ignite3/slf4j-jdk14-2.0.13.jar
> /usr/lib/ignite3/gson-fire-1.9.0.jar
> /usr/lib/ignite3/gson-2.10.1.jar
> /usr/lib/ignite3/ignite-api-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/ignite-error-code-annotation-processor-3.0.0-SNAPSHOT.jar
> /usr/lib/ignite3/guava-33.2.0-jre.jar
> /usr/lib/ignite3/jsr305-3.0.2.jar
> /usr/lib/ignite3/logging-interceptor-4.12.0.jar
> /usr/lib/ignite3/okhttp-4.12.0.jar
> /usr/lib/ignite3/threetenbp-1.6.9.jar
> /usr/lib/ignite3/swagger-annotations-1.6.14.jar
> /usr/lib/ignite3/okio-3.6.0.jar
> /usr/lib/ignite3/okio-jvm-3.6.0.jar
> /usr/lib/ignite3/kotlin-stdlib-jdk8-1.9.10.jar
> /usr/lib/ignite3/kotlin-stdlib-jdk7-1.9.10.jar
> /usr/lib/ignite3/kotlin-stdlib-1.9.10.jar
> /usr/lib/ignite3/annotations-24.1.0.jar
> /usr/lib/ignite3/fastutil-core-8.5.13.jar
> /usr/lib/ignite3/msgpack-core-0.8.24.jar
> /usr/lib/ignite3/netty-handler-4.1.109.Final.jar
> /usr/lib/ignite3/netty-codec-4.1.109.Final.jar
> /usr/lib/ignite3/netty-transport-native-unix-common-4.1.109.Final.jar
> /usr/lib/ignite3/netty-transport-4.1.109.Final.jar
> /usr/lib/ignite3/netty-buffer-4.1.109.Final.jar
> /usr/lib/ignite3/netty-resolver-4.1.109.Final.jar
> /usr/lib/ignite3/netty-common-4.1.109.Final.jar
> /usr/lib/ignite3/auto-service-annotations-1.1.1.jar
> /usr/lib/ignite3/jline-builtins-3.26.1.jar
> /usr/lib/ignite3/jline-style-3.26.1.jar
> /usr/lib/ignite3/micronaut-core-reactive-3.10.3.jar
> /usr/lib/ignite3/micronaut-core-3.10.3.jar
> /usr/lib/ignite3/slf4j-api-2.0.13.jar
> /usr/lib/ignite3/javax.annotation-api-1.3.2.jar
> /usr/lib/ignite3/jakarta.inject-api-2.0.1.jar
> /usr/lib/ignite3/jakarta.annotation-api-2.1.1.jar
> /usr/lib/ignite3/snakeyaml-2.0.jar
> /usr/lib/ignite3/validation-api-2.0.1.Final.jar
> /usr/lib/ignite3/reactor-core-3.5.0.jar
> /usr/lib/ignite3/jackson-annotations-2.17.1.jar
> /usr/lib/ignite3/jackson-core-2.17.1.jar
> /usr/lib/ignite3/caffeine-3.0.4.jar
> /usr/lib/ignite3/jline-reader-3.26.1.jar
> /usr/lib/ignite3/jline-terminal-3.26.1.jar
> /usr/lib/ignite3/reactive-streams-1.0.4.jar
> /usr/lib/ignite3/j
[jira] [Assigned] (IGNITE-22300) Adjust EventType names in EventLog
[ https://issues.apache.org/jira/browse/IGNITE-22300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22300: -- Assignee: Aleksandr > Adjust EventType names in EventLog > -- > > Key: IGNITE-22300 > URL: https://issues.apache.org/jira/browse/IGNITE-22300 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > I propose to adjust the names of EventTypes for EventLog, here is updated > types: > USER_AUTHENTICATION_SUCCESS, > USER_AUTHENTICATION_FAILURE > CLIENT_CONNECTION_ESTABLISHED, > CLIENT_CONNECTION_CLOSED. > We have to do that because now there is an inconsistency in naming for types. > Also, there is no way to see if the user has failed the authentication. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22300) Adjust EventType names in EventLog
Aleksandr created IGNITE-22300: -- Summary: Adjust EventType names in EventLog Key: IGNITE-22300 URL: https://issues.apache.org/jira/browse/IGNITE-22300 Project: Ignite Issue Type: Improvement Components: security Reporter: Aleksandr I propose to adjust the names of EventTypes for EventLog, here is updated types: USER_AUTHENTICATION_SUCCESS, USER_AUTHENTICATION_FAILURE CLIENT_CONNECTION_ESTABLISHED, CLIENT_CONNECTION_CLOSED. We have to do that because now there is an inconsistency in naming for types. Also, there is no way to see if the user has failed the authentication. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22296) Normalize --cmg-node and --meta-storage-node options in CLI
Aleksandr created IGNITE-22296: -- Summary: Normalize --cmg-node and --meta-storage-node options in CLI Key: IGNITE-22296 URL: https://issues.apache.org/jira/browse/IGNITE-22296 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr In https://issues.apache.org/jira/browse/IGNITE-22108 I've proposed to use --ms-node instead --meta-storage-node but it looks like this is misleading/confusing for the user. There is also --cmg-node option that does not self-explained. The proposal of this issue is to rename --cmg-node to --cluster-management-group and --meta-storage-node to --metastorage-group. The second proposal is to use comma-separated list to define nodes. Here is the example: --cluster-management-group node1, node2, node3 --metastorage-group node3, node5. This means that we remove the support for repeating options, the following command is not valid anymore: cluster init --cmg-node node1 --cmg-node node2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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&focusedCommentId=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)
