[jira] [Comment Edited] (IGNITE-21059) We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running cache operations
[ https://issues.apache.org/jira/browse/IGNITE-21059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795616#comment-17795616 ] Vipul Thakur edited comment on IGNITE-21059 at 12/12/23 6:59 AM: - [~cos] Please help in review was (Author: vipul.thakur): @cos Please help in review > We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running > cache operations > > > Key: IGNITE-21059 > URL: https://issues.apache.org/jira/browse/IGNITE-21059 > Project: Ignite > Issue Type: Bug > Components: binary, clients >Affects Versions: 2.14 >Reporter: Vipul Thakur >Priority: Critical > Attachments: cache-config-1.xml, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt2, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt3, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt2, > ignite-server-nohup.out > > > We have recently upgraded from 2.7.6 to 2.14 due to the issue observed in > production environment where cluster would go in hang state due to partition > map exchange. > Please find the below ticket which i created a while back for ignite 2.7.6 > https://issues.apache.org/jira/browse/IGNITE-13298 > So we migrated the apache ignite version to 2.14 and upgrade happened > smoothly but on the third day we could see cluster traffic dip again. > We have 4 nodes in a cluster where we provide 400 GB of RAM and more than 1 > TB HDD. > PFB for the attached config.[I have added it as attachment for review] > I have also added the server logs from the same time when issue happened. > We have set txn timeout as well as socket timeout both at server and client > end for our write operations but seems like sometimes cluster goes into hang > state and all our get calls are stuck and slowly everything starts to freeze > our jms listener threads and every thread reaches a choked up state in > sometime. > Due to which our read services which does not even use txn to retrieve data > also starts to choke. Ultimately leading to end user traffic dip. > We were hoping product upgrade will help but that has not been the case till > now. > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21059) We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running cache operations
[ https://issues.apache.org/jira/browse/IGNITE-21059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795616#comment-17795616 ] Vipul Thakur commented on IGNITE-21059: --- @cos Please help in review > We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running > cache operations > > > Key: IGNITE-21059 > URL: https://issues.apache.org/jira/browse/IGNITE-21059 > Project: Ignite > Issue Type: Bug > Components: binary, clients >Affects Versions: 2.14 >Reporter: Vipul Thakur >Priority: Critical > Attachments: cache-config-1.xml, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt2, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt3, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt2, > ignite-server-nohup.out > > > We have recently upgraded from 2.7.6 to 2.14 due to the issue observed in > production environment where cluster would go in hang state due to partition > map exchange. > Please find the below ticket which i created a while back for ignite 2.7.6 > https://issues.apache.org/jira/browse/IGNITE-13298 > So we migrated the apache ignite version to 2.14 and upgrade happened > smoothly but on the third day we could see cluster traffic dip again. > We have 4 nodes in a cluster where we provide 400 GB of RAM and more than 1 > TB HDD. > PFB for the attached config.[I have added it as attachment for review] > I have also added the server logs from the same time when issue happened. > We have set txn timeout as well as socket timeout both at server and client > end for our write operations but seems like sometimes cluster goes into hang > state and all our get calls are stuck and slowly everything starts to freeze > our jms listener threads and every thread reaches a choked up state in > sometime. > Due to which our read services which does not even use txn to retrieve data > also starts to choke. Ultimately leading to end user traffic dip. > We were hoping product upgrade will help but that has not been the case till > now. > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21059) We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running cache operations
[ https://issues.apache.org/jira/browse/IGNITE-21059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vipul Thakur updated IGNITE-21059: -- Attachment: ignite-server-nohup.out > We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running > cache operations > > > Key: IGNITE-21059 > URL: https://issues.apache.org/jira/browse/IGNITE-21059 > Project: Ignite > Issue Type: Bug > Components: binary, clients >Affects Versions: 2.14 >Reporter: Vipul Thakur >Priority: Critical > Attachments: cache-config-1.xml, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt2, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt3, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt2, > ignite-server-nohup.out > > > We have recently upgraded from 2.7.6 to 2.14 due to the issue observed in > production environment where cluster would go in hang state due to partition > map exchange. > Please find the below ticket which i created a while back for ignite 2.7.6 > https://issues.apache.org/jira/browse/IGNITE-13298 > So we migrated the apache ignite version to 2.14 and upgrade happened > smoothly but on the third day we could see cluster traffic dip again. > We have 4 nodes in a cluster where we provide 400 GB of RAM and more than 1 > TB HDD. > PFB for the attached config.[I have added it as attachment for review] > We have set txn timeout as well as socket timeout both at server and client > end for our write operations but seems like sometimes cluster goes into hang > state and all our get calls are stuck and slowly everything starts to freeze > our jms listener threads and every thread reaches a choked up state in > sometime. > Due to which our read services which does not even use txn to retrieve data > also starts to choke. Ultimately leading to end user traffic dip. > We were hoping product upgrade will help but that has not been the case till > now. > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21059) We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running cache operations
[ https://issues.apache.org/jira/browse/IGNITE-21059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vipul Thakur updated IGNITE-21059: -- Description: We have recently upgraded from 2.7.6 to 2.14 due to the issue observed in production environment where cluster would go in hang state due to partition map exchange. Please find the below ticket which i created a while back for ignite 2.7.6 https://issues.apache.org/jira/browse/IGNITE-13298 So we migrated the apache ignite version to 2.14 and upgrade happened smoothly but on the third day we could see cluster traffic dip again. We have 4 nodes in a cluster where we provide 400 GB of RAM and more than 1 TB HDD. PFB for the attached config.[I have added it as attachment for review] I have also added the server logs from the same time when issue happened. We have set txn timeout as well as socket timeout both at server and client end for our write operations but seems like sometimes cluster goes into hang state and all our get calls are stuck and slowly everything starts to freeze our jms listener threads and every thread reaches a choked up state in sometime. Due to which our read services which does not even use txn to retrieve data also starts to choke. Ultimately leading to end user traffic dip. We were hoping product upgrade will help but that has not been the case till now. was: We have recently upgraded from 2.7.6 to 2.14 due to the issue observed in production environment where cluster would go in hang state due to partition map exchange. Please find the below ticket which i created a while back for ignite 2.7.6 https://issues.apache.org/jira/browse/IGNITE-13298 So we migrated the apache ignite version to 2.14 and upgrade happened smoothly but on the third day we could see cluster traffic dip again. We have 4 nodes in a cluster where we provide 400 GB of RAM and more than 1 TB HDD. PFB for the attached config.[I have added it as attachment for review] We have set txn timeout as well as socket timeout both at server and client end for our write operations but seems like sometimes cluster goes into hang state and all our get calls are stuck and slowly everything starts to freeze our jms listener threads and every thread reaches a choked up state in sometime. Due to which our read services which does not even use txn to retrieve data also starts to choke. Ultimately leading to end user traffic dip. We were hoping product upgrade will help but that has not been the case till now. > We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running > cache operations > > > Key: IGNITE-21059 > URL: https://issues.apache.org/jira/browse/IGNITE-21059 > Project: Ignite > Issue Type: Bug > Components: binary, clients >Affects Versions: 2.14 >Reporter: Vipul Thakur >Priority: Critical > Attachments: cache-config-1.xml, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt2, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt3, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt2, > ignite-server-nohup.out > > > We have recently upgraded from 2.7.6 to 2.14 due to the issue observed in > production environment where cluster would go in hang state due to partition > map exchange. > Please find the below ticket which i created a while back for ignite 2.7.6 > https://issues.apache.org/jira/browse/IGNITE-13298 > So we migrated the apache ignite version to 2.14 and upgrade happened > smoothly but on the third day we could see cluster traffic dip again. > We have 4 nodes in a cluster where we provide 400 GB of RAM and more than 1 > TB HDD. > PFB for the attached config.[I have added it as attachment for review] > I have also added the server logs from the same time when issue happened. > We have set txn timeout as well as socket timeout both at server and client > end for our write operations but seems like sometimes cluster goes into hang > state and all our get calls are stuck and slowly everything starts to freeze > our jms listener threads and every thread reaches a choked up state in > sometime. > Due to which our read services which does not even use txn to retrieve data > also starts to choke. Ultimately leading to end user traffic dip. > We were hoping product upgrade will help but that has not been the case till > now. > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21059) We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running cache operations
[ https://issues.apache.org/jira/browse/IGNITE-21059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795614#comment-17795614 ] Vipul Thakur commented on IGNITE-21059: --- Hi Please review and comment and let me know if more info is needed. > We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running > cache operations > > > Key: IGNITE-21059 > URL: https://issues.apache.org/jira/browse/IGNITE-21059 > Project: Ignite > Issue Type: Bug > Components: binary, clients >Affects Versions: 2.14 >Reporter: Vipul Thakur >Priority: Critical > Attachments: cache-config-1.xml, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt2, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt3, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt2 > > > We have recently upgraded from 2.7.6 to 2.14 due to the issue observed in > production environment where cluster would go in hang state due to partition > map exchange. > Please find the below ticket which i created a while back for ignite 2.7.6 > https://issues.apache.org/jira/browse/IGNITE-13298 > So we migrated the apache ignite version to 2.14 and upgrade happened > smoothly but on the third day we could see cluster traffic dip again. > We have 4 nodes in a cluster where we provide 400 GB of RAM and more than 1 > TB HDD. > PFB for the attached config.[I have added it as attachment for review] > We have set txn timeout as well as socket timeout both at server and client > end for our write operations but seems like sometimes cluster goes into hang > state and all our get calls are stuck and slowly everything starts to freeze > our jms listener threads and every thread reaches a choked up state in > sometime. > Due to which our read services which does not even use txn to retrieve data > also starts to choke. Ultimately leading to end user traffic dip. > We were hoping product upgrade will help but that has not been the case till > now. > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21059) We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running cache operations
Vipul Thakur created IGNITE-21059: - Summary: We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running cache operations Key: IGNITE-21059 URL: https://issues.apache.org/jira/browse/IGNITE-21059 Project: Ignite Issue Type: Bug Components: binary, clients Affects Versions: 2.14 Reporter: Vipul Thakur Attachments: cache-config-1.xml, digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt1, digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt2, digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt3, digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt1, digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt2 We have recently upgraded from 2.7.6 to 2.14 due to the issue observed in production environment where cluster would go in hang state due to partition map exchange. Please find the below ticket which i created a while back for ignite 2.7.6 https://issues.apache.org/jira/browse/IGNITE-13298 So we migrated the apache ignite version to 2.14 and upgrade happened smoothly but on the third day we could see cluster traffic dip again. We have 4 nodes in a cluster where we provide 400 GB of RAM and more than 1 TB HDD. PFB for the attached config.[I have added it as attachment for review] We have set txn timeout as well as socket timeout both at server and client end for our write operations but seems like sometimes cluster goes into hang state and all our get calls are stuck and slowly everything starts to freeze our jms listener threads and every thread reaches a choked up state in sometime. Due to which our read services which does not even use txn to retrieve data also starts to choke. Ultimately leading to end user traffic dip. We were hoping product upgrade will help but that has not been the case till now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20506) CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT removal
[ https://issues.apache.org/jira/browse/IGNITE-20506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795566#comment-17795566 ] YuJue Li commented on IGNITE-20506: --- [~av] I have added some corrections, could you please review them? > CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT removal > - > > Key: IGNITE-20506 > URL: https://issues.apache.org/jira/browse/IGNITE-20506 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: YuJue Li >Priority: Major > Labels: important > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-20506) CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT removal
[ https://issues.apache.org/jira/browse/IGNITE-20506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li reopened IGNITE-20506: --- Assignee: YuJue Li (was: Anton Vinogradov) > CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT removal > - > > Key: IGNITE-20506 > URL: https://issues.apache.org/jira/browse/IGNITE-20506 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: YuJue Li >Priority: Major > Labels: important > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21058) Avoid redundant metastorage invokes on rebalance triggers recovery
Kirill Gusakov created IGNITE-21058: --- Summary: Avoid redundant metastorage invokes on rebalance triggers recovery Key: IGNITE-21058 URL: https://issues.apache.org/jira/browse/IGNITE-21058 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21015) Add the security subject ID to the cluster state change event
[ https://issues.apache.org/jira/browse/IGNITE-21015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21015: Labels: ise (was: ) > Add the security subject ID to the cluster state change event > - > > Key: IGNITE-21015 > URL: https://issues.apache.org/jira/browse/IGNITE-21015 > Project: Ignite > Issue Type: Task >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Minor > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > Add the security subject ID to the cluster state change event to track > initiator. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20748) Document new flags for JDK 11 and JDK 17
[ https://issues.apache.org/jira/browse/IGNITE-20748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-20748: Labels: documentation ise (was: documentation) > Document new flags for JDK 11 and JDK 17 > > > Key: IGNITE-20748 > URL: https://issues.apache.org/jira/browse/IGNITE-20748 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Ivan Daschinsky >Assignee: Igor Gusev >Priority: Major > Labels: documentation, ise > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21041) FilteredRecord instance must be local to RecordSerializer
[ https://issues.apache.org/jira/browse/IGNITE-21041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21041: Labels: ise (was: ) > FilteredRecord instance must be local to RecordSerializer > - > > Key: IGNITE-21041 > URL: https://issues.apache.org/jira/browse/IGNITE-21041 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > > In case of concurrent run WALIterators they concurrent for > FilteredRecord#size field. Then FilteredRecord must be singleton in context > of single RecordSerializer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21042) Move #toLong to IgniteUtils class
[ https://issues.apache.org/jira/browse/IGNITE-21042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21042: Labels: ise (was: ) > Move #toLong to IgniteUtils class > - > > Key: IGNITE-21042 > URL: https://issues.apache.org/jira/browse/IGNITE-21042 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > > toLong is a useful method, should be moved to IgniteUtils -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21046) Move binaryMetadataUpdateListener to basic interface
[ https://issues.apache.org/jira/browse/IGNITE-21046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21046: Labels: ise (was: ) > Move binaryMetadataUpdateListener to basic interface > > > Key: IGNITE-21046 > URL: https://issues.apache.org/jira/browse/IGNITE-21046 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20822) Refactoring WALIterator filter by higher bound
[ https://issues.apache.org/jira/browse/IGNITE-20822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-20822: Labels: ise (was: ) > Refactoring WALIterator filter by higher bound > -- > > Key: IGNITE-20822 > URL: https://issues.apache.org/jira/browse/IGNITE-20822 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently filter by higher bound has different implementation in WAL iterator > implementations: > # Standalone filters by self. It has a little bug - one excess iteration > over underlying iterator to check bounds. > # RecordsIterator filters only by index of higherBound. It might be > dangerous in concurrent scenario. It's better to filter by fixed position (as > it guarantees that this part of segment is completed). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20905) Make it possible to add an explicitly NULL column via ADD COLUMN
[ https://issues.apache.org/jira/browse/IGNITE-20905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20905: - Assignee: Maksim Zhuravkov > Make it possible to add an explicitly NULL column via ADD COLUMN > > > Key: IGNITE-20905 > URL: https://issues.apache.org/jira/browse/IGNITE-20905 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Roman Puchkovskiy >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > When creating a table, it's possible to specify that a column is nullable by > explicitly using NULL: > CREATE TABLE t(id INT PRIMARY KEY, col1 INT NULL) > But, if we add a column to an existing table, this does not work: > ALTER TABLE t ADD COLUMN col2 INT NULL > -> Failed to parse query: Encountered "NULL" at line 1, column X > It seems that for consistency ADD COLUMN should support same syntax as CREATE > TABLE does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19955) Fix create zone on restart rewrites existing data nodes because of trigger key inconsistnecy
[
https://issues.apache.org/jira/browse/IGNITE-19955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-19955:
-
Reviewer: Sergey Uttsel
> Fix create zone on restart rewrites existing data nodes because of trigger
> key inconsistnecy
>
>
> Key: IGNITE-19955
> URL: https://issues.apache.org/jira/browse/IGNITE-19955
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Outdated, see UPD
> Currently we have the logic for initialisation of newly created zone that it
> writes keys
> {noformat}
> zoneDataNodesKey(zoneId), zoneScaleUpChangeTriggerKey(zoneId),
> zoneScaleDownChangeTriggerKey(zoneId), zonesChangeTriggerKey(zoneId)
> {noformat}
> to metastorage, and condition is
> {noformat}
> static CompoundCondition triggerKeyConditionForZonesChanges(long
> revision, int zoneId) {
> return or(
> notExists(zonesChangeTriggerKey(zoneId)),
>
> value(zonesChangeTriggerKey(zoneId)).lt(ByteUtils.longToBytes(revision))
> );
> {noformat}
> Recovery process implies that the create zone event will be processed again,
> but with the higher revision, so data nodes will be rewritten.
> We need to handle this situation, so data nodes will be consistent after
> restart.
> Possible solution is to change condition to
> {noformat}
> static SimpleCondition triggerKeyConditionForZonesCreation(long revision,
> int zoneId) {
> return notExists(zonesChangeTriggerKey(zoneId));
> }
> static SimpleCondition triggerKeyConditionForZonesDelete(int zoneId) {
> return exists(zonesChangeTriggerKey(zoneId));
> }
> {noformat}
>
> so we could not rely on revision and check only existence of the key, when we
> create or remove zone. The problem in this solution is that reordering of the
> create and remove on some node could lead to not consistent state for zones
> key in metastorage
> *UPD*:
> This problem will be resolves once we implement
> https://issues.apache.org/jira/browse/IGNITE-20561
> In this ticket we need to unmute all tickets that were muted by this ticket
--
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] [Created] (IGNITE-21057) Add Xpkginfo:always to Compiler Args
Jonathan Strauss created IGNITE-21057:
-
Summary: Add Xpkginfo:always to Compiler Args
Key: IGNITE-21057
URL: https://issues.apache.org/jira/browse/IGNITE-21057
Project: Ignite
Issue Type: Wish
Components: build
Affects Versions: 2.15
Reporter: Jonathan Strauss
From: [javac
manual|[https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html]]
{noformat}
-Xpkginfo:[always, legacy, nonempty]
Specifies when and how the javac command generates package-info.class files
from package-info.java files using one of the following options:
always
Generates a package-info.class file for every package-info.java file. This
option may be useful if you use a build system such as Ant, which checks that
each .java file has a corresponding .class file.
legacy
Generates a package-info.class file only if package-info.java contains
annotations. This option does not generate a package-info.class file if
package-info.java contains only comments.
Note: A package-info.class file might be generated but be empty if all the
annotations in the package-info.java file have RetentionPolicy.SOURCE.
nonempty
Generates a package-info.class file only if package-info.java contains
annotations with RetentionPolicy.CLASS or RetentionPolicy.RUNTIME.
{noformat}
The Maven Compiler plugin will always recompile the entire project because
there are a number of package-info.java source files with no corresponding
package-info.class files, adding:
{code:java}
-Xpkginfo:always
{code}
Forces the compilation of these Java source files thereby allowing the build
cache to function properly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21012) Fix typo in the transaction state COMMITED
[ https://issues.apache.org/jira/browse/IGNITE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795394#comment-17795394 ] Vladislav Pyatkov commented on IGNITE-21012: Merged 7b6da4eabd1776109c218458c114bb499b11bb74 > Fix typo in the transaction state COMMITED > -- > > Key: IGNITE-21012 > URL: https://issues.apache.org/jira/browse/IGNITE-21012 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > It should be changed to COMMITTED. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21016) ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-21016:
-
Assignee: Konstantin Orlov
> ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is flaky
> ---
>
> Key: IGNITE-21016
> URL: https://issues.apache.org/jira/browse/IGNITE-21016
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> The test
> org.apache.ignite.internal.sql.engine.ItMixedQueriesTest#testIgniteSchemaAwaresAlterTableCommand
> is flacky.
> The issue periodically appears on TC, also reproducable on local environment.
> {code:java}
> org.opentest4j.AssertionFailedError: Column metadata doesn't match ==>
> expected: <3> but was: <2>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:560)
> at
> app//org.apache.ignite.internal.sql.engine.util.QueryCheckerImpl.check(QueryCheckerImpl.java:322)
> at
> app//org.apache.ignite.internal.sql.engine.util.QueryCheckerFactoryImpl$1.check(QueryCheckerFactoryImpl.java:90)
> at
> app//org.apache.ignite.internal.sql.engine.ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand(ItMixedQueriesTest.java:221)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20810) Fix duplicate documentation for Ignite extensions
[ https://issues.apache.org/jira/browse/IGNITE-20810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795314#comment-17795314 ] Igor Gusev commented on IGNITE-20810: - [~av] please review the changes. Docs should be fixed with the linked PRs. > Fix duplicate documentation for Ignite extensions > - > > Key: IGNITE-20810 > URL: https://issues.apache.org/jira/browse/IGNITE-20810 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Some time ago we created a separate documentation for Ignite extensions in > the extensions repository: > [https://github.com/apache/ignite-extensions] > It is also published, but without links from main doc > [https://ignite.apache.org/docs/extensions/aws/aws] > This currently conflicts with extensions documentation still in the main repo: > [https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-boot] > [https://github.com/apache/ignite/tree/master/docs/_docs/extensions-and-integrations] > We need to make sure there is only one documentation for extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20810) Fix duplicate documentation for Ignite extensions
[ https://issues.apache.org/jira/browse/IGNITE-20810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-20810: --- Assignee: Igor Gusev > Fix duplicate documentation for Ignite extensions > - > > Key: IGNITE-20810 > URL: https://issues.apache.org/jira/browse/IGNITE-20810 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Some time ago we created a separate documentation for Ignite extensions in > the extensions repository: > [https://github.com/apache/ignite-extensions] > It is also published, but without links from main doc > [https://ignite.apache.org/docs/extensions/aws/aws] > This currently conflicts with extensions documentation still in the main repo: > [https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-boot] > [https://github.com/apache/ignite/tree/master/docs/_docs/extensions-and-integrations] > We need to make sure there is only one documentation for extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20662) Sql. Test performance of multi statement queries
[ https://issues.apache.org/jira/browse/IGNITE-20662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-20662: - Assignee: Pavel Pereslegin > Sql. Test performance of multi statement queries > > > Key: IGNITE-20662 > URL: https://issues.apache.org/jira/browse/IGNITE-20662 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Let's add some benchmarks to measure performance of multi statement queries. > At least two types of tests should be added: > * overhead of script processor: run the same single statement query as single > statement and as script > * performance gain after implementation of sophisticated rules of > parallelisation (IGNITE-20673): run sequence of queries as chain of single > statements and as script -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21056) Use thread local buffer for encrypted dump
[ https://issues.apache.org/jira/browse/IGNITE-21056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuri Naryshkin updated IGNITE-21056: Description: When encrypted dump taken, expanded byte buffer isn't returned to the pool. (was: Thread local buffer ) > Use thread local buffer for encrypted dump > -- > > Key: IGNITE-21056 > URL: https://issues.apache.org/jira/browse/IGNITE-21056 > Project: Ignite > Issue Type: Task >Reporter: Yuri Naryshkin >Assignee: Yuri Naryshkin >Priority: Minor > Labels: IEP-109, ise > > When encrypted dump taken, expanded byte buffer isn't returned to the pool. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21056) Use thread local buffer for encrypted dump
[ https://issues.apache.org/jira/browse/IGNITE-21056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuri Naryshkin updated IGNITE-21056: Description: When encrypted dump taken, expanded byte buffer doesn't replace thread local one. (was: When encrypted dump taken, expanded byte buffer isn't returned to the pool. ) > Use thread local buffer for encrypted dump > -- > > Key: IGNITE-21056 > URL: https://issues.apache.org/jira/browse/IGNITE-21056 > Project: Ignite > Issue Type: Task >Reporter: Yuri Naryshkin >Assignee: Yuri Naryshkin >Priority: Minor > Labels: IEP-109, ise > > When encrypted dump taken, expanded byte buffer doesn't replace thread local > one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21056) Use thread local buffer for encrypted dump
[
https://issues.apache.org/jira/browse/IGNITE-21056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuri Naryshkin updated IGNITE-21056:
Description: Thread local buffer (was: Ignite has {{EncryptionSpi}} that
provides feature to encrypt data on disk.
Cache dumps must use this SPI to protect data in dump.)
> Use thread local buffer for encrypted dump
> --
>
> Key: IGNITE-21056
> URL: https://issues.apache.org/jira/browse/IGNITE-21056
> Project: Ignite
> Issue Type: Task
>Reporter: Yuri Naryshkin
>Assignee: Yuri Naryshkin
>Priority: Major
> Labels: IEP-109, ise
>
> Thread local buffer
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21056) Use thread local buffer for encrypted dump
[ https://issues.apache.org/jira/browse/IGNITE-21056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuri Naryshkin updated IGNITE-21056: Priority: Minor (was: Major) > Use thread local buffer for encrypted dump > -- > > Key: IGNITE-21056 > URL: https://issues.apache.org/jira/browse/IGNITE-21056 > Project: Ignite > Issue Type: Task >Reporter: Yuri Naryshkin >Assignee: Yuri Naryshkin >Priority: Minor > Labels: IEP-109, ise > > Thread local buffer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21056) Use thread local buffer for encrypted dump
[
https://issues.apache.org/jira/browse/IGNITE-21056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuri Naryshkin updated IGNITE-21056:
Fix Version/s: (was: 2.16)
> Use thread local buffer for encrypted dump
> --
>
> Key: IGNITE-21056
> URL: https://issues.apache.org/jira/browse/IGNITE-21056
> Project: Ignite
> Issue Type: Task
>Reporter: Yuri Naryshkin
>Assignee: Yuri Naryshkin
>Priority: Major
> Labels: IEP-109, ise
>
> Ignite has {{EncryptionSpi}} that provides feature to encrypt data on disk.
> Cache dumps must use this SPI to protect data in dump.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21056) Use thread local buffer for encrypted dump
[
https://issues.apache.org/jira/browse/IGNITE-21056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuri Naryshkin reassigned IGNITE-21056:
---
Assignee: Yuri Naryshkin (was: Nikolay Izhikov)
> Use thread local buffer for encrypted dump
> --
>
> Key: IGNITE-21056
> URL: https://issues.apache.org/jira/browse/IGNITE-21056
> Project: Ignite
> Issue Type: Task
>Reporter: Yuri Naryshkin
>Assignee: Yuri Naryshkin
>Priority: Major
> Labels: IEP-109, ise
> Fix For: 2.16
>
>
> Ignite has {{EncryptionSpi}} that provides feature to encrypt data on disk.
> Cache dumps must use this SPI to protect data in dump.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21056) Use thread local buffer for encrypted dump
Yuri Naryshkin created IGNITE-21056:
---
Summary: Use thread local buffer for encrypted dump
Key: IGNITE-21056
URL: https://issues.apache.org/jira/browse/IGNITE-21056
Project: Ignite
Issue Type: Task
Reporter: Yuri Naryshkin
Assignee: Nikolay Izhikov
Fix For: 2.16
Ignite has {{EncryptionSpi}} that provides feature to encrypt data on disk.
Cache dumps must use this SPI to protect data in dump.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20810) Fix duplicate documentation for Ignite extensions
[ https://issues.apache.org/jira/browse/IGNITE-20810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795290#comment-17795290 ] Alexey Alexandrov commented on IGNITE-20810: Created pull request removing docs/extensions section and build script for it: https://github.com/apache/ignite-website/pull/175 > Fix duplicate documentation for Ignite extensions > - > > Key: IGNITE-20810 > URL: https://issues.apache.org/jira/browse/IGNITE-20810 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Some time ago we created a separate documentation for Ignite extensions in > the extensions repository: > [https://github.com/apache/ignite-extensions] > It is also published, but without links from main doc > [https://ignite.apache.org/docs/extensions/aws/aws] > This currently conflicts with extensions documentation still in the main repo: > [https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-boot] > [https://github.com/apache/ignite/tree/master/docs/_docs/extensions-and-integrations] > We need to make sure there is only one documentation for extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21055) Sql. ParserService should use SqlNode::unparse instead of SqlNode::toString
[ https://issues.apache.org/jira/browse/IGNITE-21055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21055: -- Fix Version/s: 3.0.0-beta2 > Sql. ParserService should use SqlNode::unparse instead of SqlNode::toString > --- > > Key: IGNITE-21055 > URL: https://issues.apache.org/jira/browse/IGNITE-21055 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Problem - SqlNodes may contain sensitive information that can leak into logs > via toString method, in order to avoid such > issues it maybe a good idea to override toString method to remove all > sensitive information for such SQL nodes. > Unfornutently such approach breaks PrepareService, because it builds a copy > for a SQL AST from SQL string created by SqlNode::toString method. > Let's update ParserService to build SQL via unparse method to avoid this > problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21055) Sql. ParserService should use SqlNode::unparse instead of SqlNode::toString
[ https://issues.apache.org/jira/browse/IGNITE-21055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21055: -- Labels: ignite-3 (was: ) > Sql. ParserService should use SqlNode::unparse instead of SqlNode::toString > --- > > Key: IGNITE-21055 > URL: https://issues.apache.org/jira/browse/IGNITE-21055 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > Problem - SqlNodes may contain sensitive information that can leak into logs > via toString method, in order to avoid such > issues it maybe a good idea to override toString method to remove all > sensitive information for such SQL nodes. > Unfornutently such approach breaks PrepareService, because it builds a copy > for a SQL AST from SQL string created by SqlNode::toString method. > Let's update ParserService to build SQL via unparse method to avoid this > problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21055) Sql. ParserService should use SqlNode::unparse instead of SqlNode::toString
Maksim Zhuravkov created IGNITE-21055: - Summary: Sql. ParserService should use SqlNode::unparse instead of SqlNode::toString Key: IGNITE-21055 URL: https://issues.apache.org/jira/browse/IGNITE-21055 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Problem - SqlNodes may contain sensitive information that can leak into logs via toString method, in order to avoid such issues it maybe a good idea to override toString method to remove all sensitive information for such SQL nodes. Unfornutently such approach breaks PrepareService, because it builds a copy for a SQL AST from SQL string created by SqlNode::toString method. Let's update ParserService to build SQL via unparse method to avoid this problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21036) Add possibility to obtain parameters of already existing zone.
[ https://issues.apache.org/jira/browse/IGNITE-21036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21036: --- Summary: Add possibility to obtain parameters of already existing zone. (was: Sql. Add possibility to obtain parameters of already existing zone.) > Add possibility to obtain parameters of already existing zone. > -- > > Key: IGNITE-21036 > URL: https://issues.apache.org/jira/browse/IGNITE-21036 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > For now it`s possible to create distributed zone with different configurable > parameters, like: > "CREATE ZONE name_of_the_zone WITH partitions=7, DATA_NODES_AUTO_ADJUST=100" > but there is no way to obtain this zone params using public api (views, > jmx?). Seems we need such a functionality. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20662) Sql. Test performance of multi statement queries
[ https://issues.apache.org/jira/browse/IGNITE-20662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-20662: - Assignee: (was: Pavel Pereslegin) > Sql. Test performance of multi statement queries > > > Key: IGNITE-20662 > URL: https://issues.apache.org/jira/browse/IGNITE-20662 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Let's add some benchmarks to measure performance of multi statement queries. > At least two types of tests should be added: > * overhead of script processor: run the same single statement query as single > statement and as script > * performance gain after implementation of sophisticated rules of > parallelisation (IGNITE-20673): run sequence of queries as chain of single > statements and as script -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21054) Do not do schema sync await on every read/write operation in RW transaction
[ https://issues.apache.org/jira/browse/IGNITE-21054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21054: --- Description: For each read/write operation in an RW transaction, we check that the schema of the table has not changed (to implement fail-fast behavior). When doing so, we do 'schema sync' (implying a possible wait) at operationTimestamp. It seems that the 'schema sync' is not necessary (it's not a problem if we check against a slightly outdated schema [as it cannot be too outdated, it is not older than the schema on which the transaction had started]). This must be considered carefully first (maybe there is some reason to keep the checks). We should do it after we design the index build procedure (as it requires to take current schema for each write operation). > Do not do schema sync await on every read/write operation in RW transaction > --- > > Key: IGNITE-21054 > URL: https://issues.apache.org/jira/browse/IGNITE-21054 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > For each read/write operation in an RW transaction, we check that the schema > of the table has not changed (to implement fail-fast behavior). > When doing so, we do 'schema sync' (implying a possible wait) at > operationTimestamp. It seems that the 'schema sync' is not necessary (it's > not a problem if we check against a slightly outdated schema [as it cannot be > too outdated, it is not older than the schema on which the transaction had > started]). > This must be considered carefully first (maybe there is some reason to keep > the checks). We should do it after we design the index build procedure (as it > requires to take current schema for each write operation). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20662) Sql. Test performance of multi statement queries
[ https://issues.apache.org/jira/browse/IGNITE-20662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-20662: - Assignee: Pavel Pereslegin > Sql. Test performance of multi statement queries > > > Key: IGNITE-20662 > URL: https://issues.apache.org/jira/browse/IGNITE-20662 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Let's add some benchmarks to measure performance of multi statement queries. > At least two types of tests should be added: > * overhead of script processor: run the same single statement query as single > statement and as script > * performance gain after implementation of sophisticated rules of > parallelisation (IGNITE-20673): run sequence of queries as chain of single > statements and as script -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21054) Do not do schema sync await on every read/write operation in RW transaction
Roman Puchkovskiy created IGNITE-21054: -- Summary: Do not do schema sync await on every read/write operation in RW transaction Key: IGNITE-21054 URL: https://issues.apache.org/jira/browse/IGNITE-21054 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21053) Improve authentication providers validator
Vadim Pakhnushev created IGNITE-21053: - Summary: Improve authentication providers validator Key: IGNITE-21053 URL: https://issues.apache.org/jira/browse/IGNITE-21053 Project: Ignite Issue Type: Bug Reporter: Vadim Pakhnushev Assignee: Vadim Pakhnushev After IGNITE-20643 authentication configuration validator erroneously assumes that the providers are of type basic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21053) Improve authentication providers validator
[ https://issues.apache.org/jira/browse/IGNITE-21053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev updated IGNITE-21053: -- Component/s: security > Improve authentication providers validator > -- > > Key: IGNITE-21053 > URL: https://issues.apache.org/jira/browse/IGNITE-21053 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > > After IGNITE-20643 authentication configuration validator erroneously assumes > that the providers are of type basic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21053) Improve authentication providers validator
[ https://issues.apache.org/jira/browse/IGNITE-21053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev updated IGNITE-21053: -- Labels: ignite-3 (was: ) > Improve authentication providers validator > -- > > Key: IGNITE-21053 > URL: https://issues.apache.org/jira/browse/IGNITE-21053 > Project: Ignite > Issue Type: Bug >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > > After IGNITE-20643 authentication configuration validator erroneously assumes > that the providers are of type basic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21052) Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback is flaky due to planning timeout
[
https://issues.apache.org/jira/browse/IGNITE-21052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21052:
--
Component/s: sql
> Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback is
> flaky due to planning timeout
> ---
>
> Key: IGNITE-21052
> URL: https://issues.apache.org/jira/browse/IGNITE-21052
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> The ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback test
> recently started failing on Teamcity.
> https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-7125216101951766635=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50
> We need to investigate why planning of a simple query takes so long. It looks
> like current timeout - 5 seconds should be enough.
> {noformat}
> org.apache.ignite.sql.SqlException: IGN-SQL-10
> TraceId:97de28e5-3561-4c31-b126-e089296cec39 Planning of a query aborted due
> to planner timeout threshold is reached
> at
> app//org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareAsync$0(PrepareServiceImpl.java:202)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1705)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
> Suppressed: java.lang.RuntimeException: This is a trimmed root
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:757)
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:777)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.prepare(ExecutionServiceImplTest.java:813)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback(ExecutionServiceImplTest.java:694)
> 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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
>
[jira] [Updated] (IGNITE-21052) Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback is flaky due to planning timeout
[
https://issues.apache.org/jira/browse/IGNITE-21052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21052:
--
Description:
The ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback test
recently started failing on Teamcity.
https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-7125216101951766635=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50
We need to investigate why planning of a simple query takes so long. It looks
like current timeout - 5 seconds should be enough.
{noformat}
org.apache.ignite.sql.SqlException: IGN-SQL-10
TraceId:97de28e5-3561-4c31-b126-e089296cec39 Planning of a query aborted due to
planner timeout threshold is reached
at
app//org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareAsync$0(PrepareServiceImpl.java:202)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1705)
at
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
Suppressed: java.lang.RuntimeException: This is a trimmed root
at
org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:757)
at
org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:777)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.prepare(ExecutionServiceImplTest.java:813)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback(ExecutionServiceImplTest.java:694)
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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
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
[jira] [Updated] (IGNITE-21052) Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback is flaky due to planning timeout
[
https://issues.apache.org/jira/browse/IGNITE-21052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21052:
--
Description:
The ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback test
recently started failing on Teamcity.
https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-7125216101951766635=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50
We need to investigate why planning of a simple query takes so long (5 seconds
should be enough).
{noformat}
org.apache.ignite.sql.SqlException: IGN-SQL-10
TraceId:97de28e5-3561-4c31-b126-e089296cec39 Planning of a query aborted due to
planner timeout threshold is reached
at
app//org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareAsync$0(PrepareServiceImpl.java:202)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1705)
at
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
Suppressed: java.lang.RuntimeException: This is a trimmed root
at
org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:757)
at
org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:777)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.prepare(ExecutionServiceImplTest.java:813)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback(ExecutionServiceImplTest.java:694)
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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
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
[jira] [Created] (IGNITE-21052) Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac is flaky due to planning timeout
Pavel Pereslegin created IGNITE-21052:
-
Summary: Sql. Test
ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac is flaky due to
planning timeout
Key: IGNITE-21052
URL: https://issues.apache.org/jira/browse/IGNITE-21052
Project: Ignite
Issue Type: Bug
Reporter: Pavel Pereslegin
The ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac test
recently started failing on Teamcity.
https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-7125216101951766635=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50
We need to investigate why planning of a simple query takes so long (5 seconds
should be enough).
{noformat}
org.apache.ignite.sql.SqlException: IGN-SQL-10
TraceId:97de28e5-3561-4c31-b126-e089296cec39 Planning of a query aborted due to
planner timeout threshold is reached
at
app//org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareAsync$0(PrepareServiceImpl.java:202)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1705)
at
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
Suppressed: java.lang.RuntimeException: This is a trimmed root
at
org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:757)
at
org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:777)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.prepare(ExecutionServiceImplTest.java:813)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback(ExecutionServiceImplTest.java:694)
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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
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)
[jira] [Updated] (IGNITE-21052) Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac is flaky due to planning timeout
[
https://issues.apache.org/jira/browse/IGNITE-21052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21052:
--
Labels: ignite-3 (was: )
> Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac is
> flaky due to planning timeout
> --
>
> Key: IGNITE-21052
> URL: https://issues.apache.org/jira/browse/IGNITE-21052
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> The ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac test
> recently started failing on Teamcity.
> https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-7125216101951766635=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50
> We need to investigate why planning of a simple query takes so long (5
> seconds should be enough).
> {noformat}
> org.apache.ignite.sql.SqlException: IGN-SQL-10
> TraceId:97de28e5-3561-4c31-b126-e089296cec39 Planning of a query aborted due
> to planner timeout threshold is reached
> at
> app//org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareAsync$0(PrepareServiceImpl.java:202)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1705)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
> Suppressed: java.lang.RuntimeException: This is a trimmed root
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:757)
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:777)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.prepare(ExecutionServiceImplTest.java:813)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback(ExecutionServiceImplTest.java:694)
> 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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> 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
>
[jira] [Updated] (IGNITE-21052) Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback is flaky due to planning timeout
[
https://issues.apache.org/jira/browse/IGNITE-21052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21052:
--
Summary: Sql. Test
ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback is flaky due
to planning timeout (was: Sql. Test
ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac is flaky due to
planning timeout)
> Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback is
> flaky due to planning timeout
> ---
>
> Key: IGNITE-21052
> URL: https://issues.apache.org/jira/browse/IGNITE-21052
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> The ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac test
> recently started failing on Teamcity.
> https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-7125216101951766635=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50
> We need to investigate why planning of a simple query takes so long (5
> seconds should be enough).
> {noformat}
> org.apache.ignite.sql.SqlException: IGN-SQL-10
> TraceId:97de28e5-3561-4c31-b126-e089296cec39 Planning of a query aborted due
> to planner timeout threshold is reached
> at
> app//org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareAsync$0(PrepareServiceImpl.java:202)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1705)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
> Suppressed: java.lang.RuntimeException: This is a trimmed root
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:757)
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:777)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.prepare(ExecutionServiceImplTest.java:813)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback(ExecutionServiceImplTest.java:694)
> 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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> 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
>
[jira] [Updated] (IGNITE-21052) Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac is flaky due to planning timeout
[
https://issues.apache.org/jira/browse/IGNITE-21052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21052:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Test ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac is
> flaky due to planning timeout
> --
>
> Key: IGNITE-21052
> URL: https://issues.apache.org/jira/browse/IGNITE-21052
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> The ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallbac test
> recently started failing on Teamcity.
> https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-7125216101951766635=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50
> We need to investigate why planning of a simple query takes so long (5
> seconds should be enough).
> {noformat}
> org.apache.ignite.sql.SqlException: IGN-SQL-10
> TraceId:97de28e5-3561-4c31-b126-e089296cec39 Planning of a query aborted due
> to planner timeout threshold is reached
> at
> app//org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareAsync$0(PrepareServiceImpl.java:202)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1705)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
> Suppressed: java.lang.RuntimeException: This is a trimmed root
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:757)
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:777)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.prepare(ExecutionServiceImplTest.java:813)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.testErrorIsPropagatedToPrefetchCallback(ExecutionServiceImplTest.java:694)
> 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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
>
[jira] [Assigned] (IGNITE-21012) Fix typo in the transaction state COMMITED
[ https://issues.apache.org/jira/browse/IGNITE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-21012: -- Assignee: Vladislav Pyatkov > Fix typo in the transaction state COMMITED > -- > > Key: IGNITE-21012 > URL: https://issues.apache.org/jira/browse/IGNITE-21012 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > It should be changed to COMMITTED. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21051) Fix javadocs for IndexQuery
[ https://issues.apache.org/jira/browse/IGNITE-21051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21051: Labels: newbie (was: ) > Fix javadocs for IndexQuery > --- > > Key: IGNITE-21051 > URL: https://issues.apache.org/jira/browse/IGNITE-21051 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Priority: Major > Labels: newbie > > It's required to fix javadoc formatting in the `IndexQuery` class. Now it > renders the algorithm list in single line. Should use "ul", "li" tags for > correct rendering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21051) Fix javadocs for IndexQuery
[ https://issues.apache.org/jira/browse/IGNITE-21051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-21051: --- Labels: ise newbie (was: newbie) > Fix javadocs for IndexQuery > --- > > Key: IGNITE-21051 > URL: https://issues.apache.org/jira/browse/IGNITE-21051 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Priority: Major > Labels: ise, newbie > > It's required to fix javadoc formatting in the `IndexQuery` class. Now it > renders the algorithm list in single line. Should use "ul", "li" tags for > correct rendering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21051) Fix javadocs for IndexQuery
[ https://issues.apache.org/jira/browse/IGNITE-21051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21051: Ignite Flags: (was: Docs Required,Release Notes Required) > Fix javadocs for IndexQuery > --- > > Key: IGNITE-21051 > URL: https://issues.apache.org/jira/browse/IGNITE-21051 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Priority: Major > > It's required to fix javadoc formatting in the `IndexQuery` class. Now it > renders the algorithm list in single line. Should use "ul", "li" tags for > correct rendering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21051) Fix javadocs for IndexQuery
Maksim Timonin created IGNITE-21051: --- Summary: Fix javadocs for IndexQuery Key: IGNITE-21051 URL: https://issues.apache.org/jira/browse/IGNITE-21051 Project: Ignite Issue Type: Improvement Reporter: Maksim Timonin It's required to fix javadoc formatting in the `IndexQuery` class. Now it renders the algorithm list in single line. Should use "ul", "li" tags for correct rendering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20107) Make table created after tx started visible to the tx
[ https://issues.apache.org/jira/browse/IGNITE-20107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-20107: --- Description: *This is superseded by IGNITE-21003, see comments* baseTs is used when validating a schema (schema at commitTs or at operationTs is validated to match/be compatible to the schema at baseTs). The easiest way to calculate baseTs is to do baseTs=beginTs(tx). But to make a created table immediately available for already running transactions (as per [https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes#IEP110:Schemasynchronization:basicschemachanges-Basicrequirements] ), we can take baseTs=Max(beginTs(tx), creationTs(table)). was: baseTs is used when validating a schema (schema at commitTs or at operationTs is validated to match/be compatible to the schema at baseTs). The easiest way to calculate baseTs is to do baseTs=beginTs(tx). But to make a created table immediately available for already running transactions (as per [https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes#IEP110:Schemasynchronization:basicschemachanges-Basicrequirements] ), we can take baseTs=Max(beginTs(tx), creationTs(table)). > Make table created after tx started visible to the tx > - > > Key: IGNITE-20107 > URL: https://issues.apache.org/jira/browse/IGNITE-20107 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: iep-110, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > *This is superseded by IGNITE-21003, see comments* > baseTs is used when validating a schema (schema at commitTs or at operationTs > is validated to match/be compatible to the schema at baseTs). > The easiest way to calculate baseTs is to do baseTs=beginTs(tx). But to make > a created table immediately available for already running transactions (as > per > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes#IEP110:Schemasynchronization:basicschemachanges-Basicrequirements] > ), we can take baseTs=Max(beginTs(tx), creationTs(table)). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20107) Make table created after tx started visible to the tx
[ https://issues.apache.org/jira/browse/IGNITE-20107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795229#comment-17795229 ] Roman Puchkovskiy commented on IGNITE-20107: This was superseded by IGNITE-21003, so stopping progress for now. > Make table created after tx started visible to the tx > - > > Key: IGNITE-20107 > URL: https://issues.apache.org/jira/browse/IGNITE-20107 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: iep-110, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > baseTs is used when validating a schema (schema at commitTs or at operationTs > is validated to match/be compatible to the schema at baseTs). > The easiest way to calculate baseTs is to do baseTs=beginTs(tx). But to make > a created table immediately available for already running transactions (as > per > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes#IEP110:Schemasynchronization:basicschemachanges-Basicrequirements] > ), we can take baseTs=Max(beginTs(tx), creationTs(table)). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21000) ItDistributedConfigurationStorageTest#testRestartWithPds may fail
[
https://issues.apache.org/jira/browse/IGNITE-21000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795226#comment-17795226
]
Alexander Lapin commented on IGNITE-21000:
--
Proposed solution is inorrect. Seem that we have serious issue in jraft itself,
so I've asked the jraft guys https://github.com/sofastack/sofa-jraft/issues/1049
> ItDistributedConfigurationStorageTest#testRestartWithPds may fail
> -
>
> Key: IGNITE-21000
> URL: https://issues.apache.org/jira/browse/IGNITE-21000
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> java.lang.AssertionError:
> Expected: is <{foo=bar}>
> but: was <{}>java.lang.AssertionError:Expected: is <{foo=bar}> but:
> was <{}> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at
> org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6) at
> org.apache.ignite.internal.configuration.storage.ItDistributedConfigurationStorageTest.testRestartWithPds(ItDistributedConfigurationStorageTest.java:256)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7665195?expandCode+Inspection=true=true=false=true=false]
>
> The reason of the failure is possible read/write commands reordering on raft
> node restart. GetCurrentRevisionCommand (extends ReadCommand) handling checks
> whether raft index matches storage one and if it does - evaluates the read.
> After IGNITE-20425 raft log application is done asynchronously, meaning that
> if GetCurrentRevisionCommand will touch the leader after election but prior
> to log replay it will see 0 both in raft and storage indexes instead of 1 and
> (0 or 1) respectively. In order to fix this it's possible to add
> lastCommittedIndex initialization:
> {code:java}
> public boolean resetPendingIndex(final long newPendingIndex) {
> ...
> this.lastCommittedIndex = newPendingIndex - 1;
> ...
> }{code}
> Given solution was disccused previoulsy, see
> [https://github.com/apache/ignite-3/pull/960/files#diff-f3783b069060b4e1616ce9675b7a120ebf9797b4439ff6bae43376af62df0200]
> for more details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
