[jira] [Assigned] (IGNITE-20858) Compute error handling
[ https://issues.apache.org/jira/browse/IGNITE-20858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-20858: -- Assignee: Ivan Gagarkin > Compute error handling > -- > > Key: IGNITE-20858 > URL: https://issues.apache.org/jira/browse/IGNITE-20858 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Igor Sapego >Assignee: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Make sure that compute follows AI3 Error Handling rules, defined in > IGNITE-14611. More specifically: > - We should never throw to user anything that is not IgniteException, > IgniteCheckedException or a public class derived from one of them; > - Make sure exceptions thrown by a user code are wrapped by IgniteException > and have a meaningful message. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21297) Altering the table causes the record API to break
[
https://issues.apache.org/jira/browse/IGNITE-21297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-21297:
---
Description:
*Steps to Reproduce:*
# Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY KEY,
country VARCHAR){}}}.
# Insert some data into the table.
# Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN city
VARCHAR{}}}.
# Fetch the data using the record API: Tuple record =
table.recordView().get(null, key);
# Try to remove the data: List result =
table.recordView().deleteAllExact(null, List.of(record));
*Expected Behavior:*
The data is removed.
*Actual Behavior:*
{code:java}
Tuple doesn't match schema: schemaVersion=2, extraColumns=[]
org.apache.ignite.lang.MarshallerException: IGN-CMN-65535
TraceId:daeb79d1-49bb-47bd-af04-9f9162a44d07 Tuple doesn't match schema:
schemaVersion=2, extraColumns=[]{code}
was:
*Steps to Reproduce:*
# Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY KEY,
country VARCHAR){}}}.
# Insert some data into the table.
# Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN city
VARCHAR{}}}.
# Fetch the data using the record API: Tuple record =
table.recordView().get(null, key);
#
Try to remove the data: List result =
table.recordView().deleteAllExact(null, List.of(record));
*Expected Behavior:*
The data is removed.
*Actual Behavior:*
{code:java}
Tuple doesn't match schema: schemaVersion=2, extraColumns=[]
org.apache.ignite.lang.MarshallerException: IGN-CMN-65535
TraceId:daeb79d1-49bb-47bd-af04-9f9162a44d07 Tuple doesn't match schema:
schemaVersion=2, extraColumns=[]{code}
> Altering the table causes the record API to break
> -
>
> Key: IGNITE-21297
> URL: https://issues.apache.org/jira/browse/IGNITE-21297
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
> Attachments: alterTableTest1.java
>
>
> *Steps to Reproduce:*
> # Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY
> KEY, country VARCHAR){}}}.
> # Insert some data into the table.
> # Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN
> city VARCHAR{}}}.
> # Fetch the data using the record API: Tuple record =
> table.recordView().get(null, key);
> # Try to remove the data: List result =
> table.recordView().deleteAllExact(null, List.of(record));
> *Expected Behavior:*
> The data is removed.
> *Actual Behavior:*
> {code:java}
> Tuple doesn't match schema: schemaVersion=2, extraColumns=[]
> org.apache.ignite.lang.MarshallerException: IGN-CMN-65535
> TraceId:daeb79d1-49bb-47bd-af04-9f9162a44d07 Tuple doesn't match schema:
> schemaVersion=2, extraColumns=[]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21297) Altering the table causes the record API to break
[
https://issues.apache.org/jira/browse/IGNITE-21297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-21297:
---
Attachment: alterTableTest1.java
> Altering the table causes the record API to break
> -
>
> Key: IGNITE-21297
> URL: https://issues.apache.org/jira/browse/IGNITE-21297
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
> Attachments: alterTableTest1.java
>
>
> *Steps to Reproduce:*
> # Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY
> KEY, country VARCHAR){}}}.
> # Insert some data into the table.
> # Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN
> city VARCHAR{}}}.
> # Fetch the data using the record API: Tuple record =
> table.recordView().get(null, key);
> #
> Try to remove the data: List result =
> table.recordView().deleteAllExact(null, List.of(record));
> *Expected Behavior:*
> The data is removed.
> *Actual Behavior:*
> {code:java}
> Tuple doesn't match schema: schemaVersion=2, extraColumns=[]
> org.apache.ignite.lang.MarshallerException: IGN-CMN-65535
> TraceId:daeb79d1-49bb-47bd-af04-9f9162a44d07 Tuple doesn't match schema:
> schemaVersion=2, extraColumns=[]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21296) Altering the table causes the KV API to break
[
https://issues.apache.org/jira/browse/IGNITE-21296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-21296:
---
Description:
*Steps to Reproduce:*
# Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY KEY,
country VARCHAR){}}}.
# Create a POJO with corresponding fields to the table.
# Create a Key-Value (KV) view: {{{}KeyValueView
countryValueView = table.keyValueView(Mapper.of(Integer.class),
Mapper.of(Country.class));{}}}.
# Insert some data into the table.
# Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN city
VARCHAR{}}}.
# Create a new POJO to accommodate the added column.
# Create a new KV view: {{{}KeyValueView
countryCityKeyValueView =
CLUSTER.node(0).tables().table(TABLE_NAME).keyValueView(Mapper.of(Integer.class),
Mapper.of(CountryCity.class));{}}}.
# Attempt to remove data from the table using the first KV view:
{{{}assertTrue(countryValueView.remove(null, 0, valuePojo));{}}}. This fails
with the error "No mapped object field found for column 'CITY'".
# Try to remove data using the second KV view:
{{{}assertTrue(countryCityKeyValueView.remove(null, 0, new
CountryCity(valuePojo.country(), null)));{}}}. This returns {{{}false{}}}.
*Expected Behavior:*
It should be possible to remove values using either of the KV views after
altering the table structure.
*Actual Behavior:*
* Unable to remove values using the first KV view due to the lack of a 'city'
column in the original POJO.
* Unable to remove values using the second KV view as the {{equals}} method
does not function as expected.
was:
*Steps to Reproduce:*
# Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY KEY,
country VARCHAR){}}}.
# Create a POJO with corresponding fields to the table.
# Create a Key-Value (KV) view: {{{}KeyValueView
countryValueView = table.keyValueView(Mapper.of(Integer.class),
Mapper.of(Country.class));{}}}.
# Insert some data into the table.
# Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN city
VARCHAR{}}}.
# Create a new POJO to accommodate the added column.
# Create a new KV view: {{{}KeyValueView
countryCityKeyValueView =
CLUSTER.node(0).tables().table(TABLE_NAME).keyValueView(Mapper.of(Integer.class),
Mapper.of(CountryCity.class));{}}}.
# Attempt to remove data from the table using the first KV view:
{{{}assertTrue(countryValueView.remove(null, 0, valuePojo));{}}}. This fails
with the error "No mapped object field found for column 'CITY'".
# Try to remove data using the second KV view:
{{{}assertTrue(countryCityKeyValueView.remove(null, 0, new
CountryCity(valuePojo.country(), null)));{}}}. This returns {{{}false{}}}.
*Expected Behavior:*
** It should be possible to remove values using either of the KV views after
altering the table structure.
*Actual Behavior:*
** Unable to remove values using the first KV view due to the lack of a 'city'
column in the original POJO.
** Unable to remove values using the second KV view as the {{equals}} method
does not function as expected.
> Altering the table causes the KV API to break
> -
>
> Key: IGNITE-21296
> URL: https://issues.apache.org/jira/browse/IGNITE-21296
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
> Attachments: alterTableTest1.java
>
>
>
> *Steps to Reproduce:*
> # Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY
> KEY, country VARCHAR){}}}.
> # Create a POJO with corresponding fields to the table.
> # Create a Key-Value (KV) view: {{{}KeyValueView
> countryValueView = table.keyValueView(Mapper.of(Integer.class),
> Mapper.of(Country.class));{}}}.
> # Insert some data into the table.
> # Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN
> city VARCHAR{}}}.
> # Create a new POJO to accommodate the added column.
> # Create a new KV view: {{{}KeyValueView
> countryCityKeyValueView =
> CLUSTER.node(0).tables().table(TABLE_NAME).keyValueView(Mapper.of(Integer.class),
> Mapper.of(CountryCity.class));{}}}.
> # Attempt to remove data from the table using the first KV view:
> {{{}assertTrue(countryValueView.remove(null, 0, valuePojo));{}}}. This fails
> with the error "No mapped object field found for column 'CITY'".
> # Try to remove data using the second KV view:
> {{{}assertTrue(countryCityKeyValueView.remove(null, 0, new
> CountryCity(valuePojo.country(), null)));{}}}. This returns {{{}false{}}}.
> *Expected Behavior:*
> It should be possible to remove values using either of the KV views after
> altering the table structure.
> *Actual Behavior:*
> * Unable to remove values using the first KV view due to the lack of a
> 'city' column in the original POJO.
> *
[jira] [Updated] (IGNITE-21297) Altering the table causes the record API to break
[
https://issues.apache.org/jira/browse/IGNITE-21297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-21297:
---
Description:
*Steps to Reproduce:*
# Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY KEY,
country VARCHAR){}}}.
# Insert some data into the table.
# Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN city
VARCHAR{}}}.
# Fetch the data using the record API: Tuple record =
table.recordView().get(null, key);
#
Try to remove the data: List result =
table.recordView().deleteAllExact(null, List.of(record));
*Expected Behavior:*
The data is removed.
*Actual Behavior:*
{code:java}
Tuple doesn't match schema: schemaVersion=2, extraColumns=[]
org.apache.ignite.lang.MarshallerException: IGN-CMN-65535
TraceId:daeb79d1-49bb-47bd-af04-9f9162a44d07 Tuple doesn't match schema:
schemaVersion=2, extraColumns=[]{code}
was:
*Steps to Reproduce:*
# Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY KEY,
country VARCHAR){}}}.
# Insert some data into the table.
# Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN city
VARCHAR{}}}.
# Fetch the data using the record API: Tuple record =
table.recordView().get(null, key);
#
Try to remove the data: List result =
table.recordView().deleteAllExact(null, List.of(record));
*Expected Behavior:*
The data is removed.
*Actual Behavior:*
{code:java}
{code}
*Tuple doesn't match schema: schemaVersion=2, extraColumns=[]
org.apache.ignite.lang.MarshallerException: IGN-CMN-65535
TraceId:daeb79d1-49bb-47bd-af04-9f9162a44d07 Tuple doesn't match schema:
schemaVersion=2, extraColumns=[]*
> Altering the table causes the record API to break
> -
>
> Key: IGNITE-21297
> URL: https://issues.apache.org/jira/browse/IGNITE-21297
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
>
> *Steps to Reproduce:*
> # Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY
> KEY, country VARCHAR){}}}.
> # Insert some data into the table.
> # Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN
> city VARCHAR{}}}.
> # Fetch the data using the record API: Tuple record =
> table.recordView().get(null, key);
> #
> Try to remove the data: List result =
> table.recordView().deleteAllExact(null, List.of(record));
> *Expected Behavior:*
> The data is removed.
> *Actual Behavior:*
> {code:java}
> Tuple doesn't match schema: schemaVersion=2, extraColumns=[]
> org.apache.ignite.lang.MarshallerException: IGN-CMN-65535
> TraceId:daeb79d1-49bb-47bd-af04-9f9162a44d07 Tuple doesn't match schema:
> schemaVersion=2, extraColumns=[]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21297) Altering the table causes the record API to break
Ivan Gagarkin created IGNITE-21297:
--
Summary: Altering the table causes the record API to break
Key: IGNITE-21297
URL: https://issues.apache.org/jira/browse/IGNITE-21297
Project: Ignite
Issue Type: Bug
Reporter: Ivan Gagarkin
*Steps to Reproduce:*
# Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY KEY,
country VARCHAR){}}}.
# Insert some data into the table.
# Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN city
VARCHAR{}}}.
# Fetch the data using the record API: Tuple record =
table.recordView().get(null, key);
#
Try to remove the data: List result =
table.recordView().deleteAllExact(null, List.of(record));
*Expected Behavior:*
The data is removed.
*Actual Behavior:*
{code:java}
{code}
*Tuple doesn't match schema: schemaVersion=2, extraColumns=[]
org.apache.ignite.lang.MarshallerException: IGN-CMN-65535
TraceId:daeb79d1-49bb-47bd-af04-9f9162a44d07 Tuple doesn't match schema:
schemaVersion=2, extraColumns=[]*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21296) Altering the table causes the KV API to break
Ivan Gagarkin created IGNITE-21296:
--
Summary: Altering the table causes the KV API to break
Key: IGNITE-21296
URL: https://issues.apache.org/jira/browse/IGNITE-21296
Project: Ignite
Issue Type: Bug
Reporter: Ivan Gagarkin
Attachments: alterTableTest1.java
*Steps to Reproduce:*
# Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY KEY,
country VARCHAR){}}}.
# Create a POJO with corresponding fields to the table.
# Create a Key-Value (KV) view: {{{}KeyValueView
countryValueView = table.keyValueView(Mapper.of(Integer.class),
Mapper.of(Country.class));{}}}.
# Insert some data into the table.
# Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN city
VARCHAR{}}}.
# Create a new POJO to accommodate the added column.
# Create a new KV view: {{{}KeyValueView
countryCityKeyValueView =
CLUSTER.node(0).tables().table(TABLE_NAME).keyValueView(Mapper.of(Integer.class),
Mapper.of(CountryCity.class));{}}}.
# Attempt to remove data from the table using the first KV view:
{{{}assertTrue(countryValueView.remove(null, 0, valuePojo));{}}}. This fails
with the error "No mapped object field found for column 'CITY'".
# Try to remove data using the second KV view:
{{{}assertTrue(countryCityKeyValueView.remove(null, 0, new
CountryCity(valuePojo.country(), null)));{}}}. This returns {{{}false{}}}.
*Expected Behavior:*
** It should be possible to remove values using either of the KV views after
altering the table structure.
*Actual Behavior:*
** Unable to remove values using the first KV view due to the lack of a 'city'
column in the original POJO.
** Unable to remove values using the second KV view as the {{equals}} method
does not function as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21296) Altering the table causes the KV API to break
[
https://issues.apache.org/jira/browse/IGNITE-21296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-21296:
---
Attachment: alterTableTest1.java
> Altering the table causes the KV API to break
> -
>
> Key: IGNITE-21296
> URL: https://issues.apache.org/jira/browse/IGNITE-21296
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
> Attachments: alterTableTest1.java
>
>
>
> *Steps to Reproduce:*
> # Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY
> KEY, country VARCHAR){}}}.
> # Create a POJO with corresponding fields to the table.
> # Create a Key-Value (KV) view: {{{}KeyValueView
> countryValueView = table.keyValueView(Mapper.of(Integer.class),
> Mapper.of(Country.class));{}}}.
> # Insert some data into the table.
> # Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN
> city VARCHAR{}}}.
> # Create a new POJO to accommodate the added column.
> # Create a new KV view: {{{}KeyValueView
> countryCityKeyValueView =
> CLUSTER.node(0).tables().table(TABLE_NAME).keyValueView(Mapper.of(Integer.class),
> Mapper.of(CountryCity.class));{}}}.
> # Attempt to remove data from the table using the first KV view:
> {{{}assertTrue(countryValueView.remove(null, 0, valuePojo));{}}}. This fails
> with the error "No mapped object field found for column 'CITY'".
> # Try to remove data using the second KV view:
> {{{}assertTrue(countryCityKeyValueView.remove(null, 0, new
> CountryCity(valuePojo.country(), null)));{}}}. This returns {{{}false{}}}.
> *Expected Behavior:*
> ** It should be possible to remove values using either of the KV views after
> altering the table structure.
> *Actual Behavior:*
> ** Unable to remove values using the first KV view due to the lack of a
> 'city' column in the original POJO.
> ** Unable to remove values using the second KV view as the {{equals}} method
> does not function as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21296) Altering the table causes the KV API to break
[
https://issues.apache.org/jira/browse/IGNITE-21296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-21296:
---
Labels: ignite-3 (was: )
> Altering the table causes the KV API to break
> -
>
> Key: IGNITE-21296
> URL: https://issues.apache.org/jira/browse/IGNITE-21296
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
> Attachments: alterTableTest1.java
>
>
>
> *Steps to Reproduce:*
> # Create a table using the command: {{{}CREATE TABLE TEST (id INT PRIMARY
> KEY, country VARCHAR){}}}.
> # Create a POJO with corresponding fields to the table.
> # Create a Key-Value (KV) view: {{{}KeyValueView
> countryValueView = table.keyValueView(Mapper.of(Integer.class),
> Mapper.of(Country.class));{}}}.
> # Insert some data into the table.
> # Alter the table by adding a new column: {{{}ALTER TABLE TEST ADD COLUMN
> city VARCHAR{}}}.
> # Create a new POJO to accommodate the added column.
> # Create a new KV view: {{{}KeyValueView
> countryCityKeyValueView =
> CLUSTER.node(0).tables().table(TABLE_NAME).keyValueView(Mapper.of(Integer.class),
> Mapper.of(CountryCity.class));{}}}.
> # Attempt to remove data from the table using the first KV view:
> {{{}assertTrue(countryValueView.remove(null, 0, valuePojo));{}}}. This fails
> with the error "No mapped object field found for column 'CITY'".
> # Try to remove data using the second KV view:
> {{{}assertTrue(countryCityKeyValueView.remove(null, 0, new
> CountryCity(valuePojo.country(), null)));{}}}. This returns {{{}false{}}}.
> *Expected Behavior:*
> ** It should be possible to remove values using either of the KV views after
> altering the table structure.
> *Actual Behavior:*
> ** Unable to remove values using the first KV view due to the lack of a
> 'city' column in the original POJO.
> ** Unable to remove values using the second KV view as the {{equals}} method
> does not function as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20848) Management REST API for Compute
[
https://issues.apache.org/jira/browse/IGNITE-20848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-20848:
--
Assignee: Ivan Gagarkin
> Management REST API for Compute
>
>
> Key: IGNITE-20848
> URL: https://issues.apache.org/jira/browse/IGNITE-20848
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Mikhail Pochatkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> POST /management/v1/compute/priority
> //Change priority for job
> //Body with job is and new priority
>
> GET /management/v1/compute/jobs
> //List of all job's statuses
>
> GET /management/v1/compute/jobs/\{id}
> //Job status for specified id
>
> DELETE /management/v1/compute/cancel/\{id}
> //Cancel job for specified id
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21064) Refactor authentication naming and enum in Thin Client for clarity
[
https://issues.apache.org/jira/browse/IGNITE-21064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-21064:
--
Assignee: Ivan Gagarkin
> Refactor authentication naming and enum in Thin Client for clarity
> --
>
> Key: IGNITE-21064
> URL: https://issues.apache.org/jira/browse/IGNITE-21064
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the Thin Client utilizes
> {{org.apache.ignite.security.AuthenticationType}} to specify the
> authentication method during the handshake process. This approach can be
> confusing due to its interaction with the type of authentication defined in
> the configuration. To resolve this, we propose creating a separate
> enumeration specifically for the client. Additionally, the 'BASIC'
> authentication type should be renamed to 'PASSWORD' for clearer understanding.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20207) Improve the error handling
[ https://issues.apache.org/jira/browse/IGNITE-20207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20207: --- Description: The current implementation of org.apache.ignite.internal.network.file.FileTransferService doesn't provide recovery functionality. In case of any error the transfer should be started from scratch. We need to define cases when Ignite can provide recovery and implement this functionality. (was: The current implementation of org.apache.ignite.internal.network.file.FileTransferService doesn't provide recovery functionality. Any error during file transfer leads to repeating the transfer from scratch. We need to define cases when Ignite can provide recovery and implement this functionality. ) > Improve the error handling > -- > > Key: IGNITE-20207 > URL: https://issues.apache.org/jira/browse/IGNITE-20207 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > The current implementation of > org.apache.ignite.internal.network.file.FileTransferService doesn't provide > recovery functionality. In case of any error the transfer should be started > from scratch. We need to define cases when Ignite can provide recovery and > implement this functionality. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21199) Introduce a mechanism to manage and schedule Ignite services tasks
Ivan Gagarkin created IGNITE-21199: -- Summary: Introduce a mechanism to manage and schedule Ignite services tasks Key: IGNITE-21199 URL: https://issues.apache.org/jira/browse/IGNITE-21199 Project: Ignite Issue Type: Improvement Reporter: Ivan Gagarkin We have service tasks such as GC, and we anticipate more, which consume resources shared with user tasks, such as queries. These tasks should not monopolize resources when a node is engaged in user queries but should utilize all resources during idle times. We need to develop a common mechanism to manage resource allocation between service tasks and user tasks, ensuring this component is reusable across different service task-creating components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21157) Introducing transaction priority to resolve user and service transaction conflicts
[ https://issues.apache.org/jira/browse/IGNITE-21157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-21157: -- Assignee: Ivan Gagarkin > Introducing transaction priority to resolve user and service transaction > conflicts > -- > > Key: IGNITE-21157 > URL: https://issues.apache.org/jira/browse/IGNITE-21157 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > We need to introduce a new transaction attribute: transaction priority. This > addition is necessary to resolve potential conflicts between user > transactions and internal Ignite services transactions. Transactions from > services should be assigned a LOW priority. In the event of a conflict, the > DeadlockPreventionPolicy will assess the priorities of the involved > transactions. If the priorities are the same, the policy will then compare > timestamps; otherwise, the transaction with the lower priority will be rolled > back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21157) Introducing transaction priority to resolve user and service transaction conflicts
Ivan Gagarkin created IGNITE-21157: -- Summary: Introducing transaction priority to resolve user and service transaction conflicts Key: IGNITE-21157 URL: https://issues.apache.org/jira/browse/IGNITE-21157 Project: Ignite Issue Type: Improvement Reporter: Ivan Gagarkin We need to introduce a new transaction attribute: transaction priority. This addition is necessary to resolve potential conflicts between user transactions and internal Ignite services transactions. Transactions from services should be assigned a LOW priority. In the event of a conflict, the DeadlockPreventionPolicy will assess the priorities of the involved transactions. If the priorities are the same, the policy will then compare timestamps; otherwise, the transaction with the lower priority will be rolled back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21154) Improve InternalTable API
Ivan Gagarkin created IGNITE-21154:
--
Summary: Improve InternalTable API
Key: IGNITE-21154
URL: https://issues.apache.org/jira/browse/IGNITE-21154
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Ivan Gagarkin
Currently, {{org.apache.ignite.internal.table.InternalTable}} contains two
methods, {{deleteAllExact}} and {{{}deleteExact{}}}, which compare all columns
of the stored and provided rows, subsequently deleting the rows if their
columns are equal. We need to introduce an option allowing specification of
only selected columns for equality checks.
Additionally, there is a need for methods capable of deleting rows in a
specific partition. This would involve implementing functionality like
{code:java}
CompletableFuture delete(BinaryRowEx keyRow, int partitionId,
@Nullable InternalTransaction tx);{code}
to enable targeted row deletion within an exact partition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21137) InternalTableImpl scan methods ignore 'columnsToInclude' parameter
Ivan Gagarkin created IGNITE-21137: -- Summary: InternalTableImpl scan methods ignore 'columnsToInclude' parameter Key: IGNITE-21137 URL: https://issues.apache.org/jira/browse/IGNITE-21137 Project: Ignite Issue Type: Bug Reporter: Ivan Gagarkin InternalTableImpl's scan methods are currently returning all columns, despite of the specified 'columnsToInclude' parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21101) Renaming a node in named list disrupts update functionality
[
https://issues.apache.org/jira/browse/IGNITE-21101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-21101:
---
Attachment: ConfigurationListenerTest.java
> Renaming a node in named list disrupts update functionality
> ---
>
> Key: IGNITE-21101
> URL: https://issues.apache.org/jira/browse/IGNITE-21101
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
> Attachments: ConfigurationListenerTest.java
>
>
>
> To reproduce:
> # Remove NPE check in ConfigurationNotifier on 137th line
> # Run
> org.apache.ignite.internal.configuration.notifications.ConfigurationListenerTest#namedListNodeOnRenameAndThenUpdateSubElement
> {code:java}
> {
> "elemetns": [
> {
> "element1": {
> "entries": [
> {
> "entry1": {
> "name": "entry1",
> "value": "value1"
> }
> },
> {
> "entry2": {
> "name": "entry2",
> "value": "value2"
> }
> }
> ]
> }
> }
> ]
> } {code}
>
> * Subscribe to changes in "entry1"
> * "element1" is renamed to "element2".
> * After the renaming, update "entry1".
> * As a result, an NPE occurs.
>
> {code:java}
> java.util.concurrent.ExecutionException:
> org.apache.ignite.configuration.ConfigurationChangeException: Failed to
> change configuration at
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationListenerTest.namedListNodeOnRenameAndThenUpdateSubElement(ConfigurationListenerTest.java:707)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
> at
>
[jira] [Commented] (IGNITE-21101) Renaming a node in named list disrupts update functionality
[
https://issues.apache.org/jira/browse/IGNITE-21101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798486#comment-17798486
]
Ivan Gagarkin commented on IGNITE-21101:
The root cause is
org.apache.ignite.internal.configuration.NamedListConfiguration#beforeRefreshValue
doesn't support rename. Possible fix is
{code:java}
@Override
protected synchronized void beforeRefreshValue(
NamedListView newValue,
@Nullable NamedListView oldValue
) {
Map> oldValues = this.members;
Map> newValues = new LinkedHashMap<>();
NamedListNode newValueNode = (NamedListNode) newValue;
NamedListNode oldValueNode = (NamedListNode) oldValue;
for (UUID internalId : newValueNode.internalIds()) {
String newName = newValueNode.keyByInternalId(internalId);
String oldName = oldValue == null ? null :
oldValueNode.keyByInternalId(internalId);
if (oldName != null) {
newValues.put(newName, oldValues.get(oldName));
} else {
newValues.put(newName, cfgCreator.apply(keys, newName));
}
}
this.members = newValues;
} {code}
But also, we have to refactor
org.apache.ignite.internal.configuration.ConfigurationNode#keys because it
keeps names not ids.
> Renaming a node in named list disrupts update functionality
> ---
>
> Key: IGNITE-21101
> URL: https://issues.apache.org/jira/browse/IGNITE-21101
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
>
> To reproduce:
> # Remove NPE check in ConfigurationNotifier on 137th line
> # Run
> org.apache.ignite.internal.configuration.notifications.ConfigurationListenerTest#namedListNodeOnRenameAndThenUpdateSubElement
> {code:java}
> {
> "elemetns": [
> {
> "element1": {
> "entries": [
> {
> "entry1": {
> "name": "entry1",
> "value": "value1"
> }
> },
> {
> "entry2": {
> "name": "entry2",
> "value": "value2"
> }
> }
> ]
> }
> }
> ]
> } {code}
>
> * Subscribe to changes in "entry1"
> * "element1" is renamed to "element2".
> * After the renaming, update "entry1".
> * As a result, an NPE occurs.
>
> {code:java}
> java.util.concurrent.ExecutionException:
> org.apache.ignite.configuration.ConfigurationChangeException: Failed to
> change configuration at
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationListenerTest.namedListNodeOnRenameAndThenUpdateSubElement(ConfigurationListenerTest.java:707)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
>
[jira] [Created] (IGNITE-21101) Renaming a node in named list disrupts update functionality
Ivan Gagarkin created IGNITE-21101:
--
Summary: Renaming a node in named list disrupts update
functionality
Key: IGNITE-21101
URL: https://issues.apache.org/jira/browse/IGNITE-21101
Project: Ignite
Issue Type: Bug
Reporter: Ivan Gagarkin
To reproduce:
# Remove NPE check in ConfigurationNotifier on 137th line
# Run
org.apache.ignite.internal.configuration.notifications.ConfigurationListenerTest#namedListNodeOnRenameAndThenUpdateSubElement
{code:java}
{
"elemetns": [
{
"element1": {
"entries": [
{
"entry1": {
"name": "entry1",
"value": "value1"
}
},
{
"entry2": {
"name": "entry2",
"value": "value2"
}
}
]
}
}
]
} {code}
* Subscribe to changes in "entry1"
* "element1" is renamed to "element2".
* After the renaming, update "entry1".
* As a result, an NPE occurs.
{code:java}
java.util.concurrent.ExecutionException:
org.apache.ignite.configuration.ConfigurationChangeException: Failed to change
configuration at
java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
at
org.apache.ignite.internal.configuration.notifications.ConfigurationListenerTest.namedListNodeOnRenameAndThenUpdateSubElement(ConfigurationListenerTest.java:707)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
[jira] [Assigned] (IGNITE-21065) Enhance granularity of authentication events
[
https://issues.apache.org/jira/browse/IGNITE-21065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-21065:
--
Assignee: Ivan Gagarkin
> Enhance granularity of authentication events
>
>
> Key: IGNITE-21065
> URL: https://issues.apache.org/jira/browse/IGNITE-21065
> Project: Ignite
> Issue Type: Bug
> Components: security, thin client
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since the basic authenticator stores a list of users, we need to extend
> authentication events to improve granularity. This is to ensure that the
> connection is not closed for all users if just one of them changes their
> password. Update the tests in
> {{org.apache.ignite.client.handler.ClientInboundMessageHandlerTest}}
> accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20409) Refactor org.apache.ignite.Ignition#init
[
https://issues.apache.org/jira/browse/IGNITE-20409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin resolved IGNITE-20409.
Resolution: Abandoned
> Refactor org.apache.ignite.Ignition#init
>
>
> Key: IGNITE-20409
> URL: https://issues.apache.org/jira/browse/IGNITE-20409
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the current implementation, the method {{org.apache.ignite.Ignition#init}}
> accepts an instance of {{{}org.apache.ignite.InitParameters{}}}. Within this
> parameter object, there's a field called {{{}destinationNodeName{}}}. After
> reviewing the API consistency and internal usage, it appears that the current
> structure might be over-complicated and inconsistent with other methods of
> the {{Ignition}} class.Proposed Changes: # Refactor the
> {{org.apache.ignite.Ignition#init}} method to accept {{destinationNodeName}}
> as a direct parameter rather than as part of the {{InitParameters}} object.
> # Update the {{InitParameters}} class to remove the {{destinationNodeName}}
> field.
> # Update tests which are affected by these changes.
> Rationale:
> * Enhances API clarity by reducing the complexity of method parameters.
> * Makes the method signature more consistent with other methods in the
> {{Ignition}} class.
> * Provides flexibility for internal usage of the {{InitParameters}} without
> the node name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21065) Enhance granularity of authentication events
[
https://issues.apache.org/jira/browse/IGNITE-21065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-21065:
---
Summary: Enhance granularity of authentication events (was: Extend
AuthenticationEvent with USER_CREATED and USER_CHANGED)
> Enhance granularity of authentication events
>
>
> Key: IGNITE-21065
> URL: https://issues.apache.org/jira/browse/IGNITE-21065
> Project: Ignite
> Issue Type: Bug
> Components: security, thin client
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> Since the basic authenticator stores a list of users, we need to extend
> authentication events to improve granularity. This is to ensure that the
> connection is not closed for all users if just one of them changes their
> password. Update the tests in
> {{org.apache.ignite.client.handler.ClientInboundMessageHandlerTest}}
> accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21065) Extend AuthenticationEvent with USER_CREATED and USER_CHANGED
Ivan Gagarkin created IGNITE-21065:
--
Summary: Extend AuthenticationEvent with USER_CREATED and
USER_CHANGED
Key: IGNITE-21065
URL: https://issues.apache.org/jira/browse/IGNITE-21065
Project: Ignite
Issue Type: Bug
Components: security, thin client
Reporter: Ivan Gagarkin
Since the basic authenticator stores a list of users, we need to extend
authentication events to improve granularity. This is to ensure that the
connection is not closed for all users if just one of them changes their
password. Update the tests in
{{org.apache.ignite.client.handler.ClientInboundMessageHandlerTest}}
accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21064) Refactor authentication naming and enum in Thin Client for clarity
Ivan Gagarkin created IGNITE-21064:
--
Summary: Refactor authentication naming and enum in Thin Client
for clarity
Key: IGNITE-21064
URL: https://issues.apache.org/jira/browse/IGNITE-21064
Project: Ignite
Issue Type: Improvement
Components: thin client
Reporter: Ivan Gagarkin
Currently, the Thin Client utilizes
{{org.apache.ignite.security.AuthenticationType}} to specify the authentication
method during the handshake process. This approach can be confusing due to its
interaction with the type of authentication defined in the configuration. To
resolve this, we propose creating a separate enumeration specifically for the
client. Additionally, the 'BASIC' authentication type should be renamed to
'PASSWORD' for clearer understanding.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20841) Introduce Compute Job status internal layer
[
https://issues.apache.org/jira/browse/IGNITE-20841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20841:
---
Description:
Each not-finished Compute Job should provide their current status. This ticket
require only internal API layer. The structure of status class should be follow
{code:java}
public class JobStatus {
private final UUID id;
private JobState state;
private Instant createTime;
private Instant startTime;
private Instant finishTime;
} {code}
was:
Each not-finished Compute Job should provide their current status. This ticket
require only internal API layer. The structure of status class should be follow
{code:java}
public class JobStatus {
private final UUID id;
private JobState state;
private String ownership;
private Instant createTime;
private Instant startTime;
private Instant finishTime;
} {code}
> Introduce Compute Job status internal layer
> ---
>
> Key: IGNITE-20841
> URL: https://issues.apache.org/jira/browse/IGNITE-20841
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Mikhail Pochatkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Each not-finished Compute Job should provide their current status. This
> ticket require only internal API layer. The structure of status class should
> be follow
> {code:java}
> public class JobStatus {
> private final UUID id;
> private JobState state;
> private Instant createTime;
> private Instant startTime;
> private Instant finishTime;
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20841) Introduce Compute Job status internal layer
[
https://issues.apache.org/jira/browse/IGNITE-20841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-20841:
--
Assignee: Ivan Gagarkin
> Introduce Compute Job status internal layer
> ---
>
> Key: IGNITE-20841
> URL: https://issues.apache.org/jira/browse/IGNITE-20841
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Mikhail Pochatkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Each not-finished Compute Job should provide their current status. This
> ticket require only internal API layer. The structure of status class should
> be follow
> {code:java}
> public class JobStatus {
> private final UUID id;
> private JobState state;
> private String ownership;
> private Instant createTime;
> private Instant startTime;
> private Instant finishTime;
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20866) Race condition in configuration initialization using meta storage revision
[
https://issues.apache.org/jira/browse/IGNITE-20866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-20866:
--
Assignee: Ivan Gagarkin
> Race condition in configuration initialization using meta storage revision
> --
>
> Key: IGNITE-20866
> URL: https://issues.apache.org/jira/browse/IGNITE-20866
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
>
> {*}Summary{*}{_}:{_} Initialization of the cluster configuration using meta
> storage revision 0 leads to race conditions, resulting in potential
> misconfiguration.
> {*}Analysis{*}: Currently, the system applies the initial cluster
> configuration locally when the meta-storage revision is at 0. This approach
> can lead to race conditions where the initial configuration might be
> overlooked if the revision number changes during the initialization process.
> _Suggested Fix:_ We should modify the initialization logic to:
> # Use the local revision of the configuration key.
> # If the local revision is absent, only then fall back to the initial
> configuration.
> This approach would prevent the configuration from being ignored due to
> changes in the meta-store revision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20866) Race condition in configuration initialization using meta storage revision
Ivan Gagarkin created IGNITE-20866:
--
Summary: Race condition in configuration initialization using meta
storage revision
Key: IGNITE-20866
URL: https://issues.apache.org/jira/browse/IGNITE-20866
Project: Ignite
Issue Type: Bug
Reporter: Ivan Gagarkin
{*}Summary{*}{_}:{_} Initialization of the cluster configuration using meta
storage revision 0 leads to race conditions, resulting in potential
misconfiguration.
{*}Analysis{*}: Currently, the system applies the initial cluster configuration
locally when the meta-storage revision is at 0. This approach can lead to race
conditions where the initial configuration might be overlooked if the revision
number changes during the initialization process.
_Suggested Fix:_ We should modify the initialization logic to:
# Use the local revision of the configuration key.
# If the local revision is absent, only then fall back to the initial
configuration.
This approach would prevent the configuration from being ignored due to changes
in the meta-store revision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20854) Address Follow-Up Tasks for Completed IGNITE-20499
[ https://issues.apache.org/jira/browse/IGNITE-20854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20854: --- Priority: Critical (was: Major) > Address Follow-Up Tasks for Completed IGNITE-20499 > -- > > Key: IGNITE-20854 > URL: https://issues.apache.org/jira/browse/IGNITE-20854 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Priority: Critical > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > https://issues.apache.org/jira/browse/IGNITE-20499 is completed. Now, we need > to address the follow-up 'to-dos'. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20856) Replace IGNITE-20499 with IGNITE-20854 in To-Dos
[ https://issues.apache.org/jira/browse/IGNITE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-20856: -- Assignee: Ivan Gagarkin > Replace IGNITE-20499 with IGNITE-20854 in To-Dos > > > Key: IGNITE-20856 > URL: https://issues.apache.org/jira/browse/IGNITE-20856 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Critical > Labels: ignite-3 > > Replace IGNITE-20499 with IGNITE-20854 in To-Dos -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20856) Replace IGNITE-20499 with IGNITE-20854 in To-Dos
Ivan Gagarkin created IGNITE-20856: -- Summary: Replace IGNITE-20499 with IGNITE-20854 in To-Dos Key: IGNITE-20856 URL: https://issues.apache.org/jira/browse/IGNITE-20856 Project: Ignite Issue Type: Improvement Reporter: Ivan Gagarkin Replace IGNITE-20499 with IGNITE-20854 in To-Dos -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20854) Address Follow-Up Tasks for Completed IGNITE-20499
Ivan Gagarkin created IGNITE-20854: -- Summary: Address Follow-Up Tasks for Completed IGNITE-20499 Key: IGNITE-20854 URL: https://issues.apache.org/jira/browse/IGNITE-20854 Project: Ignite Issue Type: Improvement Reporter: Ivan Gagarkin https://issues.apache.org/jira/browse/IGNITE-20499 is completed. Now, we need to address the follow-up 'to-dos'. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20814) Replace AuthorizationHeaderFilter with own implementation of SecurityFilter
[
https://issues.apache.org/jira/browse/IGNITE-20814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-20814:
--
Assignee: Ivan Gagarkin
> Replace AuthorizationHeaderFilter with own implementation of SecurityFilter
> ---
>
> Key: IGNITE-20814
> URL: https://issues.apache.org/jira/browse/IGNITE-20814
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Current Behavior:* We're currently injecting an empty Authorization header
> in requests lacking one, as Micronaut filters out requests without
> authentication headers. This is handled by the AuthorizationHeaderFilter.
> *Problem:* This workaround is not ideal and could lead to maintainability
> issues.
> *Proposed Solution:* Develop a custom SecurityFilter that:
> * Checks whether authentication is enabled.
> * Forwards requests to {{io.micronaut.security.filters.SecurityFilter}} if
> authentication is required.
> * Allows requests to proceed without authentication if it's not required.
> *Objective:* To replace the AuthorizationHeaderFilter with a more robust and
> maintainable custom SecurityFilter implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20814) Replace AuthorizationHeaderFilter with own implementation of SecurityFilter
Ivan Gagarkin created IGNITE-20814:
--
Summary: Replace AuthorizationHeaderFilter with own implementation
of SecurityFilter
Key: IGNITE-20814
URL: https://issues.apache.org/jira/browse/IGNITE-20814
Project: Ignite
Issue Type: Improvement
Components: rest
Reporter: Ivan Gagarkin
*Current Behavior:* We're currently injecting an empty Authorization header in
requests lacking one, as Micronaut filters out requests without authentication
headers. This is handled by the AuthorizationHeaderFilter.
*Problem:* This workaround is not ideal and could lead to maintainability
issues.
*Proposed Solution:* Develop a custom SecurityFilter that:
* Checks whether authentication is enabled.
* Forwards requests to {{io.micronaut.security.filters.SecurityFilter}} if
authentication is required.
* Allows requests to proceed without authentication if it's not required.
*Objective:* To replace the AuthorizationHeaderFilter with a more robust and
maintainable custom SecurityFilter implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19723) All REST endpoins should return valid Problem json
[ https://issues.apache.org/jira/browse/IGNITE-19723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-19723: -- Assignee: Ivan Gagarkin > All REST endpoins should return valid Problem json > -- > > Key: IGNITE-19723 > URL: https://issues.apache.org/jira/browse/IGNITE-19723 > Project: Ignite > Issue Type: Bug > Components: rest >Reporter: Aleksandr >Assignee: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > We have to develop a common mechanism for validation that any REST endpoint > returns valid Problem json. > Here is the definition for valid Problem > https://datatracker.ietf.org/doc/html/rfc7807 > Now we do not set application/json+problem content type. Also, all cases > should be carefully reviewed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20499) Ability to obtain actual cluster configuration values during startup.
[ https://issues.apache.org/jira/browse/IGNITE-20499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-20499: -- Assignee: Ivan Gagarkin > Ability to obtain actual cluster configuration values during startup. > - > > Key: IGNITE-20499 > URL: https://issues.apache.org/jira/browse/IGNITE-20499 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Ivan Gagarkin >Priority: Major > Labels: configuration, ignite-3 > > The value of the configuration parameter can be changed during cluster > initialization (IgniteImpl#init). System components do not see the actual > configuration values at startup (since locally this values is applied later). > This can cause confusion when a component reads a default configuration value > at startup, which then changes when the distributed configuration is applied > on the local node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20705) CLI does not switch user context when connect command executed with different credentials
Ivan Gagarkin created IGNITE-20705:
--
Summary: CLI does not switch user context when connect command
executed with different credentials
Key: IGNITE-20705
URL: https://issues.apache.org/jira/browse/IGNITE-20705
Project: Ignite
Issue Type: Bug
Components: cli
Reporter: Ivan Gagarkin
h3. Description:
When a user connects using the {{connect}} command in the CLI and then switches
to another user using the same {{connect}} command, the CLI does not switch the
context. All following commands are still executed as the first user.
h4. Steps to Reproduce:
# Create two users (User A and User B)
# Execute {{connect}} command with credentials of User A
# Execute {{connect}} command with credentials of User B
h4. Expected Result:
All following commands should be executed as User B.
h4. Actual Result:
All following commands are executed as User A.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20676) Support cipher suites in CLI for REST and JDBC connections
Ivan Gagarkin created IGNITE-20676: -- Summary: Support cipher suites in CLI for REST and JDBC connections Key: IGNITE-20676 URL: https://issues.apache.org/jira/browse/IGNITE-20676 Project: Ignite Issue Type: Improvement Components: cli Reporter: Ivan Gagarkin We currently don't have a way to specify cipher suites for CLI when establishing REST and JDBC connections. Acceptance Criteria: # CLI should allow users to specify a list of supported cipher suites for REST and JDBC connections. # If the specified cipher suite is not supported by the system, the CLI should throw an appropriate error message. # Tests are written to cover the new functionality. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20522) There should be a default user
[ https://issues.apache.org/jira/browse/IGNITE-20522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20522: --- Summary: There should be a default user (was: There should be a default user, if authentication is enabled) > There should be a default user > -- > > Key: IGNITE-20522 > URL: https://issues.apache.org/jira/browse/IGNITE-20522 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > We need to add a default user with the credentials "ignite/ignite" for > authentication purposes. > Additionally, the enabled flag should be moved to the top level of the > security configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20664) Resolve compatibility issue with SnakeYAML versions in Micronaut tests
Ivan Gagarkin created IGNITE-20664:
--
Summary: Resolve compatibility issue with SnakeYAML versions in
Micronaut tests
Key: IGNITE-20664
URL: https://issues.apache.org/jira/browse/IGNITE-20664
Project: Ignite
Issue Type: Bug
Components: cli
Reporter: Ivan Gagarkin
We are encountering an issue with Micronaut tests involving the 'jarhell'
component. Specifically, we are using two different versions of the SnakeYAML
library - version 1.33 and version 2.0. When running the tests from IntelliJ
IDEA, we observe the following error in the
'org.apache.ignite.internal.rest.ItGeneratedRestClientTest' class
{code:java}
java.lang.NoSuchMethodError: org.yaml.snakeyaml.constructor.SafeConstructor:
method 'void ()' not found
at
io.micronaut.context.env.yaml.CustomSafeConstructor.(CustomSafeConstructor.java:36)
at
io.micronaut.context.env.yaml.YamlPropertySourceLoader.processInput(YamlPropertySourceLoader.java:56)
at
io.micronaut.context.env.AbstractPropertySourceLoader.read(AbstractPropertySourceLoader.java:117)
at
io.micronaut.context.env.AbstractPropertySourceLoader.loadProperties(AbstractPropertySourceLoader.java:102)
at
io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:68)
at
io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:55)
at
io.micronaut.context.env.DefaultEnvironment.loadPropertySourceFromLoader(DefaultEnvironment.java:607)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:541)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:527)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.readPropertySourceList(DefaultApplicationContext.java:794)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySources(DefaultEnvironment.java:412)
at
io.micronaut.context.env.DefaultEnvironment.start(DefaultEnvironment.java:270)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:769)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:738)
at
io.micronaut.context.DefaultApplicationContext.startEnvironment(DefaultApplicationContext.java:242)
at
io.micronaut.context.DefaultApplicationContext.start(DefaultApplicationContext.java:193)
at
io.micronaut.test.extensions.AbstractMicronautExtension.startApplicationContext(AbstractMicronautExtension.java:433)
at
io.micronaut.test.extensions.AbstractMicronautExtension.beforeClass(AbstractMicronautExtension.java:314)
at
io.micronaut.test.extensions.junit5.MicronautJunit5Extension.beforeAll(MicronautJunit5Extension.java:84)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeBeforeAllCallbacks$12(ClassBasedTestDescriptor.java:395)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.invokeBeforeAllCallbacks(ClassBasedTestDescriptor.java:395)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:211)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:84)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:148)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541) at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
[jira] [Updated] (IGNITE-20647) Refine Authentication Configuration Handling in ClientInboundMessageHandler
[
https://issues.apache.org/jira/browse/IGNITE-20647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20647:
---
Description:
* {*}Current Behavior{*}: Presently, any modification to the authentication
configuration settings affects all connected clients indiscriminately. This
includes disconnecting clients even when authentication is turned off.
* {*}Desired Behavior{*}: Configuration changes should have a targeted impact
based on the nature of the change:
# If a user's password changes, only that user should be disconnected.
# If authentication i`s enabled, all currently connected users should be
disconnected.
# In all other cases, existing connections should remain intact.
was:
* {*}Current Behavior{*}: Presently, any modification to the authentication
configuration settings affects all connected clients indiscriminately. This
includes disconnecting clients even when authentication is turned off.
* {*}Desired Behavior{*}: Configuration changes should have a targeted impact
based on the nature of the change:
#
## If a user's password changes, only that user should be disconnected.
## If authentication is enabled, all currently connected users should be
disconnected.
## In all other cases, existing connections should remain intact.
> Refine Authentication Configuration Handling in ClientInboundMessageHandler
> ---
>
> Key: IGNITE-20647
> URL: https://issues.apache.org/jira/browse/IGNITE-20647
> Project: Ignite
> Issue Type: Improvement
> Components: security
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> * {*}Current Behavior{*}: Presently, any modification to the authentication
> configuration settings affects all connected clients indiscriminately. This
> includes disconnecting clients even when authentication is turned off.
> * {*}Desired Behavior{*}: Configuration changes should have a targeted
> impact based on the nature of the change:
> # If a user's password changes, only that user should be disconnected.
> # If authentication i`s enabled, all currently connected users should be
> disconnected.
> # In all other cases, existing connections should remain intact.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20647) Refine Authentication Configuration Handling in ClientInboundMessageHandler
[
https://issues.apache.org/jira/browse/IGNITE-20647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-20647:
--
Assignee: Ivan Gagarkin
> Refine Authentication Configuration Handling in ClientInboundMessageHandler
> ---
>
> Key: IGNITE-20647
> URL: https://issues.apache.org/jira/browse/IGNITE-20647
> Project: Ignite
> Issue Type: Improvement
> Components: security
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> * {*}Current Behavior{*}: Presently, any modification to the authentication
> configuration settings affects all connected clients indiscriminately. This
> includes disconnecting clients even when authentication is turned off.
> * {*}Desired Behavior{*}: Configuration changes should have a targeted
> impact based on the nature of the change:
> # If a user's password changes, only that user should be disconnected.
> # If authentication i`s enabled, all currently connected users should be
> disconnected.
> # In all other cases, existing connections should remain intact.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20647) Refine Authentication Configuration Handling in ClientInboundMessageHandler
Ivan Gagarkin created IGNITE-20647:
--
Summary: Refine Authentication Configuration Handling in
ClientInboundMessageHandler
Key: IGNITE-20647
URL: https://issues.apache.org/jira/browse/IGNITE-20647
Project: Ignite
Issue Type: Improvement
Components: security
Reporter: Ivan Gagarkin
* {*}Current Behavior{*}: Presently, any modification to the authentication
configuration settings affects all connected clients indiscriminately. This
includes disconnecting clients even when authentication is turned off.
* {*}Desired Behavior{*}: Configuration changes should have a targeted impact
based on the nature of the change:
## If a user's password changes, only that user should be disconnected.
## If authentication is enabled, all currently connected users should be
disconnected.
## In all other cases, existing connections should remain intact.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20647) Refine Authentication Configuration Handling in ClientInboundMessageHandler
[
https://issues.apache.org/jira/browse/IGNITE-20647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20647:
---
Description:
* {*}Current Behavior{*}: Presently, any modification to the authentication
configuration settings affects all connected clients indiscriminately. This
includes disconnecting clients even when authentication is turned off.
* {*}Desired Behavior{*}: Configuration changes should have a targeted impact
based on the nature of the change:
#
## If a user's password changes, only that user should be disconnected.
## If authentication is enabled, all currently connected users should be
disconnected.
## In all other cases, existing connections should remain intact.
was:
* {*}Current Behavior{*}: Presently, any modification to the authentication
configuration settings affects all connected clients indiscriminately. This
includes disconnecting clients even when authentication is turned off.
* {*}Desired Behavior{*}: Configuration changes should have a targeted impact
based on the nature of the change:
## If a user's password changes, only that user should be disconnected.
## If authentication is enabled, all currently connected users should be
disconnected.
## In all other cases, existing connections should remain intact.
> Refine Authentication Configuration Handling in ClientInboundMessageHandler
> ---
>
> Key: IGNITE-20647
> URL: https://issues.apache.org/jira/browse/IGNITE-20647
> Project: Ignite
> Issue Type: Improvement
> Components: security
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> * {*}Current Behavior{*}: Presently, any modification to the authentication
> configuration settings affects all connected clients indiscriminately. This
> includes disconnecting clients even when authentication is turned off.
> * {*}Desired Behavior{*}: Configuration changes should have a targeted
> impact based on the nature of the change:
> #
> ## If a user's password changes, only that user should be disconnected.
> ## If authentication is enabled, all currently connected users should be
> disconnected.
> ## In all other cases, existing connections should remain intact.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20643) BasicAuthenticationProviderConfiguration should contain a list of users
Ivan Gagarkin created IGNITE-20643: -- Summary: BasicAuthenticationProviderConfiguration should contain a list of users Key: IGNITE-20643 URL: https://issues.apache.org/jira/browse/IGNITE-20643 Project: Ignite Issue Type: Improvement Components: security Reporter: Ivan Gagarkin Creating a separate BasicAuthenticationProviderConfiguration for each user doesn't make sense. Instead, BasicAuthenticationProviderConfiguration should contain a list of users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20567) Move the 'enabled' flag from the authentication configuration to security
[ https://issues.apache.org/jira/browse/IGNITE-20567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-20567: -- Assignee: Ivan Gagarkin > Move the 'enabled' flag from the authentication configuration to security > - > > Key: IGNITE-20567 > URL: https://issues.apache.org/jira/browse/IGNITE-20567 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20567) Move the 'enabled' flag from the authentication configuration to security
Ivan Gagarkin created IGNITE-20567: -- Summary: Move the 'enabled' flag from the authentication configuration to security Key: IGNITE-20567 URL: https://issues.apache.org/jira/browse/IGNITE-20567 Project: Ignite Issue Type: Improvement Components: security Reporter: Ivan Gagarkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18942) Reactor library version conflict
[ https://issues.apache.org/jira/browse/IGNITE-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18942: --- Description: Scalecube and Micronaut use different versions of the Reactor library: 3.5.0 and 3.4.9, respectively. Currently, Gradle is using the newer version. However, we may need to consider shadowing one of the versions to avoid conflicts. This issue must be resolved before the GA release. [https://lists.apache.org/thread/msh2q0g121lhcxmvdx15ks353dv03j4r] was: Scalecube and Micraonaut use different versions of the Reactor library - 3.5.0 and 3.4.9. Right now gradle uses the new one. But maybe it's worth shadowing one of them to avoid that conflict. We have to think and resolve it till the GA. https://lists.apache.org/thread/msh2q0g121lhcxmvdx15ks353dv03j4r > Reactor library version conflict > > > Key: IGNITE-18942 > URL: https://issues.apache.org/jira/browse/IGNITE-18942 > Project: Ignite > Issue Type: Task > Components: rest >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Scalecube and Micronaut use different versions of the Reactor library: 3.5.0 > and 3.4.9, respectively. > Currently, Gradle is using the newer version. > However, we may need to consider shadowing one of the versions to avoid > conflicts. > This issue must be resolved before the GA release. > [https://lists.apache.org/thread/msh2q0g121lhcxmvdx15ks353dv03j4r] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20533) Implement AuthenticationRequest validation in AuthenticationManagerImpl when authentication is enabled
Ivan Gagarkin created IGNITE-20533:
--
Summary: Implement AuthenticationRequest validation in
AuthenticationManagerImpl when authentication is enabled
Key: IGNITE-20533
URL: https://issues.apache.org/jira/browse/IGNITE-20533
Project: Ignite
Issue Type: Improvement
Components: security
Reporter: Ivan Gagarkin
Assignee: Ivan Gagarkin
Currently, the
{{org.apache.ignite.internal.security.authentication.AuthenticationManagerImpl}}
class attempts to authenticate users even when authentication is enabled, but
the {{AuthenticationRequest}} contains an empty username and password.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20522) There should be a default user, if authentication is enabled
Ivan Gagarkin created IGNITE-20522: -- Summary: There should be a default user, if authentication is enabled Key: IGNITE-20522 URL: https://issues.apache.org/jira/browse/IGNITE-20522 Project: Ignite Issue Type: Improvement Components: security Reporter: Ivan Gagarkin Assignee: Ivan Gagarkin We need to add a default user with the credentials "ignite/ignite" for authentication purposes. Additionally, the enabled flag should be moved to the top level of the security configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20521) Separate Security API into its own module
Ivan Gagarkin created IGNITE-20521:
--
Summary: Separate Security API into its own module
Key: IGNITE-20521
URL: https://issues.apache.org/jira/browse/IGNITE-20521
Project: Ignite
Issue Type: Improvement
Components: security
Reporter: Ivan Gagarkin
Assignee: Ivan Gagarkin
Currently, the {{ignite-security}} module contains configurations, interfaces,
and implementations. The Security API should be split out to simplify the
integration process with other modules.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20409) Refactor org.apache.ignite.Ignition#init
[
https://issues.apache.org/jira/browse/IGNITE-20409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20409:
---
Description:
In the current implementation, the method {{org.apache.ignite.Ignition#init}}
accepts an instance of {{{}org.apache.ignite.InitParameters{}}}. Within this
parameter object, there's a field called {{{}destinationNodeName{}}}. After
reviewing the API consistency and internal usage, it appears that the current
structure might be over-complicated and inconsistent with other methods of the
{{Ignition}} class.Proposed Changes: # Refactor the
{{org.apache.ignite.Ignition#init}} method to accept {{destinationNodeName}} as
a direct parameter rather than as part of the {{InitParameters}} object.
# Update the {{InitParameters}} class to remove the {{destinationNodeName}}
field.
# Update tests which are affected by these changes.
Rationale:
* Enhances API clarity by reducing the complexity of method parameters.
* Makes the method signature more consistent with other methods in the
{{Ignition}} class.
* Provides flexibility for internal usage of the {{InitParameters}} without
the node name.
was:
In the current implementation, the method {{org.apache.ignite.Ignition#init}}
accepts an instance of {{{}org.apache.ignite.InitParameters{}}}. Within this
parameter object, there's a field called {{{}destinationNodeName{}}}. After
reviewing the API consistency and internal usage, it appears that the current
structure might be over-complicated and inconsistent with other methods of the
{{Ignition}} class.Proposed Changes: # Refactor the
{{org.apache.ignite.Ignition#init}} method to accept {{destinationNodeName}} as
a direct parameter rather than as part of the {{InitParameters}} object.
# Update the {{InitParameters}} class to remove the {{destinationNodeName}}
field.
# Update tests which are affected by these changes.
Rationale: * Enhances API clarity by reducing the complexity of method
parameters.
* Makes the method signature more consistent with other methods in the
{{Ignition}} class.
* Provides flexibility for internal usage of the {{InitParameters}} without
the node name.
> Refactor org.apache.ignite.Ignition#init
>
>
> Key: IGNITE-20409
> URL: https://issues.apache.org/jira/browse/IGNITE-20409
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> In the current implementation, the method {{org.apache.ignite.Ignition#init}}
> accepts an instance of {{{}org.apache.ignite.InitParameters{}}}. Within this
> parameter object, there's a field called {{{}destinationNodeName{}}}. After
> reviewing the API consistency and internal usage, it appears that the current
> structure might be over-complicated and inconsistent with other methods of
> the {{Ignition}} class.Proposed Changes: # Refactor the
> {{org.apache.ignite.Ignition#init}} method to accept {{destinationNodeName}}
> as a direct parameter rather than as part of the {{InitParameters}} object.
> # Update the {{InitParameters}} class to remove the {{destinationNodeName}}
> field.
> # Update tests which are affected by these changes.
> Rationale:
> * Enhances API clarity by reducing the complexity of method parameters.
> * Makes the method signature more consistent with other methods in the
> {{Ignition}} class.
> * Provides flexibility for internal usage of the {{InitParameters}} without
> the node name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20409) Refactor org.apache.ignite.Ignition#init
[
https://issues.apache.org/jira/browse/IGNITE-20409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-20409:
--
Assignee: Ivan Gagarkin
> Refactor org.apache.ignite.Ignition#init
>
>
> Key: IGNITE-20409
> URL: https://issues.apache.org/jira/browse/IGNITE-20409
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> In the current implementation, the method {{org.apache.ignite.Ignition#init}}
> accepts an instance of {{{}org.apache.ignite.InitParameters{}}}. Within this
> parameter object, there's a field called {{{}destinationNodeName{}}}. After
> reviewing the API consistency and internal usage, it appears that the current
> structure might be over-complicated and inconsistent with other methods of
> the {{Ignition}} class.Proposed Changes: # Refactor the
> {{org.apache.ignite.Ignition#init}} method to accept {{destinationNodeName}}
> as a direct parameter rather than as part of the {{InitParameters}} object.
> # Update the {{InitParameters}} class to remove the {{destinationNodeName}}
> field.
> # Update tests which are affected by these changes.
> Rationale: * Enhances API clarity by reducing the complexity of method
> parameters.
> * Makes the method signature more consistent with other methods in the
> {{Ignition}} class.
> * Provides flexibility for internal usage of the {{InitParameters}} without
> the node name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20409) Refactor org.apache.ignite.Ignition#init
Ivan Gagarkin created IGNITE-20409:
--
Summary: Refactor org.apache.ignite.Ignition#init
Key: IGNITE-20409
URL: https://issues.apache.org/jira/browse/IGNITE-20409
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Gagarkin
In the current implementation, the method {{org.apache.ignite.Ignition#init}}
accepts an instance of {{{}org.apache.ignite.InitParameters{}}}. Within this
parameter object, there's a field called {{{}destinationNodeName{}}}. After
reviewing the API consistency and internal usage, it appears that the current
structure might be over-complicated and inconsistent with other methods of the
{{Ignition}} class.Proposed Changes: # Refactor the
{{org.apache.ignite.Ignition#init}} method to accept {{destinationNodeName}} as
a direct parameter rather than as part of the {{InitParameters}} object.
# Update the {{InitParameters}} class to remove the {{destinationNodeName}}
field.
# Update tests which are affected by these changes.
Rationale: * Enhances API clarity by reducing the complexity of method
parameters.
* Makes the method signature more consistent with other methods in the
{{Ignition}} class.
* Provides flexibility for internal usage of the {{InitParameters}} without
the node name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20374) ItFileTransferTest fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-20374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-20374:
--
Assignee: Ivan Gagarkin
> ItFileTransferTest fails on Windows
> ---
>
> Key: IGNITE-20374
> URL: https://issues.apache.org/jira/browse/IGNITE-20374
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> Some tests in the scope of the ItFileTransferTest
> [downloadFilesWhenDoNotHaveAccessToWrite, downloadNonReadableFiles,
> uploadFilesWhenDoNotHaveAccessToWrite, uploadNonReadableFiles] fail with the
> following error:
> {code:java}
> java.lang.AssertionError: Expected: a future that completes with an exception
> that is an instance of
> org.apache.ignite.internal.network.file.exception.FileTransferException and
> error message that contains a string containing "Failed to create a file
> transfer stream" but: was completed successfully java.lang.AssertionError:
> Expected: a future that completes with an exception that is an instance of
> org.apache.ignite.internal.network.file.exception.FileTransferException and
> error message that contains a string containing "Failed to create a file
> transfer stream" but: was completed successfully{code}
> The reason of these failures on the Windows platform can be caused by the
> fact that File.setReadable() method may not work as is.
> {quote}A convenience method to set the owner's read permission for this
> abstract pathname.
> On some platforms it may be possible to start the Java virtual machine with
> special privileges
> that allow it to read files that are marked as unreadable.
> {quote}
> I think these tests can be disabled on Windows using @DisabledOnOs(OS.WINDOWS)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20374) ItFileTransferTest fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-20374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20374:
---
Description:
Some tests in the scope of the ItFileTransferTest
[downloadFilesWhenDoNotHaveAccessToWrite, downloadNonReadableFiles,
uploadFilesWhenDoNotHaveAccessToWrite, uploadNonReadableFiles] fail with the
following error:
{code:java}
java.lang.AssertionError: Expected: a future that completes with an exception
that is an instance of
org.apache.ignite.internal.network.file.exception.FileTransferException and
error message that contains a string containing "Failed to create a file
transfer stream" but: was completed successfully java.lang.AssertionError:
Expected: a future that completes with an exception that is an instance of
org.apache.ignite.internal.network.file.exception.FileTransferException and
error message that contains a string containing "Failed to create a file
transfer stream" but: was completed successfully{code}
The reason of these failures on the Windows platform can be caused by the fact
that File.setReadable() method may not work as is.
{quote}A convenience method to set the owner's read permission for this
abstract pathname.
On some platforms it may be possible to start the Java virtual machine with
special privileges
that allow it to read files that are marked as unreadable.
{quote}
I think these tests can be disabled on Windows using @DisabledOnOs(OS.WINDOWS)
was:
Some tests in the scope of the ItFileTransferTest
[downloadFilesWhenDoNotHaveAccessToWrite, downloadNonReadableFiles,
uploadFilesWhenDoNotHaveAccessToWrite, uploadNonReadableFiles] fail with the
following error:
{{}}
{code:java}
java.lang.AssertionError: Expected: a future that completes with an exception
that is an instance of
org.apache.ignite.internal.network.file.exception.FileTransferException and
error message that contains a string containing "Failed to create a file
transfer stream" but: was completed successfully java.lang.AssertionError:
Expected: a future that completes with an exception that is an instance of
org.apache.ignite.internal.network.file.exception.FileTransferException and
error message that contains a string containing "Failed to create a file
transfer stream" but: was completed successfully{code}
{{}}
The reason of these failures on the Windows platform can be caused by the fact
that File.setReadable() method may not work as is.
{quote}{{A convenience method to set the owner's read permission for this
abstract pathname.
On some platforms it may be possible to start the Java virtual machine with
special privileges
that allow it to read files that are marked as unreadable.}}
{quote}
I think these tests can be disabled on Windows using @DisabledOnOs(OS.WINDOWS)
> ItFileTransferTest fails on Windows
> ---
>
> Key: IGNITE-20374
> URL: https://issues.apache.org/jira/browse/IGNITE-20374
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> Some tests in the scope of the ItFileTransferTest
> [downloadFilesWhenDoNotHaveAccessToWrite, downloadNonReadableFiles,
> uploadFilesWhenDoNotHaveAccessToWrite, uploadNonReadableFiles] fail with the
> following error:
> {code:java}
> java.lang.AssertionError: Expected: a future that completes with an exception
> that is an instance of
> org.apache.ignite.internal.network.file.exception.FileTransferException and
> error message that contains a string containing "Failed to create a file
> transfer stream" but: was completed successfully java.lang.AssertionError:
> Expected: a future that completes with an exception that is an instance of
> org.apache.ignite.internal.network.file.exception.FileTransferException and
> error message that contains a string containing "Failed to create a file
> transfer stream" but: was completed successfully{code}
> The reason of these failures on the Windows platform can be caused by the
> fact that File.setReadable() method may not work as is.
> {quote}A convenience method to set the owner's read permission for this
> abstract pathname.
> On some platforms it may be possible to start the Java virtual machine with
> special privileges
> that allow it to read files that are marked as unreadable.
> {quote}
> I think these tests can be disabled on Windows using @DisabledOnOs(OS.WINDOWS)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20374) ItFileTransferTest fails on Windows
Ivan Gagarkin created IGNITE-20374:
--
Summary: ItFileTransferTest fails on Windows
Key: IGNITE-20374
URL: https://issues.apache.org/jira/browse/IGNITE-20374
Project: Ignite
Issue Type: Bug
Reporter: Ivan Gagarkin
Some tests in the scope of the ItFileTransferTest
[downloadFilesWhenDoNotHaveAccessToWrite, downloadNonReadableFiles,
uploadFilesWhenDoNotHaveAccessToWrite, uploadNonReadableFiles] fail with the
following error:
{{}}
{code:java}
java.lang.AssertionError: Expected: a future that completes with an exception
that is an instance of
org.apache.ignite.internal.network.file.exception.FileTransferException and
error message that contains a string containing "Failed to create a file
transfer stream" but: was completed successfully java.lang.AssertionError:
Expected: a future that completes with an exception that is an instance of
org.apache.ignite.internal.network.file.exception.FileTransferException and
error message that contains a string containing "Failed to create a file
transfer stream" but: was completed successfully{code}
{{}}
The reason of these failures on the Windows platform can be caused by the fact
that File.setReadable() method may not work as is.
{quote}{{A convenience method to set the owner's read permission for this
abstract pathname.
On some platforms it may be possible to start the Java virtual machine with
special privileges
that allow it to read files that are marked as unreadable.}}
{quote}
I think these tests can be disabled on Windows using @DisabledOnOs(OS.WINDOWS)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-19490) Bump mockito's version
[ https://issues.apache.org/jira/browse/IGNITE-19490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin resolved IGNITE-19490. Release Note: Done as a part of IGNITE-19952 Resolution: Done > Bump mockito's version > --- > > Key: IGNITE-19490 > URL: https://issues.apache.org/jira/browse/IGNITE-19490 > Project: Ignite > Issue Type: Task >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Currently, we use mockito 4.3.1, but there is a new one. Bump the version to > 5.3.1 or newer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20221) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin resolved IGNITE-20221.
Release Note: Duplicates IGNITE-20220
Resolution: Duplicate
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20221
> URL: https://issues.apache.org/jira/browse/IGNITE-20221
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
> which returns the week-based year (locale-specific) from a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin resolved IGNITE-20225.
Release Note: Duplicates IGNITE-20220
Resolution: Duplicate
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20225
> URL: https://issues.apache.org/jira/browse/IGNITE-20225
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week] when translating
> Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from
> a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> {quote}This function uses the {{ISO}} definition when first week of year
> should have at least four days and week is started with Monday.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20222) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin resolved IGNITE-20222.
Release Note: Duplicates IGNITE-20220
Resolution: Duplicate
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20222
> URL: https://issues.apache.org/jira/browse/IGNITE-20222
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
> which returns the week-based year (locale-specific) from a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20223) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin resolved IGNITE-20223.
Release Note: Duplicates IGNITE-20220
Resolution: Duplicate
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20223
> URL: https://issues.apache.org/jira/browse/IGNITE-20223
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
> which returns the week-based year (locale-specific) from a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20224) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin resolved IGNITE-20224.
Release Note: Duplicates IGNITE-20220
Resolution: Duplicate
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20224
> URL: https://issues.apache.org/jira/browse/IGNITE-20224
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
> which returns the week-based year (locale-specific) from a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20234) ignite-spark-ext: fix platform-dependent tests
[ https://issues.apache.org/jira/browse/IGNITE-20234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20234: --- Description: There are some platform-dependent tests: * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP The SQL EXP function with the same argument on different JVMs and OS can return results with different lengths. * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK The SQL function WEEK is dependent on the locale. Therefore, the expected result must not be hard-coded. We need to fix them. was: There are some platform-dependent tests: * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK We need to fix them. > ignite-spark-ext: fix platform-dependent tests > --- > > Key: IGNITE-20234 > URL: https://issues.apache.org/jira/browse/IGNITE-20234 > Project: Ignite > Issue Type: Bug > Components: spark >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > > There are some platform-dependent tests: > * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP > The SQL EXP function with the same argument on different JVMs and OS can > return results with different lengths. > * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK > The SQL function WEEK is dependent on the locale. Therefore, the expected > result must not be hard-coded. > We need to fix them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20234) ignite-spark-ext: fix platform-dependent tests
[ https://issues.apache.org/jira/browse/IGNITE-20234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20234: --- Component/s: spark > ignite-spark-ext: fix platform-dependent tests > --- > > Key: IGNITE-20234 > URL: https://issues.apache.org/jira/browse/IGNITE-20234 > Project: Ignite > Issue Type: Bug > Components: spark >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > > There are some platform-dependent tests: > * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP > * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK > We need to fix them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20225:
---
Description:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week] when translating
Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
{quote}This function uses the {{ISO}} definition when first week of year should
have at least four days and week is started with Monday.
{quote}
was:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
{quote}This function uses the {{ISO}} definition when first week of year should
have at least four days and week is started with Monday.
{quote}
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20225
> URL: https://issues.apache.org/jira/browse/IGNITE-20225
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week] when translating
> Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from
> a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> {quote}This function uses the {{ISO}} definition when first week of year
> should have at least four days and week is started with Monday.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20234) ignite-spark-ext: fix platform-dependent tests
[ https://issues.apache.org/jira/browse/IGNITE-20234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20234: --- Description: There are some platform-dependent tests: * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK We need to fix them. was:IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP > ignite-spark-ext: fix platform-dependent tests > --- > > Key: IGNITE-20234 > URL: https://issues.apache.org/jira/browse/IGNITE-20234 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Gagarkin >Priority: Major > > There are some platform-dependent tests: > * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP > * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK > We need to fix them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20234) ignite-spark-ext: fix platform-dependent tests
[ https://issues.apache.org/jira/browse/IGNITE-20234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-20234: -- Assignee: Ivan Gagarkin > ignite-spark-ext: fix platform-dependent tests > --- > > Key: IGNITE-20234 > URL: https://issues.apache.org/jira/browse/IGNITE-20234 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > > There are some platform-dependent tests: > * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP > * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK > We need to fix them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20234) ignite-spark-ext: fix platform-dependent tests
Ivan Gagarkin created IGNITE-20234: -- Summary: ignite-spark-ext: fix platform-dependent tests Key: IGNITE-20234 URL: https://issues.apache.org/jira/browse/IGNITE-20234 Project: Ignite Issue Type: Bug Reporter: Ivan Gagarkin IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20225:
---
Description:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
{quote}This function uses the {{ISO}} definition when first week of year should
have at least four days and week is started with Monday.
{quote}
was:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20225
> URL: https://issues.apache.org/jira/browse/IGNITE-20225
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
> Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from
> a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> {quote}This function uses the {{ISO}} definition when first week of year
> should have at least four days and week is started with Monday.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20225:
---
Description:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translate
Spqrk SQL to H2 SQL which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
was:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],], which returns the
week-based year (locale-specific) from a date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20225
> URL: https://issues.apache.org/jira/browse/IGNITE-20225
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],] when translate
> Spqrk SQL to H2 SQL which returns the week-based year (locale-specific) from
> a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20225:
---
Description:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
was:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translate
Spqrk SQL to H2 SQL which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20225
> URL: https://issues.apache.org/jira/browse/IGNITE-20225
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
> Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from
> a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20225:
---
Description:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],], which returns the
week-based year (locale-specific) from a date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
was:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
which returns the week-based year (locale-specific) from a date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20225
> URL: https://issues.apache.org/jira/browse/IGNITE-20225
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],], which returns
> the week-based year (locale-specific) from a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
Ivan Gagarkin created IGNITE-20225:
--
Summary: ignite-spark-ext: 'select weekofyear' returns incorrect
week number based on local rules
Key: IGNITE-20225
URL: https://issues.apache.org/jira/browse/IGNITE-20225
Project: Ignite
Issue Type: Bug
Components: spark
Reporter: Ivan Gagarkin
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
which returns the week-based year (locale-specific) from a date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20223) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
Ivan Gagarkin created IGNITE-20223:
--
Summary: ignite-spark-ext: 'select weekofyear' returns incorrect
week number based on local rules
Key: IGNITE-20223
URL: https://issues.apache.org/jira/browse/IGNITE-20223
Project: Ignite
Issue Type: Bug
Components: spark
Reporter: Ivan Gagarkin
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
which returns the week-based year (locale-specific) from a date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20222) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
Ivan Gagarkin created IGNITE-20222:
--
Summary: ignite-spark-ext: 'select weekofyear' returns incorrect
week number based on local rules
Key: IGNITE-20222
URL: https://issues.apache.org/jira/browse/IGNITE-20222
Project: Ignite
Issue Type: Bug
Components: spark
Reporter: Ivan Gagarkin
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
which returns the week-based year (locale-specific) from a date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20224) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
Ivan Gagarkin created IGNITE-20224:
--
Summary: ignite-spark-ext: 'select weekofyear' returns incorrect
week number based on local rules
Key: IGNITE-20224
URL: https://issues.apache.org/jira/browse/IGNITE-20224
Project: Ignite
Issue Type: Bug
Components: spark
Reporter: Ivan Gagarkin
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
which returns the week-based year (locale-specific) from a date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20221) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
Ivan Gagarkin created IGNITE-20221:
--
Summary: ignite-spark-ext: 'select weekofyear' returns incorrect
week number based on local rules
Key: IGNITE-20221
URL: https://issues.apache.org/jira/browse/IGNITE-20221
Project: Ignite
Issue Type: Bug
Components: spark
Reporter: Ivan Gagarkin
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
which returns the week-based year (locale-specific) from a date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20220) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
Ivan Gagarkin created IGNITE-20220:
--
Summary: ignite-spark-ext: 'select weekofyear' returns incorrect
week number based on local rules
Key: IGNITE-20220
URL: https://issues.apache.org/jira/browse/IGNITE-20220
Project: Ignite
Issue Type: Bug
Components: spark
Reporter: Ivan Gagarkin
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],|http://www.h2database.com/html/grammar.html#week_year_field],]
which returns the week-based year (locale-specific) from a date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20208) Reduce the size of FileChunkMessage
[ https://issues.apache.org/jira/browse/IGNITE-20208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20208: --- Summary: Reduce the size of FileChunkMessage (was: Reduce the size of ) > Reduce the size of FileChunkMessage > --- > > Key: IGNITE-20208 > URL: https://issues.apache.org/jira/browse/IGNITE-20208 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > We can decrease the size of > org.apache.ignite.internal.network.file.messages.FileChunkMessage by > replacing file names with file ids. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20208) Reduce the size of
[ https://issues.apache.org/jira/browse/IGNITE-20208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20208: --- Summary: Reduce the size of (was: Use file ids instead of file names when transferring file chunks) > Reduce the size of > --- > > Key: IGNITE-20208 > URL: https://issues.apache.org/jira/browse/IGNITE-20208 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > We can decrease the size of > org.apache.ignite.internal.network.file.messages.FileChunkMessage by > replacing file names with file ids. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20203) File transfer for Ignite 3
[
https://issues.apache.org/jira/browse/IGNITE-20203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20203:
---
Description:
In the outcome of IGNITE-19009, we obtained the new module
{{{}ignite-file-transfer{}}}.
All file transfers in Ignite 3 should utilize the new service,
FileTransferService. Additionally, there are some aspects of the service that
need improvement.
was:As outcome of IGNITE-19009, we
> File transfer for Ignite 3
> --
>
> Key: IGNITE-20203
> URL: https://issues.apache.org/jira/browse/IGNITE-20203
> Project: Ignite
> Issue Type: Epic
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> In the outcome of IGNITE-19009, we obtained the new module
> {{{}ignite-file-transfer{}}}.
> All file transfers in Ignite 3 should utilize the new service,
> FileTransferService. Additionally, there are some aspects of the service that
> need improvement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20203) File transfer for Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-20203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20203: --- Description: As outcome of IGNITE-19009, we (was: As outcome of ) > File transfer for Ignite 3 > -- > > Key: IGNITE-20203 > URL: https://issues.apache.org/jira/browse/IGNITE-20203 > Project: Ignite > Issue Type: Epic >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > As outcome of IGNITE-19009, we -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20203) File transfer for Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-20203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20203: --- Description: As outcome of > File transfer for Ignite 3 > -- > > Key: IGNITE-20203 > URL: https://issues.apache.org/jira/browse/IGNITE-20203 > Project: Ignite > Issue Type: Epic >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > As outcome of -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20207) Improve the error handling
[ https://issues.apache.org/jira/browse/IGNITE-20207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20207: --- Description: The current implementation of org.apache.ignite.internal.network.file.FileTransferService doesn't provide recovery functionality. Any error during file transfer leads to repeating the transfer from scratch. We need to define cases when Ignite can provide recovery and implement this functionality. (was: The current implementation of org.apache.ignite.internal.network.file.FileTransferService doesn't provide recovery functionality. Any error during file transfer leads to repeating the transfer from scratch. ) > Improve the error handling > -- > > Key: IGNITE-20207 > URL: https://issues.apache.org/jira/browse/IGNITE-20207 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > The current implementation of > org.apache.ignite.internal.network.file.FileTransferService doesn't provide > recovery functionality. Any error during file transfer leads to repeating the > transfer from scratch. We need to define cases when Ignite can provide > recovery and implement this functionality. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20207) Improve the error handling
[
https://issues.apache.org/jira/browse/IGNITE-20207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20207:
---
Description: The current implementation of
org.apache.ignite.internal.network.file.FileTransferService doesn't provide
recovery functionality. Any error during file transfer leads to repeat the
transfer from scratch. (was: The current implementation of
{{org.apache.ignite.internal.network.file.ChunkedFileWriter}} compares the file
pointer with the offset of the received file chunk. If they are equal, the
chunk is written to the disk; if not, the chunk is placed in the queue, and it
will be written when all previous chunks have been written.
It might be more efficient to write chunks instantly.
We should investigate this approach and improve the implementation.)
> Improve the error handling
> --
>
> Key: IGNITE-20207
> URL: https://issues.apache.org/jira/browse/IGNITE-20207
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> The current implementation of
> org.apache.ignite.internal.network.file.FileTransferService doesn't provide
> recovery functionality. Any error during file transfer leads to repeat the
> transfer from scratch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20207) Improve the error handling
[ https://issues.apache.org/jira/browse/IGNITE-20207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20207: --- Description: The current implementation of org.apache.ignite.internal.network.file.FileTransferService doesn't provide recovery functionality. Any error during file transfer leads to repeating the transfer from scratch. (was: The current implementation of org.apache.ignite.internal.network.file.FileTransferService doesn't provide recovery functionality. Any error during file transfer leads to repeat the transfer from scratch. ) > Improve the error handling > -- > > Key: IGNITE-20207 > URL: https://issues.apache.org/jira/browse/IGNITE-20207 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > The current implementation of > org.apache.ignite.internal.network.file.FileTransferService doesn't provide > recovery functionality. Any error during file transfer leads to repeating the > transfer from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20207) Improve the error handling
[
https://issues.apache.org/jira/browse/IGNITE-20207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20207:
---
Summary: Improve the error handling (was: Improve the writing of files in
FileTransferService)
> Improve the error handling
> --
>
> Key: IGNITE-20207
> URL: https://issues.apache.org/jira/browse/IGNITE-20207
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> The current implementation of
> {{org.apache.ignite.internal.network.file.ChunkedFileWriter}} compares the
> file pointer with the offset of the received file chunk. If they are equal,
> the chunk is written to the disk; if not, the chunk is placed in the queue,
> and it will be written when all previous chunks have been written.
> It might be more efficient to write chunks instantly.
> We should investigate this approach and improve the implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20208) Use file ids instead of file names when transferring file chunks
Ivan Gagarkin created IGNITE-20208: -- Summary: Use file ids instead of file names when transferring file chunks Key: IGNITE-20208 URL: https://issues.apache.org/jira/browse/IGNITE-20208 Project: Ignite Issue Type: Improvement Reporter: Ivan Gagarkin We can decrease the size of org.apache.ignite.internal.network.file.messages.FileChunkMessage by replacing file names with file ids. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20207) Improve the writing of files in FileTransferService
Ivan Gagarkin created IGNITE-20207:
--
Summary: Improve the writing of files in FileTransferService
Key: IGNITE-20207
URL: https://issues.apache.org/jira/browse/IGNITE-20207
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Gagarkin
The current implementation of
{{org.apache.ignite.internal.network.file.ChunkedFileWriter}} compares the file
pointer with the offset of the received file chunk. If they are equal, the
chunk is written to the disk; if not, the chunk is placed in the queue, and it
will be written when all previous chunks have been written.
It might be more efficient to write chunks instantly.
We should investigate this approach and improve the implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20206) Improve parallelism the sending of files in FileTransferService
[
https://issues.apache.org/jira/browse/IGNITE-20206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20206:
---
Summary: Improve parallelism the sending of files in FileTransferService
(was: Improve parallelism of sending files in FileTransferService)
> Improve parallelism the sending of files in FileTransferService
> ---
>
> Key: IGNITE-20206
> URL: https://issues.apache.org/jira/browse/IGNITE-20206
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> The current implementation of
> {{org.apache.ignite.internal.network.file.FileSender}} has parallelism at the
> file level. It works well when there are many files to send. It may be worth
> improving by implementing parallelism at the file chunk level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20206) Improve parallelism of sending files in FileTransferService
[
https://issues.apache.org/jira/browse/IGNITE-20206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20206:
---
Summary: Improve parallelism of sending files in FileTransferService (was:
Improve parallelism in FileTransferService on the file chunks level)
> Improve parallelism of sending files in FileTransferService
> ---
>
> Key: IGNITE-20206
> URL: https://issues.apache.org/jira/browse/IGNITE-20206
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> The current implementation of
> {{org.apache.ignite.internal.network.file.FileSender}} has parallelism at the
> file level. It works well when there are many files to send. It may be worth
> improving by implementing parallelism at the file chunk level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20206) Improve parallelism in FileTransferService on the file chunks level
[
https://issues.apache.org/jira/browse/IGNITE-20206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20206:
---
Description: The current implementation of
{{org.apache.ignite.internal.network.file.FileSender}} has parallelism at the
file level. It works well when there are many files to send. It may be worth
improving by implementing parallelism at the file chunk level. (was: The
current implementation of
`{{{}org.apache.ignite.internal.network.file.FileSender`{}}} has parallelism at
the file level. It works well when there are many files to send. It may be
worth improving by implementing parallelism at the file chunk level.)
> Improve parallelism in FileTransferService on the file chunks level
> ---
>
> Key: IGNITE-20206
> URL: https://issues.apache.org/jira/browse/IGNITE-20206
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> The current implementation of
> {{org.apache.ignite.internal.network.file.FileSender}} has parallelism at the
> file level. It works well when there are many files to send. It may be worth
> improving by implementing parallelism at the file chunk level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20206) Improve parallelism in FileTransferService on the file chunks level
Ivan Gagarkin created IGNITE-20206:
--
Summary: Improve parallelism in FileTransferService on the file
chunks level
Key: IGNITE-20206
URL: https://issues.apache.org/jira/browse/IGNITE-20206
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Gagarkin
The current implementation of
`{{{}org.apache.ignite.internal.network.file.FileSender`{}}} has parallelism at
the file level. It works well when there are many files to send. It may be
worth improving by implementing parallelism at the file chunk level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20204) Use FileTransferService for transfer deployment units between nodes
[ https://issues.apache.org/jira/browse/IGNITE-20204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20204: --- Description: Currently, Ignite 3 loads deployment units content to the heap as byte[] when transferring units between nodes. This is a potentially easy way of OOM. We should replace the deployment transferring mechanism with FileTransferService. was: Currently, Ignite 3 loads deployment units content to the heap as byte[] when transferring units between nodes. This is a potentially easy way of OOM. We should replace deployment transferring mechanism by FileTransferService. > Use FileTransferService for transfer deployment units between nodes > --- > > Key: IGNITE-20204 > URL: https://issues.apache.org/jira/browse/IGNITE-20204 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Currently, Ignite 3 loads deployment units content to the heap as byte[] when > transferring units between nodes. This is a potentially easy way of OOM. > We should replace the deployment transferring mechanism with > FileTransferService. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20204) Use FileTransferService for transfer deployment units between nodes
[ https://issues.apache.org/jira/browse/IGNITE-20204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20204: --- Description: Currently, Ignite 3 loads deployment units content to the heap as byte[] when transferring units between nodes. This is a potentially easy way of OOM. We should replace deployment transferring mechanism by FileTransferService. was: Currently, Ignite 3 loads deployment units content to the heap as byte[] when transferring units between nodes. This is a potentially easy way of OOM. We should replace deployment transferring mechanism by > Use FileTransferService for transfer deployment units between nodes > --- > > Key: IGNITE-20204 > URL: https://issues.apache.org/jira/browse/IGNITE-20204 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Currently, Ignite 3 loads deployment units content to the heap as byte[] when > transferring units between nodes. This is a potentially easy way of OOM. > We should replace deployment transferring mechanism by FileTransferService. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20204) Use FileTransferService for transfer deployment units between nodes
[ https://issues.apache.org/jira/browse/IGNITE-20204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20204: --- Description: Currently, Ignite 3 loads deployment units content to the heap as byte[] when transferring units between nodes. This is a potentially easy way of OOM. We should replace deployment transferring mechanism by was: Currently, Ignite 3 loads deployment units content to the heap as byte[] when transfer units The current implementation of Network forces to load deployment unit content to the heap as byte[]. This is a potentially easy way of OOM. > Use FileTransferService for transfer deployment units between nodes > --- > > Key: IGNITE-20204 > URL: https://issues.apache.org/jira/browse/IGNITE-20204 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Currently, Ignite 3 loads deployment units content to the heap as byte[] when > transferring units between nodes. This is a potentially easy way of OOM. > We should replace deployment transferring mechanism by > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20204) Use FileTransferService for transfer deployment units between nodes
[ https://issues.apache.org/jira/browse/IGNITE-20204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20204: --- Description: Currently, Ignite 3 loads deployment units content to the heap as byte[] when transfer units The current implementation of Network forces to load deployment unit content to the heap as byte[]. This is a potentially easy way of OOM. was: The current implementation of Network forces to load deployment unit content to the heap as byte[]. This is a potentially easy way of OOM. > Use FileTransferService for transfer deployment units between nodes > --- > > Key: IGNITE-20204 > URL: https://issues.apache.org/jira/browse/IGNITE-20204 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Currently, Ignite 3 loads deployment units content to the heap as byte[] when > transfer units > The current implementation of Network forces to load deployment unit content > to the heap as byte[]. This is a potentially easy way of OOM. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20204) Use FileTransferService for transfer deployment units between nodes
[ https://issues.apache.org/jira/browse/IGNITE-20204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20204: --- Description: Current implemenatation of Network force to load deployment unit content to heap as byte[]. This is a potential easy way of OOM. > Use FileTransferService for transfer deployment units between nodes > --- > > Key: IGNITE-20204 > URL: https://issues.apache.org/jira/browse/IGNITE-20204 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Current implemenatation of Network force to load deployment unit content to > heap as byte[]. This is a potential easy way of OOM. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
