[jira] [Resolved] (IGNITE-17305) IgniteExceptionHandlerTest.shouldHandleIgniteException fails after IGNITE-14931
[ https://issues.apache.org/jira/browse/IGNITE-17305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-17305. -- Resolution: Duplicate The fix was merged under IGNITE-17281 > IgniteExceptionHandlerTest.shouldHandleIgniteException fails after > IGNITE-14931 > --- > > Key: IGNITE-17305 > URL: https://issues.apache.org/jira/browse/IGNITE-17305 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Blocker > Labels: ignite-3 > > The root cause of the issue is that IGNITE-14931 introduced changes in the > format of ignite error messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17305) IgniteExceptionHandlerTest.shouldHandleIgniteException fails after IGNITE-14931
[ https://issues.apache.org/jira/browse/IGNITE-17305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17305: - Description: The root cause of the issue is that IGNITE-14931 introduced changes in the format of ignite error messages. > IgniteExceptionHandlerTest.shouldHandleIgniteException fails after > IGNITE-14931 > --- > > Key: IGNITE-17305 > URL: https://issues.apache.org/jira/browse/IGNITE-17305 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Blocker > Labels: ignite-3 > > The root cause of the issue is that IGNITE-14931 introduced changes in the > format of ignite error messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17130) Profilies support for CLI configuration
[
https://issues.apache.org/jira/browse/IGNITE-17130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563946#comment-17563946
]
Aleksandr commented on IGNITE-17130:
LGTM, thanks for the contribution.
> Profilies support for CLI configuration
> ---
>
> Key: IGNITE-17130
> URL: https://issues.apache.org/jira/browse/IGNITE-17130
> Project: Ignite
> Issue Type: New Feature
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> h3. Config file site:
> The Ignite CLI currently only has one set of properties. Need to support
> multiple profiles, this means that the config must have multiple sections for
> each user profile. INI format completely covers everything we need, so need
> migrate config file format from properties to ini.
> Default profile name [default].
> h3. CLI command site:
> Create profile command
> {code:java}
> ignite cli config profile create
> --name profile_name (REQUIRED)
> --copy-from profile-name (OPTIONAL)
> --activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
> Activate profile command as default profile
> {code:java}
> ignite cli config profile use profile_name {code}
> Read\write property with profile
> {code:java}
> ignite cli config --profile profile_name get\set propertyKey=propertyValue
> {code}
> Read current profile
> {code:java}
> ignite cli config profile show{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17337) Support limiting volatile RAFT log memory by total entries size
Roman Puchkovskiy created IGNITE-17337: -- Summary: Support limiting volatile RAFT log memory by total entries size Key: IGNITE-17337 URL: https://issues.apache.org/jira/browse/IGNITE-17337 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-alpha6 In IGNITE-17334, we'll build a simple volatile RAFT log storage. Here, we need to add ability to judge whether we can accept more entries to the in-memory region based on entries total size. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17336) Spill-out to disk support for volatile RAFT log storage
Roman Puchkovskiy created IGNITE-17336: -- Summary: Spill-out to disk support for volatile RAFT log storage Key: IGNITE-17336 URL: https://issues.apache.org/jira/browse/IGNITE-17336 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-alpha6 In IGNITE-16655, we'll build a simple volatile RAFT log storage. We need to have ability to spill out to disk if the in-memory log storage is completely filled. RocksDB can be used for this (or something different). Probably, some research is required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17335) Off-heap storage for RAFT log
Roman Puchkovskiy created IGNITE-17335: -- Summary: Off-heap storage for RAFT log Key: IGNITE-17335 URL: https://issues.apache.org/jira/browse/IGNITE-17335 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-alpha6 In IGNITE-17334, we'll build a volatile log storage using a simple on-heap data structure. We need to replace it with an off-heap structure (probably, using page memory) to avoid GC pressure. When using page memory, we could allocate a single region for all RAFT groups' log storages and allocate some memory budget to each RAFT group. The description is not too precise, some research is needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17334) Basic volatile RAFT log storage
Roman Puchkovskiy created IGNITE-17334: -- Summary: Basic volatile RAFT log storage Key: IGNITE-17334 URL: https://issues.apache.org/jira/browse/IGNITE-17334 Project: Ignite Issue Type: Improvement Components: persistence Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-alpha6 The storage should contain the following components: # An elastic (but with possible hard-limit) in-memory storage for log entries. On this iteration it will be on-heap data structure (for instance, a skip list). Later, we'll build something better (like an off-heap implementation, maybe using pagemem). # An algorithm for determining when the in-memory storage cannot accept new entries. On this iteration, the only supported algorithm will be simply limiting the store by the number of stored entries. Later we will add something smarter, like the total size of the stored entries and adaptive algorithms. # A policy for what to do if the store cannot accept a record. On this iteration, it will be just to reject the entry. Later, we can add support for spilling out to disk. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17006) Add protection against arbitrary page memory links in LinkRowId
[ https://issues.apache.org/jira/browse/IGNITE-17006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-17006. Resolution: Invalid Not valid anymore due to IGNITE-17076 > Add protection against arbitrary page memory links in LinkRowId > --- > > Key: IGNITE-17006 > URL: https://issues.apache.org/jira/browse/IGNITE-17006 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > It's theoretically possible to pass an arbitrary page memory link (via > LinkRowId) which might cause troubles: > # If pageId exceeds page memory limit, the JVM might crash > # If the page with this pageId was never initialized, an attempt to read > will fail with an internal assertion (because lock state will be 0) > A possibility for item ID to be invalid is already handled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16942) Open API support for REST (IEP-87)
[ https://issues.apache.org/jira/browse/IGNITE-16942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin updated IGNITE-16942: --- Epic Name: IEP-87 (Open API support for REST) (was: IEP-87) > Open API support for REST (IEP-87) > -- > > Key: IGNITE-16942 > URL: https://issues.apache.org/jira/browse/IGNITE-16942 > Project: Ignite > Issue Type: Epic > Components: rest >Reporter: Aleksandr >Priority: Major > Labels: ignite-3, rest > > REST endpoints provided by Ignite node should support Open API specification. > * micronaut is suggested as an implementation framework for REST > * generate Open API specification from source code > * new micronaut-based implementation has to include all existing endpoints -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17333) .NET: Thin 3.0: SQL ResultSet object mapping
[
https://issues.apache.org/jira/browse/IGNITE-17333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17333:
Description:
Table API provides object mapping capabilities:
{code:c#}
IRecordView mappedView = Table.GetRecordView();
Person res = await mappedView.GetAsync(...);
{code}
This is cleaner and more efficient than working with *IgniteTuple*s (less
allocations and type casts).
Implement similar functionality for SQL API - see *ISql.ExecuteAsync*.
was:
Table API provides object mapping capabilities:
{code:c#}
IRecordView mappedView = Table.GetRecordView();
Person res = await mappedView.GetAsync(...);
{code}
This is cleaner and more efficient than working with *IgniteTuple*s (less
allocations and type casts).
Implement similar functionality for SQL API - see *Task>
ExecuteAsync*.
> .NET: Thin 3.0: SQL ResultSet object mapping
>
>
> Key: IGNITE-17333
> URL: https://issues.apache.org/jira/browse/IGNITE-17333
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
>
> Table API provides object mapping capabilities:
> {code:c#}
> IRecordView mappedView = Table.GetRecordView();
> Person res = await mappedView.GetAsync(...);
> {code}
> This is cleaner and more efficient than working with *IgniteTuple*s (less
> allocations and type casts).
> Implement similar functionality for SQL API - see *ISql.ExecuteAsync*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17333) .NET: Thin 3.0: SQL ResultSet object mapping
[
https://issues.apache.org/jira/browse/IGNITE-17333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17333:
Description:
Table API provides object mapping capabilities:
{code:c#}
IRecordView mappedView = Table.GetRecordView();
Person res = await mappedView.GetAsync(...);
{code}
This is cleaner and more efficient than working with *IgniteTuple*s (less
allocations and type casts).
Implement similar functionality for SQL API - see *Task>
ExecuteAsync*.
was:
Table API provides object mapping capabilities:
{code:c#}
IRecordView mappedView = Table.GetRecordView();
Person res = await mappedView.GetAsync(...);
{code}
This is cleaner and more efficient than working with *IgniteTuple*s (less
allocations and type casts).
> .NET: Thin 3.0: SQL ResultSet object mapping
>
>
> Key: IGNITE-17333
> URL: https://issues.apache.org/jira/browse/IGNITE-17333
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
>
> Table API provides object mapping capabilities:
> {code:c#}
> IRecordView mappedView = Table.GetRecordView();
> Person res = await mappedView.GetAsync(...);
> {code}
> This is cleaner and more efficient than working with *IgniteTuple*s (less
> allocations and type casts).
> Implement similar functionality for SQL API - see *Task>
> ExecuteAsync*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17333) .NET: Thin 3.0: SQL ResultSet object mapping
[
https://issues.apache.org/jira/browse/IGNITE-17333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17333:
Description:
Table API provides object mapping capabilities:
{code:csharp}
IRecordView mappedView = Table.GetRecordView();
Person res = await mappedView.GetAsync(...);
{code}
This is cleaner and more efficient than working with *IgniteTuple*s (less
allocations and type casts).
> .NET: Thin 3.0: SQL ResultSet object mapping
>
>
> Key: IGNITE-17333
> URL: https://issues.apache.org/jira/browse/IGNITE-17333
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
>
> Table API provides object mapping capabilities:
> {code:csharp}
> IRecordView mappedView = Table.GetRecordView();
> Person res = await mappedView.GetAsync(...);
> {code}
> This is cleaner and more efficient than working with *IgniteTuple*s (less
> allocations and type casts).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17333) .NET: Thin 3.0: SQL ResultSet object mapping
[
https://issues.apache.org/jira/browse/IGNITE-17333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17333:
Description:
Table API provides object mapping capabilities:
{code:c#}
IRecordView mappedView = Table.GetRecordView();
Person res = await mappedView.GetAsync(...);
{code}
This is cleaner and more efficient than working with *IgniteTuple*s (less
allocations and type casts).
was:
Table API provides object mapping capabilities:
{code:csharp}
IRecordView mappedView = Table.GetRecordView();
Person res = await mappedView.GetAsync(...);
{code}
This is cleaner and more efficient than working with *IgniteTuple*s (less
allocations and type casts).
> .NET: Thin 3.0: SQL ResultSet object mapping
>
>
> Key: IGNITE-17333
> URL: https://issues.apache.org/jira/browse/IGNITE-17333
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
>
> Table API provides object mapping capabilities:
> {code:c#}
> IRecordView mappedView = Table.GetRecordView();
> Person res = await mappedView.GetAsync(...);
> {code}
> This is cleaner and more efficient than working with *IgniteTuple*s (less
> allocations and type casts).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17333) .NET: Thin 3.0: SQL ResultSet object mapping
Pavel Tupitsyn created IGNITE-17333: --- Summary: .NET: Thin 3.0: SQL ResultSet object mapping Key: IGNITE-17333 URL: https://issues.apache.org/jira/browse/IGNITE-17333 Project: Ignite Issue Type: Improvement Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17130) Profilies support for CLI configuration
[
https://issues.apache.org/jira/browse/IGNITE-17130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-17130:
---
Description:
h3. Config file site:
The Ignite CLI currently only has one set of properties. Need to support
multiple profiles, this means that the config must have multiple sections for
each user profile. INI format completely covers everything we need, so need
migrate config file format from properties to ini.
Default profile name [default].
h3. CLI command site:
Create profile command
{code:java}
ignite cli config profile create
--name profile_name (REQUIRED)
--copy-from profile-name (OPTIONAL)
--activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
Activate profile command as default profile
{code:java}
ignite cli config profile use profile_name {code}
Read\write property with profile
{code:java}
ignite cli config --profile profile_name get\set propertyKey=propertyValue
{code}
Read current profile
{code:java}
ignite cli config profile show{code}
was:
h3. Config file site:
The Ignite CLI currently only has one set of properties. Need to support
multiple profiles, this means that the config must have multiple sections for
each user profile. INI format completely covers everything we need, so need
migrate config file format from properties to ini.
Default profile name [default].
h3. CLI command site:
Create profile command
{code:java}
ignite cli config profile create
--name profile_name (REQUIRED)
--copy-from profile-name (OPTIONAL)
--activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
Activate profile command as default profile
{code:java}
ignite cli config profile use profile_name {code}
Read\write property with profile
{code:java}
ignite cli config --profile profile_name get\set propertyKey=propertyValue
{code}
Read current profile show
{code:java}
ignite cli config profile{code}
> Profilies support for CLI configuration
> ---
>
> Key: IGNITE-17130
> URL: https://issues.apache.org/jira/browse/IGNITE-17130
> Project: Ignite
> Issue Type: New Feature
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h3. Config file site:
> The Ignite CLI currently only has one set of properties. Need to support
> multiple profiles, this means that the config must have multiple sections for
> each user profile. INI format completely covers everything we need, so need
> migrate config file format from properties to ini.
> Default profile name [default].
> h3. CLI command site:
> Create profile command
> {code:java}
> ignite cli config profile create
> --name profile_name (REQUIRED)
> --copy-from profile-name (OPTIONAL)
> --activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
> Activate profile command as default profile
> {code:java}
> ignite cli config profile use profile_name {code}
> Read\write property with profile
> {code:java}
> ignite cli config --profile profile_name get\set propertyKey=propertyValue
> {code}
> Read current profile
> {code:java}
> ignite cli config profile show{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17130) Profilies support for CLI configuration
[
https://issues.apache.org/jira/browse/IGNITE-17130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-17130:
---
Description:
h3. Config file site:
The Ignite CLI currently only has one set of properties. Need to support
multiple profiles, this means that the config must have multiple sections for
each user profile. INI format completely covers everything we need, so need
migrate config file format from properties to ini.
Default profile name [default].
h3. CLI command site:
Create profile command
{code:java}
ignite cli config profile create
--name profile_name (REQUIRED)
--copy-from profile-name (OPTIONAL)
--activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
Activate profile command as default profile
{code:java}
ignite cli config profile use profile_name {code}
Read\write property with profile
{code:java}
ignite cli config --profile profile_name get\set propertyKey=propertyValue
{code}
Read current profile
{code:java}
ignite cli config profile{code}
was:
h3. Config file site:
The Ignite CLI currently only has one set of properties. Need to support
multiple profiles, this means that the config must have multiple sections for
each user profile. INI format completely covers everything we need, so need
migrate config file format from properties to ini.
Default profile name [default].
h3. CLI command site:
Create profile command
{code:java}
ignite cli config profile create
--name profile_name (REQUIRED)
--copy-from profile-name (OPTIONAL)
--activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
Activate profile command as default profile
{code:java}
ignite cli config use profile_name {code}
Read\write property with profile
{code:java}
ignite cli config --profile profile_name get\set propertyKey=propertyValue
{code}
Read current profile
{code:java}
ignite cli config profile{code}
> Profilies support for CLI configuration
> ---
>
> Key: IGNITE-17130
> URL: https://issues.apache.org/jira/browse/IGNITE-17130
> Project: Ignite
> Issue Type: New Feature
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h3. Config file site:
> The Ignite CLI currently only has one set of properties. Need to support
> multiple profiles, this means that the config must have multiple sections for
> each user profile. INI format completely covers everything we need, so need
> migrate config file format from properties to ini.
> Default profile name [default].
> h3. CLI command site:
> Create profile command
> {code:java}
> ignite cli config profile create
> --name profile_name (REQUIRED)
> --copy-from profile-name (OPTIONAL)
> --activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
> Activate profile command as default profile
> {code:java}
> ignite cli config profile use profile_name {code}
> Read\write property with profile
> {code:java}
> ignite cli config --profile profile_name get\set propertyKey=propertyValue
> {code}
> Read current profile
> {code:java}
> ignite cli config profile{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17130) Profilies support for CLI configuration
[
https://issues.apache.org/jira/browse/IGNITE-17130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-17130:
---
Description:
h3. Config file site:
The Ignite CLI currently only has one set of properties. Need to support
multiple profiles, this means that the config must have multiple sections for
each user profile. INI format completely covers everything we need, so need
migrate config file format from properties to ini.
Default profile name [default].
h3. CLI command site:
Create profile command
{code:java}
ignite cli config profile create
--name profile_name (REQUIRED)
--copy-from profile-name (OPTIONAL)
--activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
Activate profile command as default profile
{code:java}
ignite cli config profile use profile_name {code}
Read\write property with profile
{code:java}
ignite cli config --profile profile_name get\set propertyKey=propertyValue
{code}
Read current profile show
{code:java}
ignite cli config profile{code}
was:
h3. Config file site:
The Ignite CLI currently only has one set of properties. Need to support
multiple profiles, this means that the config must have multiple sections for
each user profile. INI format completely covers everything we need, so need
migrate config file format from properties to ini.
Default profile name [default].
h3. CLI command site:
Create profile command
{code:java}
ignite cli config profile create
--name profile_name (REQUIRED)
--copy-from profile-name (OPTIONAL)
--activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
Activate profile command as default profile
{code:java}
ignite cli config profile use profile_name {code}
Read\write property with profile
{code:java}
ignite cli config --profile profile_name get\set propertyKey=propertyValue
{code}
Read current profile
{code:java}
ignite cli config profile{code}
> Profilies support for CLI configuration
> ---
>
> Key: IGNITE-17130
> URL: https://issues.apache.org/jira/browse/IGNITE-17130
> Project: Ignite
> Issue Type: New Feature
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h3. Config file site:
> The Ignite CLI currently only has one set of properties. Need to support
> multiple profiles, this means that the config must have multiple sections for
> each user profile. INI format completely covers everything we need, so need
> migrate config file format from properties to ini.
> Default profile name [default].
> h3. CLI command site:
> Create profile command
> {code:java}
> ignite cli config profile create
> --name profile_name (REQUIRED)
> --copy-from profile-name (OPTIONAL)
> --activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
> Activate profile command as default profile
> {code:java}
> ignite cli config profile use profile_name {code}
> Read\write property with profile
> {code:java}
> ignite cli config --profile profile_name get\set propertyKey=propertyValue
> {code}
> Read current profile show
> {code:java}
> ignite cli config profile{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17130) Profilies support for CLI configuration
[
https://issues.apache.org/jira/browse/IGNITE-17130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-17130:
---
Description:
h3. Config file site:
The Ignite CLI currently only has one set of properties. Need to support
multiple profiles, this means that the config must have multiple sections for
each user profile. INI format completely covers everything we need, so need
migrate config file format from properties to ini.
Default profile name [default].
h3. CLI command site:
Create profile command
{code:java}
ignite cli config profile create
--name profile_name (REQUIRED)
--copy-from profile-name (OPTIONAL)
--activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
Activate profile command as default profile
{code:java}
ignite cli config use profile_name {code}
Read\write property with profile
{code:java}
ignite cli config --profile profile_name get\set propertyKey=propertyValue
{code}
Read current profile
{code:java}
ignite cli config profile{code}
was:
h3. Config file site:
The Ignite CLI currently only has one set of properties. Need to support
multiple profiles, this means that the config must have multiple sections for
each user profile. INI format completely covers everything we need, so need
migrate config file format from properties to ini.
Default profile name [default].
h3. CLI command site:
Create profile command
{code:java}
ignite cli config create-profile
--name profile_name (REQUIRED)
--copy-from profile-name (OPTIONAL)
--activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
Activate profile command as default profile
{code:java}
ignite cli config use profile_name {code}
Read\write property with profile
{code:java}
ignite cli config --profile profile_name get\set propertyKey=propertyValue
{code}
Read current profile
{code:java}
ignite cli config profile{code}
> Profilies support for CLI configuration
> ---
>
> Key: IGNITE-17130
> URL: https://issues.apache.org/jira/browse/IGNITE-17130
> Project: Ignite
> Issue Type: New Feature
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h3. Config file site:
> The Ignite CLI currently only has one set of properties. Need to support
> multiple profiles, this means that the config must have multiple sections for
> each user profile. INI format completely covers everything we need, so need
> migrate config file format from properties to ini.
> Default profile name [default].
> h3. CLI command site:
> Create profile command
> {code:java}
> ignite cli config profile create
> --name profile_name (REQUIRED)
> --copy-from profile-name (OPTIONAL)
> --activate true\false (OPTIONAL, DEFAULT VALUE = false){code}
> Activate profile command as default profile
> {code:java}
> ignite cli config use profile_name {code}
> Read\write property with profile
> {code:java}
> ignite cli config --profile profile_name get\set propertyKey=propertyValue
> {code}
> Read current profile
> {code:java}
> ignite cli config profile{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17296) .NET: Service call interceptor
[ https://issues.apache.org/jira/browse/IGNITE-17296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17296: Fix Version/s: 2.14 > .NET: Service call interceptor > -- > > Key: IGNITE-17296 > URL: https://issues.apache.org/jira/browse/IGNITE-17296 > Project: Ignite > Issue Type: Sub-task > Components: managed services, platforms >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: .NET, iep-79, ise > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement interceptor for .NET service. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17296) .NET: Service call interceptor
[ https://issues.apache.org/jira/browse/IGNITE-17296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17296: Component/s: platforms > .NET: Service call interceptor > -- > > Key: IGNITE-17296 > URL: https://issues.apache.org/jira/browse/IGNITE-17296 > Project: Ignite > Issue Type: Sub-task > Components: managed services, platforms >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: .NET, iep-79, ise > Time Spent: 10m > Remaining Estimate: 0h > > Implement interceptor for .NET service. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17269) Java service call interceptor
[
https://issues.apache.org/jira/browse/IGNITE-17269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563801#comment-17563801
]
Ignite TC Bot commented on IGNITE-17269:
{panel:title=Branch: [pull/10128/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10128/head] Base: [master] : New Tests
(9)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [[tests
9|https://ci2.ignite.apache.org/viewLog.html?buildId=6510509]]
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testOrder[clusterSingleton=false,
sticky=false] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testException[clusterSingleton=false,
sticky=false] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testOrder[clusterSingleton=true, sticky=true]
- PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testException[clusterSingleton=true,
sticky=true] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testOrder[clusterSingleton=false, sticky=true]
- PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testException[clusterSingleton=false,
sticky=true] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testRedeploy[clusterSingleton=true,
sticky=true] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testRedeploy[clusterSingleton=false,
sticky=true] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testRedeploy[clusterSingleton=false,
sticky=false] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6510505buildTypeId=IgniteTests24Java8_RunAll]
> Java service call interceptor
> -
>
> Key: IGNITE-17269
> URL: https://issues.apache.org/jira/browse/IGNITE-17269
> Project: Ignite
> Issue Type: Sub-task
> Components: managed services
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-79, ise
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement interceptor for java service.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17327) Add automatic code checks - RedundantTypeCast and Write-only object
[ https://issues.apache.org/jira/browse/IGNITE-17327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-17327: Assignee: (was: Nikolay Izhikov) > Add automatic code checks - RedundantTypeCast and Write-only object > --- > > Key: IGNITE-17327 > URL: https://issues.apache.org/jira/browse/IGNITE-17327 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Minor > > Currently, there are some dead code in Ignite which can be eliminated by > automatic IDE and TC checks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17062) Add ability to process local events asynchronously
[
https://issues.apache.org/jira/browse/IGNITE-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563770#comment-17563770
]
Vladislav Pyatkov commented on IGNITE-17062:
Merged dac5eea8a7e068e70759f21dc180b595c9b7038d
[~Denis Chudov] Thank you for the contribution
> Add ability to process local events asynchronously
> --
>
> Key: IGNITE-17062
> URL: https://issues.apache.org/jira/browse/IGNITE-17062
> Project: Ignite
> Issue Type: Task
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Local events (org.apache.ignite.internal.manager.Event) logic should be
> reworked a bit in order to await all subscribers to process corresponding
> event before publishing the action. Let's check an example of an expected
> behavior:
> # TableManager prepares table for creation.
> # TableManager notifies all subscribers with Table.CREATE event propagating
> to-be-created table.
> # TableManager (with the help of
> org.apache.ignite.internal.manager.Producer) awaits all subscribers to
> acknowledge that Table.CREATE event was successfully processed. E.g.
> SqlQueryProcessor prepares calcite schemes and sends ack by completing
> event's Future like it's done within ConfigurationRegistry events.
> # TableManager on Compound-Like-Future.allOff(events) publishes
> corresponding action, e.g. makes table visible to everyone.
> Proposed solution is very similar to what we already have in
> ConfigurationRegistry
> {code:java}
> public interface ConfigurationListener {
> /**
> * Called on property value update.
> *
> * @param ctx Notification context.
> * @return Future that signifies the end of the listener execution.
> */
> CompletableFuture onUpdate(ConfigurationNotificationEvent ctx);
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17062) Add ability to process local events asynchronously
[
https://issues.apache.org/jira/browse/IGNITE-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17062:
---
Summary: Add ability to process local events asynchronously (was: Add
ability to process local events synchronously)
> Add ability to process local events asynchronously
> --
>
> Key: IGNITE-17062
> URL: https://issues.apache.org/jira/browse/IGNITE-17062
> Project: Ignite
> Issue Type: Task
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Local events (org.apache.ignite.internal.manager.Event) logic should be
> reworked a bit in order to await all subscribers to process corresponding
> event before publishing the action. Let's check an example of an expected
> behavior:
> # TableManager prepares table for creation.
> # TableManager notifies all subscribers with Table.CREATE event propagating
> to-be-created table.
> # TableManager (with the help of
> org.apache.ignite.internal.manager.Producer) awaits all subscribers to
> acknowledge that Table.CREATE event was successfully processed. E.g.
> SqlQueryProcessor prepares calcite schemes and sends ack by completing
> event's Future like it's done within ConfigurationRegistry events.
> # TableManager on Compound-Like-Future.allOff(events) publishes
> corresponding action, e.g. makes table visible to everyone.
> Proposed solution is very similar to what we already have in
> ConfigurationRegistry
> {code:java}
> public interface ConfigurationListener {
> /**
> * Called on property value update.
> *
> * @param ctx Notification context.
> * @return Future that signifies the end of the listener execution.
> */
> CompletableFuture onUpdate(ConfigurationNotificationEvent ctx);
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17062) Add ability to process local events synchronously
[
https://issues.apache.org/jira/browse/IGNITE-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563762#comment-17563762
]
Vladislav Pyatkov commented on IGNITE-17062:
LGTM
> Add ability to process local events synchronously
> -
>
> Key: IGNITE-17062
> URL: https://issues.apache.org/jira/browse/IGNITE-17062
> Project: Ignite
> Issue Type: Task
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Local events (org.apache.ignite.internal.manager.Event) logic should be
> reworked a bit in order to await all subscribers to process corresponding
> event before publishing the action. Let's check an example of an expected
> behavior:
> # TableManager prepares table for creation.
> # TableManager notifies all subscribers with Table.CREATE event propagating
> to-be-created table.
> # TableManager (with the help of
> org.apache.ignite.internal.manager.Producer) awaits all subscribers to
> acknowledge that Table.CREATE event was successfully processed. E.g.
> SqlQueryProcessor prepares calcite schemes and sends ack by completing
> event's Future like it's done within ConfigurationRegistry events.
> # TableManager on Compound-Like-Future.allOff(events) publishes
> corresponding action, e.g. makes table visible to everyone.
> Proposed solution is very similar to what we already have in
> ConfigurationRegistry
> {code:java}
> public interface ConfigurationListener {
> /**
> * Called on property value update.
> *
> * @param ctx Notification context.
> * @return Future that signifies the end of the listener execution.
> */
> CompletableFuture onUpdate(ConfigurationNotificationEvent ctx);
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17285) Ambiguous output of INDEXES SytemView if cache is created via DDL
[
https://issues.apache.org/jira/browse/IGNITE-17285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563744#comment-17563744
]
Yury Gerzhedovich commented on IGNITE-17285:
Aleksey is right. Aditionaly could say that duplication issue is known issue -
IGNITE-11125
> Ambiguous output of INDEXES SytemView if cache is created via DDL
> --
>
> Key: IGNITE-17285
> URL: https://issues.apache.org/jira/browse/IGNITE-17285
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Attachments: SqlIndexSystemViewReproducerTest.patch,
> create_table.txt, query_entity.txt
>
>
> There is a difference in 'COLUMNS ' and 'INLINE_SIZE' columns content in
> system view 'INDEXES', when you create SQL-cache by means of QueryEntity and
> by means of DDL.
> As you can see in reproducer [^SqlIndexSystemViewReproducerTest.patch] ,
> there are two "equal" attepmts to create cache: via DDL, and via Cache API +
> QueryEntity.
> Primary keys contains equal set of fields, affinity fields are the same.
> Outputs of system views TABLES, TABLE_COLUMNS and BINARY_METADATA are the
> same for both ways of cache creation. Table content (i.e. select *) is also
> the same, if you do not take into account the order of output.
> There are example sqlline outputs for table from reproducer:
> # [^create_table.txt] - for table, created by DDL.
> # [^query_entity.txt] - for table, created by Cache API.
> As you can see, colums and content differs in INDEXES view: in case of DDL,
> indexes does not have '_KEY' column, and have explicit set of columns from
> primary key. Also, there is a duplication of affinity column 'ID' for :
> {code}
> "ID" ASC, "FIRSTNAME" ASC, "LASTNAME" ASC, "ID" ASC
> {code}
> In case of creation table via Cache API + QueryEntity, no exlicit primary key
> columns are shown, but '_KEY' column is, and there is no duplication of
> affinity column 'ID' in '_key_PK_hash' index.
> Reproducer dumps indexes ({{org.h2.index.Index}}) collection content, which
> is obtained from {{GridH2Table#getIndexes}}. It seems, that information
> differs in this class too.
> Example output:
> {code:java|title=Cache API + QueryEntity}
> Index name Columns
> _key_PK__SCAN_ [_KEY, ID]
> _key_PK_hash [_KEY, ID]
> _key_PK [_KEY, ID]
> AFFINITY_KEY [ID, _KEY]
> PERSONINFO_CITYNAME_IDX [CITYNAME, _KEY, ID]
> {code}
> {code:java|title=DDL}
> Index name Columns
> _key_PK__SCAN_ [ID, FIRSTNAME, LASTNAME]
> _key_PK_hash [_KEY, ID]
> _key_PK [ID, FIRSTNAME, LASTNAME]
> AFFINITY_KEY [ID, FIRSTNAME, LASTNAME]
> PERSONINFO_CITYNAME_IDX [CITYNAME, ID, FIRSTNAME, LASTNAME]
> {code}
> If such difference is not a bug, it should be documented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17332) Smart SQL node mapping based on safetime on replicas
[ https://issues.apache.org/jira/browse/IGNITE-17332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17332: --- Component/s: sql > Smart SQL node mapping based on safetime on replicas > > > Key: IGNITE-17332 > URL: https://issues.apache.org/jira/browse/IGNITE-17332 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > After implementing IGNITE-17263 we can mapping to node with data replica -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17332) Smart SQL node mapping based on safetime on replicas
Yury Gerzhedovich created IGNITE-17332: -- Summary: Smart SQL node mapping based on safetime on replicas Key: IGNITE-17332 URL: https://issues.apache.org/jira/browse/IGNITE-17332 Project: Ignite Issue Type: Improvement Reporter: Yury Gerzhedovich After implementing IGNITE-17263 we can mapping to node with data replica -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17331) Smart transaction exception handling for SQL
Yury Gerzhedovich created IGNITE-17331: -- Summary: Smart transaction exception handling for SQL Key: IGNITE-17331 URL: https://issues.apache.org/jira/browse/IGNITE-17331 Project: Ignite Issue Type: Improvement Reporter: Yury Gerzhedovich After implementing IGNITE-17329 we have just abort transaction and SQL execution in case of any error. Let's investigate for which cases possible retry execute whole query or just a fragments behind the scene and don't notify user about a issue. As result of the task should be banch of tickets with description possible cases and ways to implement the retries logic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17330) Support RO TX by SQL
[ https://issues.apache.org/jira/browse/IGNITE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17330: --- Summary: Support RO TX by SQL (was: support RO TX by SQL) > Support RO TX by SQL > > > Key: IGNITE-17330 > URL: https://issues.apache.org/jira/browse/IGNITE-17330 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > After implementing IGNITE-17260 we should add support RO transaction for SQL > queries. Seems required just use transaction method with timestamp as > parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17330) support RO TX by SQL
Yury Gerzhedovich created IGNITE-17330: -- Summary: support RO TX by SQL Key: IGNITE-17330 URL: https://issues.apache.org/jira/browse/IGNITE-17330 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich After implementing IGNITE-17260 we should add support RO transaction for SQL queries. Seems required just use transaction method with timestamp as parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17329) Transaction exception handling for SQL
[ https://issues.apache.org/jira/browse/IGNITE-17329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17329: --- Summary: Transaction exception handling for SQL (was: transaction exception handling for SQL) > Transaction exception handling for SQL > -- > > Key: IGNITE-17329 > URL: https://issues.apache.org/jira/browse/IGNITE-17329 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's implement simple version of transaction exception handling for SQL > execution - just a abort a transaction and stop execution. It's not a good > and final solution, but enought for start. As a next step (in a separate > ticket) we should think out cases which could be retried without of aborting > a transaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17329) transaction exception handling for SQL
Yury Gerzhedovich created IGNITE-17329: -- Summary: transaction exception handling for SQL Key: IGNITE-17329 URL: https://issues.apache.org/jira/browse/IGNITE-17329 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich Let's implement simple version of transaction exception handling for SQL execution - just a abort a transaction and stop execution. It's not a good and final solution, but enought for start. As a next step (in a separate ticket) we should think out cases which could be retried without of aborting a transaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17328) Start/stop implicit TX from SQL
Yury Gerzhedovich created IGNITE-17328: -- Summary: Start/stop implicit TX from SQL Key: IGNITE-17328 URL: https://issues.apache.org/jira/browse/IGNITE-17328 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich All SQL queries should be executed transactionally, so it required implement implicit start/stop transactions in case of transaction is not active. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17301) Need to bound RAFT lease intervals by the HLC range
[ https://issues.apache.org/jira/browse/IGNITE-17301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17301: - Labels: ignite-3 transaction3_recovery (was: ignite-3 transaction3_ro) > Need to bound RAFT lease intervals by the HLC range > --- > > Key: IGNITE-17301 > URL: https://issues.apache.org/jira/browse/IGNITE-17301 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_recovery > > Need to bound RAFT lease intervals by the HLC range -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17222) Need to propagate HLC with transaction protocol events
[ https://issues.apache.org/jira/browse/IGNITE-17222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17222: --- Description: One of source of HLC sync is a transaction protocol. Each ReplicaRequest и ReplicaResponse should carry the sender’s HLC and updates receiver HLC according to rules. (was: One of source of HLC sync is a transaction protocol. Each ReplicaRequest и ReplicaResponse involved in the execution of the transaction carries the sender’s HLC and updates receiver HLC according to rules.) > Need to propagate HLC with transaction protocol events > -- > > Key: IGNITE-17222 > URL: https://issues.apache.org/jira/browse/IGNITE-17222 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_ro > > One of source of HLC sync is a transaction protocol. Each ReplicaRequest и > ReplicaResponse should carry the sender’s HLC and updates receiver HLC > according to rules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17222) Need to propagate HLC with transaction protocol events
[ https://issues.apache.org/jira/browse/IGNITE-17222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17222: --- Description: One of source of HLC sync is a transaction protocol. Each ReplicaRequest и ReplicaResponse involved in the execution of the transaction carries the sender’s HLC and updates receiver HLC according to rules. (was: One of source of HLC sync is a transaction protocol. Each message involved in the execution of the transaction carries the sender’s HLC and updates receiver HLC according to rules.) > Need to propagate HLC with transaction protocol events > -- > > Key: IGNITE-17222 > URL: https://issues.apache.org/jira/browse/IGNITE-17222 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_ro > > One of source of HLC sync is a transaction protocol. Each ReplicaRequest и > ReplicaResponse involved in the execution of the transaction carries the > sender’s HLC and updates receiver HLC according to rules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17327) Add automatic code checks - RedundantTypeCast and Write-only object
[ https://issues.apache.org/jira/browse/IGNITE-17327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-17327: - Summary: Add automatic code checks - RedundantTypeCast and Write-only object (was: Add automatic code check - RedundantTypeCast and Write-only object) > Add automatic code checks - RedundantTypeCast and Write-only object > --- > > Key: IGNITE-17327 > URL: https://issues.apache.org/jira/browse/IGNITE-17327 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Minor > > Currently, there are some dead code in Ignite which can be eliminated by > automatic IDE and TC checks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17327) Add automatic code check - RedundantTypeCast and Write-only object
Nikolay Izhikov created IGNITE-17327: Summary: Add automatic code check - RedundantTypeCast and Write-only object Key: IGNITE-17327 URL: https://issues.apache.org/jira/browse/IGNITE-17327 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Currently, there are some dead code in Ignite which can be eliminated by automatic IDE and TC checks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17326) Update Ignite dependency: Spring
[ https://issues.apache.org/jira/browse/IGNITE-17326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17326: --- Fix Version/s: 2.14 > Update Ignite dependency: Spring > > > Key: IGNITE-17326 > URL: https://issues.apache.org/jira/browse/IGNITE-17326 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.14 > > > Update Ignite dependency Spring 5.2.21.RELEASE to 5.2.22.RELEASE -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17326) Update Ignite dependency: Spring
Aleksandr created IGNITE-17326: -- Summary: Update Ignite dependency: Spring Key: IGNITE-17326 URL: https://issues.apache.org/jira/browse/IGNITE-17326 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Assignee: Aleksandr Update Ignite dependency Spring 5.2.21.RELEASE to 5.2.22.RELEASE -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17006) Add protection against arbitrary page memory links in LinkRowId
[ https://issues.apache.org/jira/browse/IGNITE-17006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563653#comment-17563653 ] Ivan Bessonov commented on IGNITE-17006: Given that LinkRowId won't be a thing soon, I propose closing this issue . See IGNITE-17076 > Add protection against arbitrary page memory links in LinkRowId > --- > > Key: IGNITE-17006 > URL: https://issues.apache.org/jira/browse/IGNITE-17006 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > It's theoretically possible to pass an arbitrary page memory link (via > LinkRowId) which might cause troubles: > # If pageId exceeds page memory limit, the JVM might crash > # If the page with this pageId was never initialized, an attempt to read > will fail with an internal assertion (because lock state will be 0) > A possibility for item ID to be invalid is already handled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17311) KafkaToIgniteLoader instantiates several Spring contexts
[
https://issues.apache.org/jira/browse/IGNITE-17311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563651#comment-17563651
]
Ignite TC Bot commented on IGNITE-17311:
{panel:title=Branch: [pull/10139/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Snapshots{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6671382]]
* IgniteSnapshotTestSuite:
IgniteClusterSnapshotRestoreSelfTest.testStartClusterSnapshotRestoreMultipleThreadsDiffNode[Encryption=false]
- Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10139/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6669919buildTypeId=IgniteTests24Java8_RunAll]
> KafkaToIgniteLoader instantiates several Spring contexts
>
>
> Key: IGNITE-17311
> URL: https://issues.apache.org/jira/browse/IGNITE-17311
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-59
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> KafkaToIgniteLoader instantiates two SpringApplicationContext during app
> start.
> This can lead to error in case other beans inside context not designed for
> this case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16757) Add cache create/destroy events to CDCConsumer
[
https://issues.apache.org/jira/browse/IGNITE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-16757:
-
Fix Version/s: 2.14
> Add cache create/destroy events to CDCConsumer
> --
>
> Key: IGNITE-16757
> URL: https://issues.apache.org/jira/browse/IGNITE-16757
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
> Fix For: 2.14
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Need to provide the way to notify {{CDCConsumer}} about creation/destroying
> caches(tables).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-16757) Add cache create/destroy events to CDCConsumer
[
https://issues.apache.org/jira/browse/IGNITE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563645#comment-17563645
]
Ignite TC Bot commented on IGNITE-16757:
{panel:title=Branch: [pull/9948/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9948/head] Base: [master] : New Tests
(18)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=6508819]]
* {color:#013220}IgnitePdsTestSuite2:
CdcCacheConfigOnRestartTest.testPersistenceNotClearedOnRestart - PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcCacheConfigOnRestartTest.testInMemoryCdcClearedOnRestart - PASSED{color}
{color:#8b}Queries 3 (lazy=true){color} [[tests
8|https://ci2.ignite.apache.org/viewLog.html?buildId=6510243]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
CacheEventsCdcTest.testCreateTableForExistingCache[persistence=true] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
CacheEventsCdcTest.testCreateDestroyCache[persistence=true] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
CacheEventsCdcTest.testCreateDropSQLTable[persistence=true] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
CacheEventsCdcTest.testCreateDropSQLTable[persistence=false] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
CacheEventsCdcTest.testCreateTableForExistingCache[persistence=false] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
CacheEventsCdcTest.testCreateDestroyCache[persistence=false] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
CacheEventsCdcTest.testCreateDestroyCachesInGroup[persistence=true] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
CacheEventsCdcTest.testCreateDestroyCachesInGroup[persistence=false] -
PASSED{color}
{color:#8b}Queries 3{color} [[tests
8|https://ci2.ignite.apache.org/viewLog.html?buildId=6510241]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
CacheEventsCdcTest.testCreateTableForExistingCache[persistence=true] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
CacheEventsCdcTest.testCreateDestroyCache[persistence=true] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
CacheEventsCdcTest.testCreateTableForExistingCache[persistence=false] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
CacheEventsCdcTest.testCreateDestroyCache[persistence=false] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
CacheEventsCdcTest.testCreateDestroyCachesInGroup[persistence=true] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
CacheEventsCdcTest.testCreateDropSQLTable[persistence=true] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
CacheEventsCdcTest.testCreateDestroyCachesInGroup[persistence=false] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
CacheEventsCdcTest.testCreateDropSQLTable[persistence=false] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6508864buildTypeId=IgniteTests24Java8_RunAll]
> Add cache create/destroy events to CDCConsumer
> --
>
> Key: IGNITE-16757
> URL: https://issues.apache.org/jira/browse/IGNITE-16757
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Need to provide the way to notify {{CDCConsumer}} about creation/destroying
> caches(tables).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17322) [ducktests] Add ability to configure more options for ignite nodes
[ https://issues.apache.org/jira/browse/IGNITE-17322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563641#comment-17563641 ] Sergey Korotkov commented on IGNITE-17322: -- [~nizhikov] would you please review? > [ducktests] Add ability to configure more options for ignite nodes > -- > > Key: IGNITE-17322 > URL: https://issues.apache.org/jira/browse/IGNITE-17322 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Time Spent: 10m > Remaining Estimate: 0h > > Add more options to configure in IgniteConfiguration. Inparticular cache > templates, affinity, transaction options, and more individual options. > XML config file generation refactored a little bit for some beans to reduce > code duplication (snake case names of python config classes converted > automatically to camel case to be inserted to XML ignite config. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17322) [ducktests] Add ability to configure more options for ignite nodes
[ https://issues.apache.org/jira/browse/IGNITE-17322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-17322: - Description: Add more options to configure in IgniteConfiguration. Inparticular cache templates, affinity, transaction options, and more individual options. XML config file generation refactored a little bit for some beans to reduce code duplication (snake case names of python config classes converted automatically to camel case to be inserted to XML ignite config. > [ducktests] Add ability to configure more options for ignite nodes > -- > > Key: IGNITE-17322 > URL: https://issues.apache.org/jira/browse/IGNITE-17322 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Time Spent: 10m > Remaining Estimate: 0h > > Add more options to configure in IgniteConfiguration. Inparticular cache > templates, affinity, transaction options, and more individual options. > XML config file generation refactored a little bit for some beans to reduce > code duplication (snake case names of python config classes converted > automatically to camel case to be inserted to XML ignite config. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17325) Consider in-place compare for BinaryTuple comparator
Ivan Bessonov created IGNITE-17325: -- Summary: Consider in-place compare for BinaryTuple comparator Key: IGNITE-17325 URL: https://issues.apache.org/jira/browse/IGNITE-17325 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov We should be able to compare columns in IGNITE-17318 / IGNITE-17320 without deserializing them. This includes String, BigInteger, BigDecimal, BitMap and maybe other types that I forgot about -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-16665) [Native Persistence 3.0] Move the group ID to the configuration
[ https://issues.apache.org/jira/browse/IGNITE-16665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563639#comment-17563639 ] Kirill Tkalenko commented on IGNITE-16665: -- [~ibessonov] I was in a hurry, I did not manage to make the correct description and title, I will fix it soon. > [Native Persistence 3.0] Move the group ID to the configuration > --- > > Key: IGNITE-16665 > URL: https://issues.apache.org/jira/browse/IGNITE-16665 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Problem: > Currently, persistent storage engines such as *PageMemory* and *RocksDB* use > the > *org.apache.ignite.configuration.schemas.table.TableConfigurationSchema#name* > (as part or all) as the name for the directory in which the data will be > stored. This does not allow you to rename the table correctly, since the data > will have to be in the new directory so that it is not lost after restarting > the node, but it will be in the directory with the old name. > Possible solution: > Do not use the name of the table as the directory name, instead add the > *org.apache.ignite.configuration.schemas.table.TableConfigurationSchema#id* > which should never change, and must also be unique. > Please see: > * *org.apache.ignite.internal.storage.StorageUtils#groupId* > * > *org.apache.ignite.internal.storage.pagememory.PersistentPageMemoryTableStorage#start* > * > *org.apache.ignite.internal.storage.rocksdb.RocksDbStorageEngine#createTable* > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-16665) [Native Persistence 3.0] Move the group ID to the configuration
[ https://issues.apache.org/jira/browse/IGNITE-16665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563636#comment-17563636 ] Ivan Bessonov commented on IGNITE-16665: I'm sorry, but this description has nothing to do with groupId. Is this intentional? > [Native Persistence 3.0] Move the group ID to the configuration > --- > > Key: IGNITE-16665 > URL: https://issues.apache.org/jira/browse/IGNITE-16665 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Problem: > Currently, persistent storage engines such as *PageMemory* and *RocksDB* use > the > *org.apache.ignite.configuration.schemas.table.TableConfigurationSchema#name* > (as part or all) as the name for the directory in which the data will be > stored. This does not allow you to rename the table correctly, since the data > will have to be in the new directory so that it is not lost after restarting > the node, but it will be in the directory with the old name. > Possible solution: > Do not use the name of the table as the directory name, instead add the > *org.apache.ignite.configuration.schemas.table.TableConfigurationSchema#id* > which should never change, and must also be unique. > Please see: > * *org.apache.ignite.internal.storage.StorageUtils#groupId* > * > *org.apache.ignite.internal.storage.pagememory.PersistentPageMemoryTableStorage#start* > * > *org.apache.ignite.internal.storage.rocksdb.RocksDbStorageEngine#createTable* > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17267) Preparing a checkpoint for a DeltaFilePageStore
[ https://issues.apache.org/jira/browse/IGNITE-17267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563624#comment-17563624 ] Vladislav Pyatkov commented on IGNITE-17267: [~ktkale...@gridgain.com] I merged the path f79bd4f3edac372962a3f43e414b8338c596d682 Thank you for the contribution. > Preparing a checkpoint for a DeltaFilePageStore > --- > > Key: IGNITE-17267 > URL: https://issues.apache.org/jira/browse/IGNITE-17267 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 5h > Remaining Estimate: 0h > > To implement the *DeltaFilePageStore*, we need to prepare a checkpoint for > their creation. > What should be done: > # Sort dirty pages (*FullPageId*) by *groupId*, *partitionId*, *pageIdx*; > # In several threads, write dirty pages in batches for each partition and > know the number of these pages. > What can we look at: > * > *org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointWorkflow#beginCheckpoint* > * > *org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointWorkflow#splitAndSortCheckpointPagesIfNeeded* > * > *org.apache.ignite.internal.pagememory.persistence.checkpoint.Checkpointer#writePages* > Some implementation notes: > * We can replace *CheckpointWorkflow#parallelSortThreshold* with a constant > at 40k, according to the > [paper|https://www.researchgate.net/publication/331742843_Threshold_Analysis_and_Comparison_of_Sequential_and_Parallel_Divide_and_Conquer_Sorting_Algorithms]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17203) SQL API: Implement scale and precision metadata
[ https://issues.apache.org/jira/browse/IGNITE-17203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563617#comment-17563617 ] Konstantin Orlov commented on IGNITE-17203: --- [~amashenkov], LGTM! > SQL API: Implement scale and precision metadata > --- > > Key: IGNITE-17203 > URL: https://issues.apache.org/jira/browse/IGNITE-17203 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 2h > Remaining Estimate: 0h > > *scale()* and *precision()* in *ColumnMetadata* interface return incorrect > values. Implement them properly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-13412) Publish nightly snapshot in apache repository
[ https://issues.apache.org/jira/browse/IGNITE-13412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov resolved IGNITE-13412. -- Resolution: Duplicate > Publish nightly snapshot in apache repository > -- > > Key: IGNITE-13412 > URL: https://issues.apache.org/jira/browse/IGNITE-13412 > Project: Ignite > Issue Type: Improvement > Components: streaming >Reporter: Saikat Maitra >Priority: Major > > > We used to publish nightly packages earlier in the apache snapshot repository > but we are no longer publishing the packages. > > [https://repository.apache.org/content/repositories/snapshots/org/apache/ignite/ignite-core/] > > The last published package was > [2.2.2-SNAPSHOT/|https://repository.apache.org/content/repositories/snapshots/org/apache/ignite/ignite-core/2.2.2-SNAPSHOT/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-13570) Migrate OSGI module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-13570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563612#comment-17563612 ] Maxim Muzafarov commented on IGNITE-13570: -- [~agoncharuk] I've assigned this issue to myselft. Please, let me know if you'd like to continue working on this issue. > Migrate OSGI module to ignite-extensions > > > Key: IGNITE-13570 > URL: https://issues.apache.org/jira/browse/IGNITE-13570 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > > Migrate OSGI module to ignite-extensions > https://github.com/apache/ignite-extensions > Details: > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-13570) Migrate OSGI module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-13570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned IGNITE-13570: Assignee: Maxim Muzafarov (was: Alexey Goncharuk) > Migrate OSGI module to ignite-extensions > > > Key: IGNITE-13570 > URL: https://issues.apache.org/jira/browse/IGNITE-13570 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > > Migrate OSGI module to ignite-extensions > https://github.com/apache/ignite-extensions > Details: > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17324) Update Ignite dependency: Lucene
Aleksandr created IGNITE-17324: -- Summary: Update Ignite dependency: Lucene Key: IGNITE-17324 URL: https://issues.apache.org/jira/browse/IGNITE-17324 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Assignee: Aleksandr Update Lucene dependency 7.4.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17324) Update Ignite dependency: Lucene
[ https://issues.apache.org/jira/browse/IGNITE-17324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17324: --- Fix Version/s: 2.14 > Update Ignite dependency: Lucene > > > Key: IGNITE-17324 > URL: https://issues.apache.org/jira/browse/IGNITE-17324 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Minor > Fix For: 2.14 > > > Update Lucene dependency 7.4.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17323) Update Ignite dependency: Jetty
[ https://issues.apache.org/jira/browse/IGNITE-17323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17323: --- Fix Version/s: 2.14 > Update Ignite dependency: Jetty > --- > > Key: IGNITE-17323 > URL: https://issues.apache.org/jira/browse/IGNITE-17323 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.14 > > > Update Jetty dependency 9.4.39.v20210325 to 9.4.48.v20220622 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17323) Update Ignite dependency: Jetty
Aleksandr created IGNITE-17323: -- Summary: Update Ignite dependency: Jetty Key: IGNITE-17323 URL: https://issues.apache.org/jira/browse/IGNITE-17323 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Assignee: Aleksandr Update Jetty dependency 9.4.39.v20210325 to 9.4.48.v20220622 -- This message was sent by Atlassian Jira (v8.20.10#820010)
