[MTCGA]: new failures in builds [6014968] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *Test with high flaky rate in master IgniteCachePutRetryAtomicSelfTest.testInvoke https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7568819892486826780=%3Cdefault%3E=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 21:10:23 24-05-2021
Re: [DISCUSSION] Transactional cache could be in inconsistent state after node recovery.
As for me, it is logical to remove this flag after merging IGNITE-6324. I suppose that the slowdown is negligible. BTW, yardstick reports contains no information about confidence interval. I suppose that another run could show not drop but improvement :) пн, 24 мая 2021 г. в 12:06, Zhenya Stanilovsky : > > > Igniters, as previously was found [1] in some cases transactional cache can > contain unexpected data after node crash and further recovery. Short > explanation: it`s all due to ignite does not save transactional records into > the WAL. > The simplest example: 1 node cluster and transactional cache, if crash has > occurred during transaction processing data records will be partially stored > into the wal and further recovery procedure will apply them, as is, thus if > transaction contain keys [k1, k2, k3] after recovery we can obtain only [k1, > k2], of course this is unexpected and erroneous behavior. There are numerous > variants with multi nodes on how they can obtain inconsistent data after > recovery [2]. PR [1] (already merged into master) has changed this situation > and i suggest to turn on by default transactional records storing and remove > flag IGNITE_WAL_LOG_TX_RECORDS at all. > I benchmarked (attached in issue) and found no potential slowdowns here. > Any comments ? Review is appreciated too. Thanks! > > [1] https://issues.apache.org/jira/browse/IGNITE-6324 > [2] > https://github.com/apache/ignite/pull/8987/files#diff-96ba20321a66ec20d0df55abcdeb0808ff6dd1d4b87b782c892496369321a593R75 > [3] https://issues.apache.org/jira/browse/IGNITE-14739 > > > > -- Sincerely yours, Ivan Daschinskiy
[DISCUSSION] Transactional cache could be in inconsistent state after node recovery.
Igniters, as previously was found [1] in some cases transactional cache can contain unexpected data after node crash and further recovery. Short explanation: it`s all due to ignite does not save transactional records into the WAL. The simplest example: 1 node cluster and transactional cache, if crash has occurred during transaction processing data records will be partially stored into the wal and further recovery procedure will apply them, as is, thus if transaction contain keys [k1, k2, k3] after recovery we can obtain only [k1, k2], of course this is unexpected and erroneous behavior. There are numerous variants with multi nodes on how they can obtain inconsistent data after recovery [2]. PR [1] (already merged into master) has changed this situation and i suggest to turn on by default transactional records storing and remove flag IGNITE_WAL_LOG_TX_RECORDS at all. I benchmarked (attached in issue) and found no potential slowdowns here. Any comments ? Review is appreciated too. Thanks! [1] https://issues.apache.org/jira/browse/IGNITE-6324 [2] https://github.com/apache/ignite/pull/8987/files#diff-96ba20321a66ec20d0df55abcdeb0808ff6dd1d4b87b782c892496369321a593R75 [3] https://issues.apache.org/jira/browse/IGNITE-14739
Re: Building with maven 3.8.1
My point is that we cannot test "Maven 3.8.1 works with Apache Ignite" on TeamCity currently - only locally or in Travis. Just FYI :) > On 24 May 2021, at 10:39, Ivan Daschinsky wrote: > > And so what? There are no changes in pom's (in this PR) that break > build on earlier maven versions. Why we should trust this patch > (moreover, it breaks even some travis ci checks) > > пн, 24 мая 2021 г. в 10:09, Petr Ivanov : >> >> Our TeamCity currently does not support 3.8.1 maven build runner. >> I think it will be available with 2021.1 version that is going to be >> delivered soon. >> >> >>> On 21 May 2021, at 12:28, Ivan Daschinsky wrote: >>> >>> Hi. But where is TC run? And I suppose, that >>> https://travis-ci.com/github/apache/ignite/jobs/506675544 should be at >>> least fixed >>> >>> пт, 21 мая 2021 г. в 10:22, Petr Ivanov : Hi, Ilya. Left small comment on formatting issue. Otherwise looks good! Considering 3.8.1 maven support — we will be migrating builds there after TC 2021.1 will be delivered. > On 20 May 2021, at 19:22, Ilya Korol wrote: > > Hi, all. > > Maybe someone has already faced the issue with Ignite and latest Maven > release 3.8.1? > > https://issues.apache.org/jira/browse/IGNITE-14753 > > From 3.8.1 maven supplied with config that will block any http > repository/mirror. (See details here > https://maven.apache.org/docs/3.8.1/release-notes.html#cve-2021-26291) > > Attempt to perform a build produces several errors: > > > 1. Third party dependencies > > 1.1) jta, hibernate-4.2, hibernate-5.1, hibernate-5.3 (btw hibernate-* > modules aren't built during mvn install) > > org.ow2.jotm:jotm-core:jar:2.2.3 > -> org.ow2.carol:carol:jar:3.0.8 > -> org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 > > jotm is a test dependency. Switch to latest available version 2.3.1-M1 > did the trick. I didn't find any changelog for latest jotm release (their > site jotm.ow2.org seems a bit abandoned). I checked a little the diff > between 2.2.3 and 2.3.1-M1 source jars. Seems that there was some changes > in RMI related facilities, but i don't have enough expertise make a > conclusion that switch to 2.3.1-M1 would be safe (even if tests would be > green). Due to state of JOTM project maybe we should consider using > another JTA implementation with ongoing support like Atomicos or Narayana > (this implementation is also from the JBoss family like Hibernate)? > > 1.2) spark > > [ERROR] Failed to execute goal on project ignite-spark: Could not resolve > dependencies for project > org.apache.ignite:ignite-spark:jar:2.11.0-SNAPSHOT: Failed to collect > dependencies at org.apache.spark:spark-core_2.11:jar:2.3.0 -> > net.java.dev.jets3t:jets3t:jar:0.9.4 -> > commons-codec:commons-codec:jar:1.15-SNAPSHOT: Failed to read artifact > descriptor for commons-codec:commons-codec:jar:1.15-SNAPSHOT: Could not > transfer artifact commons-codec:commons-codec:pom:1.15-SNAPSHOT from/to > maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for > repositories: [apache.snapshots (http://repository.apache.org/snapshots, > default, snapshots)] -> [Help 1] > > Updating to latest spark-core_2.11 maintenance version (2.3.0 -> 2.3.4) > did the job. > > > 2. Broken plugins configuration > > Currently ignite-parent uses org.apache:apache:16 as parent. Up to 18 > release apache used http schema in different places of its configuration > (e.g. snapshot repository). So i guess its a good reason to update apache > parent at least to 18 release or maybe even to latest 23. This upgrade > will break builds for several modules: > > 2.1) maven-jar-plugin */useDefaultManifestFile/* option was removed, so > usage of this option (true for ignite) will break the build. I guess we > can safely remove it from parent pom. > > 2.2) Classifiers in ignite-exdata-uri. Building ignite-exdata-uri with > latest jar plugin produces errors like: > > ignite-extdata-uri: You have to use a classifier to attach supplemental > artifacts to the project instead of replacing them > > Seems that jar plugin doesn't like when build produces multiple jars even > if they finalName's are different. Reworking build configuration with > classifiers fixed the problem. > > > I've created a PR with proposed changes: > https://github.com/apache/ignite/pull/9116, comments are welcome > >>> >>> >>> -- >>> Sincerely yours, Ivan Daschinskiy >> > > > -- > Sincerely yours, Ivan Daschinskiy
Re: Building with maven 3.8.1
Of cource this PR should be fixed to not break any existing tests before accepting. I've posted it just as example of described issues. I'll check failed stuff and add required fixes when i get some free time. 24.05.2021 17:39, Ivan Daschinsky пишет: And so what? There are no changes in pom's (in this PR) that break build on earlier maven versions. Why we should trust this patch (moreover, it breaks even some travis ci checks) пн, 24 мая 2021 г. в 10:09, Petr Ivanov : Our TeamCity currently does not support 3.8.1 maven build runner. I think it will be available with 2021.1 version that is going to be delivered soon. On 21 May 2021, at 12:28, Ivan Daschinsky wrote: Hi. But where is TC run? And I suppose, that https://travis-ci.com/github/apache/ignite/jobs/506675544 should be at least fixed пт, 21 мая 2021 г. в 10:22, Petr Ivanov : Hi, Ilya. Left small comment on formatting issue. Otherwise looks good! Considering 3.8.1 maven support — we will be migrating builds there after TC 2021.1 will be delivered. On 20 May 2021, at 19:22, Ilya Korol wrote: Hi, all. Maybe someone has already faced the issue with Ignite and latest Maven release 3.8.1? https://issues.apache.org/jira/browse/IGNITE-14753 From 3.8.1 maven supplied with config that will block any http repository/mirror. (See details here https://maven.apache.org/docs/3.8.1/release-notes.html#cve-2021-26291) Attempt to perform a build produces several errors: 1. Third party dependencies 1.1) jta, hibernate-4.2, hibernate-5.1, hibernate-5.3 (btw hibernate-* modules aren't built during mvn install) org.ow2.jotm:jotm-core:jar:2.2.3 -> org.ow2.carol:carol:jar:3.0.8 -> org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 jotm is a test dependency. Switch to latest available version 2.3.1-M1 did the trick. I didn't find any changelog for latest jotm release (their site jotm.ow2.org seems a bit abandoned). I checked a little the diff between 2.2.3 and 2.3.1-M1 source jars. Seems that there was some changes in RMI related facilities, but i don't have enough expertise make a conclusion that switch to 2.3.1-M1 would be safe (even if tests would be green). Due to state of JOTM project maybe we should consider using another JTA implementation with ongoing support like Atomicos or Narayana (this implementation is also from the JBoss family like Hibernate)? 1.2) spark [ERROR] Failed to execute goal on project ignite-spark: Could not resolve dependencies for project org.apache.ignite:ignite-spark:jar:2.11.0-SNAPSHOT: Failed to collect dependencies at org.apache.spark:spark-core_2.11:jar:2.3.0 -> net.java.dev.jets3t:jets3t:jar:0.9.4 -> commons-codec:commons-codec:jar:1.15-SNAPSHOT: Failed to read artifact descriptor for commons-codec:commons-codec:jar:1.15-SNAPSHOT: Could not transfer artifact commons-codec:commons-codec:pom:1.15-SNAPSHOT from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories: [apache.snapshots (http://repository.apache.org/snapshots, default, snapshots)] -> [Help 1] Updating to latest spark-core_2.11 maintenance version (2.3.0 -> 2.3.4) did the job. 2. Broken plugins configuration Currently ignite-parent uses org.apache:apache:16 as parent. Up to 18 release apache used http schema in different places of its configuration (e.g. snapshot repository). So i guess its a good reason to update apache parent at least to 18 release or maybe even to latest 23. This upgrade will break builds for several modules: 2.1) maven-jar-plugin */useDefaultManifestFile/* option was removed, so usage of this option (true for ignite) will break the build. I guess we can safely remove it from parent pom. 2.2) Classifiers in ignite-exdata-uri. Building ignite-exdata-uri with latest jar plugin produces errors like: ignite-extdata-uri: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them Seems that jar plugin doesn't like when build produces multiple jars even if they finalName's are different. Reworking build configuration with classifiers fixed the problem. I've created a PR with proposed changes: https://github.com/apache/ignite/pull/9116, comments are welcome -- Sincerely yours, Ivan Daschinskiy
Re: Building with maven 3.8.1
And so what? There are no changes in pom's (in this PR) that break build on earlier maven versions. Why we should trust this patch (moreover, it breaks even some travis ci checks) пн, 24 мая 2021 г. в 10:09, Petr Ivanov : > > Our TeamCity currently does not support 3.8.1 maven build runner. > I think it will be available with 2021.1 version that is going to be > delivered soon. > > > > On 21 May 2021, at 12:28, Ivan Daschinsky wrote: > > > > Hi. But where is TC run? And I suppose, that > > https://travis-ci.com/github/apache/ignite/jobs/506675544 should be at > > least fixed > > > > пт, 21 мая 2021 г. в 10:22, Petr Ivanov : > >> > >> Hi, Ilya. > >> > >> > >> Left small comment on formatting issue. > >> Otherwise looks good! > >> > >> > >> Considering 3.8.1 maven support — we will be migrating builds there after > >> TC 2021.1 will be delivered. > >> > >> > >>> On 20 May 2021, at 19:22, Ilya Korol wrote: > >>> > >>> Hi, all. > >>> > >>> Maybe someone has already faced the issue with Ignite and latest Maven > >>> release 3.8.1? > >>> > >>> https://issues.apache.org/jira/browse/IGNITE-14753 > >>> > >>> From 3.8.1 maven supplied with config that will block any http > >>> repository/mirror. (See details here > >>> https://maven.apache.org/docs/3.8.1/release-notes.html#cve-2021-26291) > >>> > >>> Attempt to perform a build produces several errors: > >>> > >>> > >>> 1. Third party dependencies > >>> > >>> 1.1) jta, hibernate-4.2, hibernate-5.1, hibernate-5.3 (btw hibernate-* > >>> modules aren't built during mvn install) > >>> > >>> org.ow2.jotm:jotm-core:jar:2.2.3 > >>> -> org.ow2.carol:carol:jar:3.0.8 > >>> -> org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 > >>> > >>> jotm is a test dependency. Switch to latest available version 2.3.1-M1 > >>> did the trick. I didn't find any changelog for latest jotm release (their > >>> site jotm.ow2.org seems a bit abandoned). I checked a little the diff > >>> between 2.2.3 and 2.3.1-M1 source jars. Seems that there was some changes > >>> in RMI related facilities, but i don't have enough expertise make a > >>> conclusion that switch to 2.3.1-M1 would be safe (even if tests would be > >>> green). Due to state of JOTM project maybe we should consider using > >>> another JTA implementation with ongoing support like Atomicos or Narayana > >>> (this implementation is also from the JBoss family like Hibernate)? > >>> > >>> 1.2) spark > >>> > >>> [ERROR] Failed to execute goal on project ignite-spark: Could not resolve > >>> dependencies for project > >>> org.apache.ignite:ignite-spark:jar:2.11.0-SNAPSHOT: Failed to collect > >>> dependencies at org.apache.spark:spark-core_2.11:jar:2.3.0 -> > >>> net.java.dev.jets3t:jets3t:jar:0.9.4 -> > >>> commons-codec:commons-codec:jar:1.15-SNAPSHOT: Failed to read artifact > >>> descriptor for commons-codec:commons-codec:jar:1.15-SNAPSHOT: Could not > >>> transfer artifact commons-codec:commons-codec:pom:1.15-SNAPSHOT from/to > >>> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for > >>> repositories: [apache.snapshots (http://repository.apache.org/snapshots, > >>> default, snapshots)] -> [Help 1] > >>> > >>> Updating to latest spark-core_2.11 maintenance version (2.3.0 -> 2.3.4) > >>> did the job. > >>> > >>> > >>> 2. Broken plugins configuration > >>> > >>> Currently ignite-parent uses org.apache:apache:16 as parent. Up to 18 > >>> release apache used http schema in different places of its configuration > >>> (e.g. snapshot repository). So i guess its a good reason to update apache > >>> parent at least to 18 release or maybe even to latest 23. This upgrade > >>> will break builds for several modules: > >>> > >>> 2.1) maven-jar-plugin */useDefaultManifestFile/* option was removed, so > >>> usage of this option (true for ignite) will break the build. I guess we > >>> can safely remove it from parent pom. > >>> > >>> 2.2) Classifiers in ignite-exdata-uri. Building ignite-exdata-uri with > >>> latest jar plugin produces errors like: > >>> > >>>ignite-extdata-uri: You have to use a classifier to attach > >>> supplemental artifacts to the project instead of replacing them > >>> > >>> Seems that jar plugin doesn't like when build produces multiple jars even > >>> if they finalName's are different. Reworking build configuration with > >>> classifiers fixed the problem. > >>> > >>> > >>> I've created a PR with proposed changes: > >>> https://github.com/apache/ignite/pull/9116, comments are welcome > >>> > >> > > > > > > -- > > Sincerely yours, Ivan Daschinskiy > -- Sincerely yours, Ivan Daschinskiy
Re: Building with maven 3.8.1
Our TeamCity currently does not support 3.8.1 maven build runner. I think it will be available with 2021.1 version that is going to be delivered soon. > On 21 May 2021, at 12:28, Ivan Daschinsky wrote: > > Hi. But where is TC run? And I suppose, that > https://travis-ci.com/github/apache/ignite/jobs/506675544 should be at > least fixed > > пт, 21 мая 2021 г. в 10:22, Petr Ivanov : >> >> Hi, Ilya. >> >> >> Left small comment on formatting issue. >> Otherwise looks good! >> >> >> Considering 3.8.1 maven support — we will be migrating builds there after TC >> 2021.1 will be delivered. >> >> >>> On 20 May 2021, at 19:22, Ilya Korol wrote: >>> >>> Hi, all. >>> >>> Maybe someone has already faced the issue with Ignite and latest Maven >>> release 3.8.1? >>> >>> https://issues.apache.org/jira/browse/IGNITE-14753 >>> >>> From 3.8.1 maven supplied with config that will block any http >>> repository/mirror. (See details here >>> https://maven.apache.org/docs/3.8.1/release-notes.html#cve-2021-26291) >>> >>> Attempt to perform a build produces several errors: >>> >>> >>> 1. Third party dependencies >>> >>> 1.1) jta, hibernate-4.2, hibernate-5.1, hibernate-5.3 (btw hibernate-* >>> modules aren't built during mvn install) >>> >>> org.ow2.jotm:jotm-core:jar:2.2.3 >>> -> org.ow2.carol:carol:jar:3.0.8 >>> -> org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 >>> >>> jotm is a test dependency. Switch to latest available version 2.3.1-M1 did >>> the trick. I didn't find any changelog for latest jotm release (their site >>> jotm.ow2.org seems a bit abandoned). I checked a little the diff between >>> 2.2.3 and 2.3.1-M1 source jars. Seems that there was some changes in RMI >>> related facilities, but i don't have enough expertise make a conclusion >>> that switch to 2.3.1-M1 would be safe (even if tests would be green). Due >>> to state of JOTM project maybe we should consider using another JTA >>> implementation with ongoing support like Atomicos or Narayana (this >>> implementation is also from the JBoss family like Hibernate)? >>> >>> 1.2) spark >>> >>> [ERROR] Failed to execute goal on project ignite-spark: Could not resolve >>> dependencies for project >>> org.apache.ignite:ignite-spark:jar:2.11.0-SNAPSHOT: Failed to collect >>> dependencies at org.apache.spark:spark-core_2.11:jar:2.3.0 -> >>> net.java.dev.jets3t:jets3t:jar:0.9.4 -> >>> commons-codec:commons-codec:jar:1.15-SNAPSHOT: Failed to read artifact >>> descriptor for commons-codec:commons-codec:jar:1.15-SNAPSHOT: Could not >>> transfer artifact commons-codec:commons-codec:pom:1.15-SNAPSHOT from/to >>> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for >>> repositories: [apache.snapshots (http://repository.apache.org/snapshots, >>> default, snapshots)] -> [Help 1] >>> >>> Updating to latest spark-core_2.11 maintenance version (2.3.0 -> 2.3.4) did >>> the job. >>> >>> >>> 2. Broken plugins configuration >>> >>> Currently ignite-parent uses org.apache:apache:16 as parent. Up to 18 >>> release apache used http schema in different places of its configuration >>> (e.g. snapshot repository). So i guess its a good reason to update apache >>> parent at least to 18 release or maybe even to latest 23. This upgrade will >>> break builds for several modules: >>> >>> 2.1) maven-jar-plugin */useDefaultManifestFile/* option was removed, so >>> usage of this option (true for ignite) will break the build. I guess we can >>> safely remove it from parent pom. >>> >>> 2.2) Classifiers in ignite-exdata-uri. Building ignite-exdata-uri with >>> latest jar plugin produces errors like: >>> >>>ignite-extdata-uri: You have to use a classifier to attach supplemental >>> artifacts to the project instead of replacing them >>> >>> Seems that jar plugin doesn't like when build produces multiple jars even >>> if they finalName's are different. Reworking build configuration with >>> classifiers fixed the problem. >>> >>> >>> I've created a PR with proposed changes: >>> https://github.com/apache/ignite/pull/9116, comments are welcome >>> >> > > > -- > Sincerely yours, Ivan Daschinskiy
