[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. > * Unab
[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 > org.junit.platform.engine.support.hierarchical.ThrowableC
[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&focusedCommentId=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 > org.junit.jupiter.e
[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 org.junit.platform.engine.support.hierarchical.Nod
[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 org.junit.platform.engine.support.hierarchical.NodeTestT
[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)