[jira] [Updated] (GEODE-5892) File's absolute path does not change after user.dir is changed in jdk11
[
https://issues.apache.org/jira/browse/GEODE-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5892:
--
Labels: pull-request-available (was: )
> File's absolute path does not change after user.dir is changed in jdk11
> ---
>
> Key: GEODE-5892
> URL: https://issues.apache.org/jira/browse/GEODE-5892
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> File relativeFile1 = new File("abc.txt");
> System.setProperty("user.dir", "/somewhereElse");
> File relativeFile2 = new File("abc.txt");
> System.out.println(relativeFile1.getAbsolutePath());
> System.out.println(relativeFile2.getAbsolutePath());
> {noformat}
> pre jdk11, the code above will print out "/somewhereElse/abc.txt" in both
> lines, even though the relativeFile objects still point to the files under
> the old user.dir. But in jdk11, the above code will print out "old
> user.dir/abc.txt" in both lines.
> dynamically change user.dir would not affect the relative file's absolute
> path anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654651#comment-16654651
]
ASF subversion and git services commented on GEODE-5803:
Commit 41e271e7bcafbc91aee58764e55db916a74fd92a in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=41e271e ]
Geode 5803 distributed test (#2613)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 geode-core:distributedTest does not need test or integrationTest
Move refactors only
Gradle changes to trigger
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654652#comment-16654652
]
ASF subversion and git services commented on GEODE-5803:
Commit 41e271e7bcafbc91aee58764e55db916a74fd92a in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=41e271e ]
Geode 5803 distributed test (#2613)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 geode-core:distributedTest does not need test or integrationTest
Move refactors only
Gradle changes to trigger
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654650#comment-16654650
]
ASF subversion and git services commented on GEODE-5803:
Commit 41e271e7bcafbc91aee58764e55db916a74fd92a in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=41e271e ]
Geode 5803 distributed test (#2613)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 geode-core:distributedTest does not need test or integrationTest
Move refactors only
Gradle changes to trigger
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654653#comment-16654653
]
ASF subversion and git services commented on GEODE-5803:
Commit 41e271e7bcafbc91aee58764e55db916a74fd92a in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=41e271e ]
Geode 5803 distributed test (#2613)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 geode-core:distributedTest does not need test or integrationTest
Move refactors only
Gradle changes to trigger
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654461#comment-16654461
]
ASF subversion and git services commented on GEODE-5803:
Commit 898a06a414eeb2b3d6d0d8fd7951d022730728a3 in geode's branch
refs/heads/feature/GEODE-5875 from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=898a06a ]
GEODE-5803 Make geode-core:integrationTest not need geode-core:test (#2612)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* Bump to rerun precheckin after Concourse instability.
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5893) RepeatTest task was broken by upgrade of docker plugin
[ https://issues.apache.org/jira/browse/GEODE-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654462#comment-16654462 ] ASF subversion and git services commented on GEODE-5893: Commit e0b172591bb1cc2af604fa5eefe4d961c6562ff4 in geode's branch refs/heads/feature/GEODE-5875 from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e0b1725 ] GEODE-5893: Keep docker configuration in RepeatTest The RepeatTest task was not retaining the workerProcessFactory installed by the docker plugin, because the new version of the docker plugin used a different implementation of TestExcecutor. > RepeatTest task was broken by upgrade of docker plugin > -- > > Key: GEODE-5893 > URL: https://issues.apache.org/jira/browse/GEODE-5893 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Time Spent: 40m > Remaining Estimate: 0h > > The repeatXXXTest targets are not running in separate docker containers, > after the upgrade of the docker plugin in 4e8ea1c5fa. > The issue appears to be that the new version of the plugin has a new > implementation of TestExecutor. RepeatTest.groovy previously had a workaround > to make sure it preserved the modifications made to the executor by the > docker plugin, but that workaround is not working with the new version of the > plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654458#comment-16654458
]
ASF subversion and git services commented on GEODE-5803:
Commit 898a06a414eeb2b3d6d0d8fd7951d022730728a3 in geode's branch
refs/heads/feature/GEODE-5875 from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=898a06a ]
GEODE-5803 Make geode-core:integrationTest not need geode-core:test (#2612)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* Bump to rerun precheckin after Concourse instability.
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654460#comment-16654460
]
ASF subversion and git services commented on GEODE-5803:
Commit 898a06a414eeb2b3d6d0d8fd7951d022730728a3 in geode's branch
refs/heads/feature/GEODE-5875 from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=898a06a ]
GEODE-5803 Make geode-core:integrationTest not need geode-core:test (#2612)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* Bump to rerun precheckin after Concourse instability.
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5875) gfsh destroy jndi-binding command actually removes all data sources
[
https://issues.apache.org/jira/browse/GEODE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654463#comment-16654463
]
ASF subversion and git services commented on GEODE-5875:
Commit db00af460ff9d5edc4f0588422af67370d7644d5 in geode's branch
refs/heads/feature/GEODE-5875 from [~dschneider]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=db00af4 ]
Merge branch 'develop' into feature/GEODE-5875
> gfsh destroy jndi-binding command actually removes all data sources
> ---
>
> Key: GEODE-5875
> URL: https://issues.apache.org/jira/browse/GEODE-5875
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jianxia Chen
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When executing gfsh command {{destroy jndi-binding}}, besides the targeted
> data source, the other data sources will be partially released early.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654453#comment-16654453 ] ASF subversion and git services commented on GEODE-5864: Commit b6158bf09a1e5e832d6d564a1b780096084c598b in geode's branch refs/heads/feature/GEODE-5875 from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b6158bf ] GEODE-5864: Adds support for private/public github. Co-authored-by: Robert Houghton Co-authored-by: Jacob Barrett > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654457#comment-16654457
]
ASF subversion and git services commented on GEODE-5803:
Commit 898a06a414eeb2b3d6d0d8fd7951d022730728a3 in geode's branch
refs/heads/feature/GEODE-5875 from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=898a06a ]
GEODE-5803 Make geode-core:integrationTest not need geode-core:test (#2612)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* Bump to rerun precheckin after Concourse instability.
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654447#comment-16654447 ] ASF subversion and git services commented on GEODE-5864: Commit c80d85baafee1d2e296130d49528d633c9b035ea in geode's branch refs/heads/feature/GEODE-5875 from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c80d85b ] Merge pull request #2639 from rhoughton-pivot/GEODE-5864 [GEODE-5864] Get rid of docker-geode-build-resource. > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5676) ClusterConfigLocatorRestartDUnitTest hung in CI
[
https://issues.apache.org/jira/browse/GEODE-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654449#comment-16654449
]
ASF subversion and git services commented on GEODE-5676:
Commit df30df1c8e9a1216a3f9bd07b712e3c4fa99031d in geode's branch
refs/heads/feature/GEODE-5875 from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=df30df1 ]
GEODE-5676: Disconnect system before closing SocketCreatorFactory
The MemberStarterRule was closing SocketCreatorFactory before calling
DistributedSystem.disconnect. In the case of
ClusterConfigLocatorRestartDUnitTest there was a reconnect thread
running in the background that ended up throwing a NullPointerException
if the SocketCreatorFactory was closed. This led to an infinite loop in
the reconnect thread.
We should not be messing with the internal state of Geode until we call
disconnect to stop all of Geode's background threads.
Co-Authored-By: Dale Emery
> ClusterConfigLocatorRestartDUnitTest hung in CI
> ---
>
> Key: GEODE-5676
> URL: https://issues.apache.org/jira/browse/GEODE-5676
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.8.0
>
> Attachments: callstacks.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This test hung in a couple of runs of DistributedTest
>
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds//430
>
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds//370
> {noformat}
> Started @ 2018-08-30 04:23:46.599 +
> 2018-08-30 04:48:33.135 +
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> serverRestartsAfterLocatorReconnects
> Ended @ 2018-08-30 05:21:34.897 +
> {noformat}
> It seems to be stuck in tear down
> {noformat}
> "ReconnectThread" #416 prio=5 os_prio=0 tid=0x7fa86cad2000 nid=0xd07 in
> Object.wait() [0x7fa744ecd000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2697)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2558)
> - locked <0xe00bedc8> (a java.lang.Object)
> - locked <0xe07af498> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xe00bedd8> (a java.lang.Class for
> org.apache.geode.cache.CacheFactory)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1041)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:3987)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1552)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$1(GMSMembershipManager.java:2564)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager$$Lambda$81/1816825082.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> "RMI TCP Connection(8)-172.17.0.13" #32 daemon prio=5 os_prio=0
> tid=0x7fa874001800 nid=0x2ff waiting for monitor entry
> [0x7fa8f0d15000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1367)
> - waiting to lock <0xe07af498> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1022)
> at
> org.apache.geode.test.junit.rules.MemberStarterRule.disconnectDSIfAny(MemberStarterRule.java:182)
> at
> org.apache.geode.test.junit.rules.MemberStarterRule.after(MemberStarterRule.java:129)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.stopElementInsideVM(ClusterStartupRule.java:385)
> at
> org.apache.geode.test.junit.rules.VMProvider.lambda$stop$fe0d42dc$1(VMProvider.java:42)
> at
> org.apache.geode.test.junit.rules.VMProvider$$Lambda$77/1844235204.run(Unknown
> Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Commented] (GEODE-5857) Race conditions during JMX registration and cleanup
[ https://issues.apache.org/jira/browse/GEODE-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654452#comment-16654452 ] ASF subversion and git services commented on GEODE-5857: Commit 76420dcd93e17f009aa73ca8188d135158358323 in geode's branch refs/heads/feature/GEODE-5875 from [~mcmellawatt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=76420dc ] GEODE-5857: Handle JMX race conditions during registration and cleanup > Race conditions during JMX registration and cleanup > --- > > Key: GEODE-5857 > URL: https://issues.apache.org/jira/browse/GEODE-5857 > Project: Geode > Issue Type: Bug > Components: jmx, management >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Unregistering an MBean twice results in an InstanceNotFoundException, which > gets wrapped in a ManagementException and logged as a warning. This should > not be a warning as an InstanceNotFoundException implies the MBean has > already been unregistered, and a second unregistration is basically a no-op. > The same logic applies to registration of an MBean -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5845) Document that an enum should never be used for keys
[ https://issues.apache.org/jira/browse/GEODE-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654454#comment-16654454 ] ASF subversion and git services commented on GEODE-5845: Commit 2f5fe0a8bcbd3245531abf33e43adae2f93f0272 in geode's branch refs/heads/feature/GEODE-5875 from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f5fe0a ] GEODE-5845 Document not to use enums for keys (#2605) * GEODE-5845 Document not to use enums for keys * GEODE-5845 Revise docs (on not having enums as keys) per review > Document that an enum should never be used for keys > --- > > Key: GEODE-5845 > URL: https://issues.apache.org/jira/browse/GEODE-5845 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Maybe it should be obvious, but an enum type should never be used for an > entry key. To make this explicitly clear, add this advice to the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5844) String.Format() argument mismatch in SystemAdmin.initHelpMap()
[ https://issues.apache.org/jira/browse/GEODE-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654450#comment-16654450 ] ASF subversion and git services commented on GEODE-5844: Commit 567569bb129d1d8acc0a709edf8b0f4e73be7c92 in geode's branch refs/heads/feature/GEODE-5875 from [~propeller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=567569b ] GEODE-5844: Make log format match args > String.Format() argument mismatch in SystemAdmin.initHelpMap() > -- > > Key: GEODE-5844 > URL: https://issues.apache.org/jira/browse/GEODE-5844 > Project: Geode > Issue Type: Bug > Components: general >Reporter: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > An argument count in String.Format() mismatch can cause a > java.util.MissingFormatArgumentException exception for some commands in > SystemAdmin.initHelpMap(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5879) Use and enforce consistent gradle declaration behavior
[ https://issues.apache.org/jira/browse/GEODE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654451#comment-16654451 ] ASF subversion and git services commented on GEODE-5879: Commit 89105618d7877cce23ffa7456ba97aec621c1160 in geode's branch refs/heads/feature/GEODE-5875 from [~rhoughton] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8910561 ] GEODE-5879 Enforces consistent syntax in gradle dependency declaration (#2611) Always use a parentesis around the thing being depended on. Do not space pad between configuration and parenthesis before dependency Prefer single quote around the package names Co-authored-by: Robert Houghton Co-authored-by: Patrick Rhomberg > Use and enforce consistent gradle declaration behavior > -- > > Key: GEODE-5879 > URL: https://issues.apache.org/jira/browse/GEODE-5879 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Gradle syntax is permissive about dependency declaration, unless exclusions > are needed. Then the input must be in a parenthetical block before opening > the closure. Fix this everywhere, and then use a spotless rule to make it > consistent forever -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654448#comment-16654448 ] ASF subversion and git services commented on GEODE-5864: Commit c80d85baafee1d2e296130d49528d633c9b035ea in geode's branch refs/heads/feature/GEODE-5875 from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c80d85b ] Merge pull request #2639 from rhoughton-pivot/GEODE-5864 [GEODE-5864] Get rid of docker-geode-build-resource. > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5845) Document that an enum should never be used for keys
[ https://issues.apache.org/jira/browse/GEODE-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654455#comment-16654455 ] ASF subversion and git services commented on GEODE-5845: Commit 2f5fe0a8bcbd3245531abf33e43adae2f93f0272 in geode's branch refs/heads/feature/GEODE-5875 from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f5fe0a ] GEODE-5845 Document not to use enums for keys (#2605) * GEODE-5845 Document not to use enums for keys * GEODE-5845 Revise docs (on not having enums as keys) per review > Document that an enum should never be used for keys > --- > > Key: GEODE-5845 > URL: https://issues.apache.org/jira/browse/GEODE-5845 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Maybe it should be obvious, but an enum type should never be used for an > entry key. To make this explicitly clear, add this advice to the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5845) Document that an enum should never be used for keys
[ https://issues.apache.org/jira/browse/GEODE-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654456#comment-16654456 ] ASF subversion and git services commented on GEODE-5845: Commit 2f5fe0a8bcbd3245531abf33e43adae2f93f0272 in geode's branch refs/heads/feature/GEODE-5875 from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f5fe0a ] GEODE-5845 Document not to use enums for keys (#2605) * GEODE-5845 Document not to use enums for keys * GEODE-5845 Revise docs (on not having enums as keys) per review > Document that an enum should never be used for keys > --- > > Key: GEODE-5845 > URL: https://issues.apache.org/jira/browse/GEODE-5845 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Maybe it should be obvious, but an enum type should never be used for an > entry key. To make this explicitly clear, add this advice to the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5861) JDBC Connector should use gfsh jndi-binding instead of jdbc-connection
[
https://issues.apache.org/jira/browse/GEODE-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5861:
--
Labels: pull-request-available (was: )
> JDBC Connector should use gfsh jndi-binding instead of jdbc-connection
> --
>
> Key: GEODE-5861
> URL: https://issues.apache.org/jira/browse/GEODE-5861
> Project: Geode
> Issue Type: Improvement
> Components: extensions
>Reporter: Jianxia Chen
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
>
> In Geode there are two {{gfsh}} commands {{create jndi-binding}} and {{create
> jdbc-connection}} which try to accomplish the same goal. We should:
> * Change JDBC Connector to use the JNDI binding, instead of the JDBC
> Connection
> * Remove the {{create jdbc-connection}} command.
> * Remove the {{destroy jdbc-connection}} command
> * Remove the {{list jdbc-connection}} command.
> * Remove the {{describe jdbc-connection}} command
> * Remove the {{alter jdbc-connnection}} command
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5890) gateway events from the same distributed system did not check misorder
[
https://issues.apache.org/jira/browse/GEODE-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5890:
--
Labels: pull-request-available (was: )
> gateway events from the same distributed system did not check misorder
> --
>
> Key: GEODE-5890
> URL: https://issues.apache.org/jira/browse/GEODE-5890
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> Host name: rs-GEM-2228-1638a2i3xlarge-hydra-client-28
> OS name: Linux
> Architecture: amd64
> OS version: 3.10.0-862.11.6.el7.x86_64
> Java version: 1.8.0_181
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /usr/local/regr/jdk/jdk1.8.0_181/jre
> #
> Product
> Product-Name: Pivotal GemFire
> Product-Version: 9.6.0
> Native version: native code unavailable
> Build
> Build-Date: 2018-09-18 00:33:49 +
> Build-Id: root 9
> Build-Java-Version: 1.8.0_171
> Build-Platform: Linux 4.4.0-89-generic amd64
> Open
> Source-Date: 2018-09-18 00:29:00 +
> Source-Repository: support/9.6
> Source-Revision: b404fab8c4fe962dc8adab827034efdbc93ab861
> Closed
> GemFire-Source-Date: 2018-09-10 23:15:03 +
> GemFire-Source-Repository: support/9.6
> GemFire-Source-Revision: f5a2b5ec6e6144a0635c41d1605b4586dd8acc6a
> Running on: /10.32.111.152, 4 cpu(s), amd64 Linux
> 3.10.0-862.11.6.el7.x86_64
> #
> Test was run from versioning/newWan/wanVersioning.bt
> Test:
> versioning/newWan/parRegSerialSenderKeysPerWanHct.conf
> bridgeHostsPerSite=3
> bridgeThreadsPerVM=2
> bridgeVMsPerHost=1
> clientMem=256m
> edgeHostsPerSite=2
> edgeThreadsPerVM=5
> edgeVMsPerHost=1
> enableFailover=true
> locatorHostsPerSite=1
> locatorThreadsPerVM=2
> locatorVMsPerHost=1
> maxOps=2
> redundantCopies=1
> resultWaitSec=1200
> serverMem=256m
> wanSites=4
> Run with local.conf:
> hydra.Prms-randomSeed=1537256262399;
> hydra.Prms-randomSeed=1537256262399;
> hydra.GemFirePrms-logLevel = fine;
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1537256262399;
> *** Test failed with this error:
> CLIENT vm_17_thr_50_edge_3_2_host1_11693
> TASK[0] versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA
> ERROR util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> at
> newWan.WANOperationsClient.verifyRegionContents(WANOperationsClient.java:1089)
> at
> versioning.newWan.WanConflictResolverTest.validateEntryOperationFromBBSnapshot(WanConflictResolverTest.java:364)
> at
> versioning.newWan.WanConflictResolverTest.doOpsAndValidateHA(WanConflictResolverTest.java:319)
> at
> versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA(WanConflictResolverTest.java:111)
> at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.execute(MethExecutor.java:181)
> at hydra.MethExecutor.execute(MethExecutor.java:149)
> at hydra.TestTask.execute(TestTask.java:197)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:213)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5890) gateway events from the same distributed system did not check misorder
[
https://issues.apache.org/jira/browse/GEODE-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654412#comment-16654412
]
ASF subversion and git services commented on GEODE-5890:
Commit d0fb21aaae7425f18d049df6ea270fc34d8b6158 in geode's branch
refs/heads/feature/GEODE-5890 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d0fb21a ]
GEODE-5890: gateway events from the same distributed system should check
misorder
> gateway events from the same distributed system did not check misorder
> --
>
> Key: GEODE-5890
> URL: https://issues.apache.org/jira/browse/GEODE-5890
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>
> {noformat}
> Host name: rs-GEM-2228-1638a2i3xlarge-hydra-client-28
> OS name: Linux
> Architecture: amd64
> OS version: 3.10.0-862.11.6.el7.x86_64
> Java version: 1.8.0_181
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /usr/local/regr/jdk/jdk1.8.0_181/jre
> #
> Product
> Product-Name: Pivotal GemFire
> Product-Version: 9.6.0
> Native version: native code unavailable
> Build
> Build-Date: 2018-09-18 00:33:49 +
> Build-Id: root 9
> Build-Java-Version: 1.8.0_171
> Build-Platform: Linux 4.4.0-89-generic amd64
> Open
> Source-Date: 2018-09-18 00:29:00 +
> Source-Repository: support/9.6
> Source-Revision: b404fab8c4fe962dc8adab827034efdbc93ab861
> Closed
> GemFire-Source-Date: 2018-09-10 23:15:03 +
> GemFire-Source-Repository: support/9.6
> GemFire-Source-Revision: f5a2b5ec6e6144a0635c41d1605b4586dd8acc6a
> Running on: /10.32.111.152, 4 cpu(s), amd64 Linux
> 3.10.0-862.11.6.el7.x86_64
> #
> Test was run from versioning/newWan/wanVersioning.bt
> Test:
> versioning/newWan/parRegSerialSenderKeysPerWanHct.conf
> bridgeHostsPerSite=3
> bridgeThreadsPerVM=2
> bridgeVMsPerHost=1
> clientMem=256m
> edgeHostsPerSite=2
> edgeThreadsPerVM=5
> edgeVMsPerHost=1
> enableFailover=true
> locatorHostsPerSite=1
> locatorThreadsPerVM=2
> locatorVMsPerHost=1
> maxOps=2
> redundantCopies=1
> resultWaitSec=1200
> serverMem=256m
> wanSites=4
> Run with local.conf:
> hydra.Prms-randomSeed=1537256262399;
> hydra.Prms-randomSeed=1537256262399;
> hydra.GemFirePrms-logLevel = fine;
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1537256262399;
> *** Test failed with this error:
> CLIENT vm_17_thr_50_edge_3_2_host1_11693
> TASK[0] versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA
> ERROR util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> at
> newWan.WANOperationsClient.verifyRegionContents(WANOperationsClient.java:1089)
> at
> versioning.newWan.WanConflictResolverTest.validateEntryOperationFromBBSnapshot(WanConflictResolverTest.java:364)
> at
> versioning.newWan.WanConflictResolverTest.doOpsAndValidateHA(WanConflictResolverTest.java:319)
> at
> versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA(WanConflictResolverTest.java:111)
> at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.execute(MethExecutor.java:181)
> at hydra.MethExecutor.execute(MethExecutor.java:149)
> at hydra.TestTask.execute(TestTask.java:197)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:213)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5628) CI Failure: WANRollingUpgradeEventProcessingMixedSiteOneOldSiteTwo
[
https://issues.apache.org/jira/browse/GEODE-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-5628.
--
Resolution: Fixed
> CI Failure: WANRollingUpgradeEventProcessingMixedSiteOneOldSiteTwo
> --
>
> Key: GEODE-5628
> URL: https://issues.apache.org/jira/browse/GEODE-5628
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Sai Boorlagadda
>Assignee: Ryan McMahon
>Priority: Major
> Labels: pull-request-available, swat
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CI Run: https://concourse.apachegeode-ci.info/builds/20378
> Build artifacts:
> http://files.apachegeode-ci.info/builds/geode-pr-2357/test-results/upgradeTest/1535044814/
> {code:java}
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneOldSiteTwo
> > EventProcessingMixedSiteOneOldSiteTwo[from_v150] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneOldSiteTwo$$Lambda$41/436821547.run
> in VM 4 running on Host 460446c8f083 with 7 VMs with version 150
> at org.apache.geode.test.dunit.VM.invoke(VM.java:450)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:419)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:362)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneOldSiteTwo.EventProcessingMixedSiteOneOldSiteTwo(WANRollingUpgradeEventProcessingMixedSiteOneOldSiteTwo.java:68)
> Caused by:
> java.net.BindException: Failed to create server socket on
> null[25,312]
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:752)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:709)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:675)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:240)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:224)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:219)
> at
> org.apache.geode.distributed.internal.InternalLocator.startTcpServer(InternalLocator.java:485)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:542)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:305)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:103)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:95)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneOldSiteTwo.lambda$EventProcessingMixedSiteOneOldSiteTwo$67afc7f8$1(WANRollingUpgradeEventProcessingMixedSiteOneOldSiteTwo.java:68)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:375)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:748)
> ... 13 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5401) Client transaction should not be expired once it is failed over
[ https://issues.apache.org/jira/browse/GEODE-5401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-5401. - Resolution: Fixed Fix Version/s: 1.7.0 > Client transaction should not be expired once it is failed over > --- > > Key: GEODE-5401 > URL: https://issues.apache.org/jira/browse/GEODE-5401 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.7.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > When a client is disconnected from the server, the client's originated > transactions are scheduled to be expired. However, when the client > transaction failed over, the expire transaction task is not cancelled. If > transaction is not finished/committed within the timeout period > (transactionTimeToLive default to 180 seconds), the transaction will be > expired. > The consequence is that only part of the transaction gets committed. The > expire transaction task will close the transaction and remove it from the > hosted txstates map removing the existing operations. The subsequent > operations will starts a new transaction -- only the operations afterwards > will be recored and committed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5401) Client transaction should not be expired once it is failed over
[ https://issues.apache.org/jira/browse/GEODE-5401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-5401: Affects Version/s: (was: 1.7.0) > Client transaction should not be expired once it is failed over > --- > > Key: GEODE-5401 > URL: https://issues.apache.org/jira/browse/GEODE-5401 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.7.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > When a client is disconnected from the server, the client's originated > transactions are scheduled to be expired. However, when the client > transaction failed over, the expire transaction task is not cancelled. If > transaction is not finished/committed within the timeout period > (transactionTimeToLive default to 180 seconds), the transaction will be > expired. > The consequence is that only part of the transaction gets committed. The > expire transaction task will close the transaction and remove it from the > hosted txstates map removing the existing operations. The subsequent > operations will starts a new transaction -- only the operations afterwards > will be recored and committed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5895) Rolling upgrade tests can fail with port conflicts with dunit debugger ports
Dan Smith created GEODE-5895:
Summary: Rolling upgrade tests can fail with port conflicts with
dunit debugger ports
Key: GEODE-5895
URL: https://issues.apache.org/jira/browse/GEODE-5895
Project: Geode
Issue Type: Improvement
Reporter: Dan Smith
We recently had a rolling upgrade test fail with an address already in use
failure. Tracking this down, it looks like the issue is that the we picked an
available port, and then bounced a dunit VM. When the VM restarted it picked
that same port to listener for debugging connections.
Failure:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.8.0-build.9/test-results/distributedTest/1539810558/
{noformat}
Bouncing VM5 from version 160 to 000
Old process for vm_5 has exited
Executing [/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -classpath,
[jira] [Updated] (GEODE-5895) Rolling upgrade tests can fail with port conflicts with dunit debugger ports
[
https://issues.apache.org/jira/browse/GEODE-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5895:
-
Labels: swat (was: )
> Rolling upgrade tests can fail with port conflicts with dunit debugger ports
>
>
> Key: GEODE-5895
> URL: https://issues.apache.org/jira/browse/GEODE-5895
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Priority: Major
> Labels: swat
>
> We recently had a rolling upgrade test fail with an address already in use
> failure. Tracking this down, it looks like the issue is that the we picked an
> available port, and then bounced a dunit VM. When the VM restarted it picked
> that same port to listener for debugging connections.
> Failure:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.8.0-build.9/test-results/distributedTest/1539810558/
> {noformat}
> Bouncing VM5 from version 160 to 000
> Old process for vm_5 has exited
> Executing [/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -classpath,
>
[jira] [Updated] (GEODE-5894) bouncycastle is misspelled as bounty-castle in dependency-versions.properties
[
https://issues.apache.org/jira/browse/GEODE-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5894:
--
Labels: pull-request-available (was: )
> bouncycastle is misspelled as bounty-castle in dependency-versions.properties
> -
>
> Key: GEODE-5894
> URL: https://issues.apache.org/jira/browse/GEODE-5894
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>Priority: Trivial
> Labels: pull-request-available
>
> {noformat}
> geode-junit/build.gradle
> 41: compile('org.bouncycastle:bcpkix-jdk15on:' +
> project.'bounty-castle.version')
> gradle/dependency-versions.properties
> 21:bounty-castle.version = 1.59
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5894) bouncycastle is misspelled as bounty-castle in dependency-versions.properties
[
https://issues.apache.org/jira/browse/GEODE-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-5894:
Priority: Trivial (was: Major)
> bouncycastle is misspelled as bounty-castle in dependency-versions.properties
> -
>
> Key: GEODE-5894
> URL: https://issues.apache.org/jira/browse/GEODE-5894
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>Priority: Trivial
>
> {noformat}
> geode-junit/build.gradle
> 41: compile('org.bouncycastle:bcpkix-jdk15on:' +
> project.'bounty-castle.version')
> gradle/dependency-versions.properties
> 21:bounty-castle.version = 1.59
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5894) bouncycastle is misspelled as bounty-castle in dependency-versions.properties
[
https://issues.apache.org/jira/browse/GEODE-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan reassigned GEODE-5894:
---
Assignee: Galen O'Sullivan
> bouncycastle is misspelled as bounty-castle in dependency-versions.properties
> -
>
> Key: GEODE-5894
> URL: https://issues.apache.org/jira/browse/GEODE-5894
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>Priority: Major
>
> {noformat}
> geode-junit/build.gradle
> 41: compile('org.bouncycastle:bcpkix-jdk15on:' +
> project.'bounty-castle.version')
> gradle/dependency-versions.properties
> 21:bounty-castle.version = 1.59
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5894) bouncycastle is misspelled as bounty-castle in dependency-versions.properties
Galen O'Sullivan created GEODE-5894:
---
Summary: bouncycastle is misspelled as bounty-castle in
dependency-versions.properties
Key: GEODE-5894
URL: https://issues.apache.org/jira/browse/GEODE-5894
Project: Geode
Issue Type: Bug
Components: build
Reporter: Galen O'Sullivan
{noformat}
geode-junit/build.gradle
41: compile('org.bouncycastle:bcpkix-jdk15on:' +
project.'bounty-castle.version')
gradle/dependency-versions.properties
21:bounty-castle.version = 1.59
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5893) RepeatTest task was broken by upgrade of docker plugin
[ https://issues.apache.org/jira/browse/GEODE-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-5893. -- Resolution: Fixed > RepeatTest task was broken by upgrade of docker plugin > -- > > Key: GEODE-5893 > URL: https://issues.apache.org/jira/browse/GEODE-5893 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Time Spent: 40m > Remaining Estimate: 0h > > The repeatXXXTest targets are not running in separate docker containers, > after the upgrade of the docker plugin in 4e8ea1c5fa. > The issue appears to be that the new version of the plugin has a new > implementation of TestExecutor. RepeatTest.groovy previously had a workaround > to make sure it preserved the modifications made to the executor by the > docker plugin, but that workaround is not working with the new version of the > plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5893) RepeatTest task was broken by upgrade of docker plugin
[ https://issues.apache.org/jira/browse/GEODE-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654320#comment-16654320 ] ASF subversion and git services commented on GEODE-5893: Commit e0b172591bb1cc2af604fa5eefe4d961c6562ff4 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e0b1725 ] GEODE-5893: Keep docker configuration in RepeatTest The RepeatTest task was not retaining the workerProcessFactory installed by the docker plugin, because the new version of the docker plugin used a different implementation of TestExcecutor. > RepeatTest task was broken by upgrade of docker plugin > -- > > Key: GEODE-5893 > URL: https://issues.apache.org/jira/browse/GEODE-5893 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Time Spent: 40m > Remaining Estimate: 0h > > The repeatXXXTest targets are not running in separate docker containers, > after the upgrade of the docker plugin in 4e8ea1c5fa. > The issue appears to be that the new version of the plugin has a new > implementation of TestExecutor. RepeatTest.groovy previously had a workaround > to make sure it preserved the modifications made to the executor by the > docker plugin, but that workaround is not working with the new version of the > plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654304#comment-16654304
]
ASF subversion and git services commented on GEODE-5803:
Commit 898a06a414eeb2b3d6d0d8fd7951d022730728a3 in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=898a06a ]
GEODE-5803 Make geode-core:integrationTest not need geode-core:test (#2612)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* Bump to rerun precheckin after Concourse instability.
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654303#comment-16654303
]
ASF subversion and git services commented on GEODE-5803:
Commit 898a06a414eeb2b3d6d0d8fd7951d022730728a3 in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=898a06a ]
GEODE-5803 Make geode-core:integrationTest not need geode-core:test (#2612)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* Bump to rerun precheckin after Concourse instability.
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654305#comment-16654305
]
ASF subversion and git services commented on GEODE-5803:
Commit 898a06a414eeb2b3d6d0d8fd7951d022730728a3 in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=898a06a ]
GEODE-5803 Make geode-core:integrationTest not need geode-core:test (#2612)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* Bump to rerun precheckin after Concourse instability.
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654302#comment-16654302
]
ASF subversion and git services commented on GEODE-5803:
Commit 898a06a414eeb2b3d6d0d8fd7951d022730728a3 in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=898a06a ]
GEODE-5803 Make geode-core:integrationTest not need geode-core:test (#2612)
* GEODE-5803 Make geode-core:integrationTest not need geode-core:test
Move-refactor only, plus build.gradle to point integration at junit and
geode-core:distributedTest to use geode-core:test explicitly (to be
changed in next commit)
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Move refactor many test resources to the correct sourceSet
Continue breaking the dependency between integrationTest and test
sourceSets
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* GEODE-5803 Update assembly-content for new items in geode-junit
Move-refactor into geode-junit:main sourceSet has caused new classes to
appear on the assemblycontent test.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
* Bump to rerun precheckin after Concourse instability.
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5893) RepeatTest task was broken by upgrade of docker plugin
[ https://issues.apache.org/jira/browse/GEODE-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5893: -- Labels: pull-request-available swat (was: swat) > RepeatTest task was broken by upgrade of docker plugin > -- > > Key: GEODE-5893 > URL: https://issues.apache.org/jira/browse/GEODE-5893 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > > The repeatXXXTest targets are not running in separate docker containers, > after the upgrade of the docker plugin in 4e8ea1c5fa. > The issue appears to be that the new version of the plugin has a new > implementation of TestExecutor. RepeatTest.groovy previously had a workaround > to make sure it preserved the modifications made to the executor by the > docker plugin, but that workaround is not working with the new version of the > plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5893) RepeatTest task was broken by upgrade of docker plugin
[ https://issues.apache.org/jira/browse/GEODE-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-5893: - Summary: RepeatTest task was broken by upgrade of docker plugin (was: repeatXXXTest task was broken by upgrade of docker plugin) > RepeatTest task was broken by upgrade of docker plugin > -- > > Key: GEODE-5893 > URL: https://issues.apache.org/jira/browse/GEODE-5893 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: swat > > The repeatXXXTest targets are not running in separate docker containers, > after the upgrade of the docker plugin in 4e8ea1c5fa. > The issue appears to be that the new version of the plugin has a new > implementation of TestExecutor. RepeatTest.groovy previously had a workaround > to make sure it preserved the modifications made to the executor by the > docker plugin, but that workaround is not working with the new version of the > plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5893) repeatXXXTest task was broken by upgrade of docker plugin
[ https://issues.apache.org/jira/browse/GEODE-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-5893: Assignee: Dan Smith > repeatXXXTest task was broken by upgrade of docker plugin > - > > Key: GEODE-5893 > URL: https://issues.apache.org/jira/browse/GEODE-5893 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: swat > > The repeatXXXTest targets are not running in separate docker containers, > after the upgrade of the docker plugin in 4e8ea1c5fa. > The issue appears to be that the new version of the plugin has a new > implementation of TestExecutor. RepeatTest.groovy previously had a workaround > to make sure it preserved the modifications made to the executor by the > docker plugin, but that workaround is not working with the new version of the > plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5893) repeatXXXTest task was broken by upgrade of docker plugin
[ https://issues.apache.org/jira/browse/GEODE-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-5893: - Labels: swat (was: ) > repeatXXXTest task was broken by upgrade of docker plugin > - > > Key: GEODE-5893 > URL: https://issues.apache.org/jira/browse/GEODE-5893 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Priority: Major > Labels: swat > > The repeatXXXTest targets are not running in separate docker containers, > after the upgrade of the docker plugin in 4e8ea1c5fa. > The issue appears to be that the new version of the plugin has a new > implementation of TestExecutor. RepeatTest.groovy previously had a workaround > to make sure it preserved the modifications made to the executor by the > docker plugin, but that workaround is not working with the new version of the > plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5893) repeatXXXTest task was broken by upgrade of docker plugin
Dan Smith created GEODE-5893: Summary: repeatXXXTest task was broken by upgrade of docker plugin Key: GEODE-5893 URL: https://issues.apache.org/jira/browse/GEODE-5893 Project: Geode Issue Type: Improvement Reporter: Dan Smith The repeatXXXTest targets are not running in separate docker containers, after the upgrade of the docker plugin in 4e8ea1c5fa. The issue appears to be that the new version of the plugin has a new implementation of TestExecutor. RepeatTest.groovy previously had a workaround to make sure it preserved the modifications made to the executor by the docker plugin, but that workaround is not working with the new version of the plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5892) File's absolute path does not change after user.dir is changed in jdk11
[
https://issues.apache.org/jira/browse/GEODE-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654232#comment-16654232
]
Owen Nichols commented on GEODE-5892:
-
Which specific tests are failing on Java11 due to this?
> File's absolute path does not change after user.dir is changed in jdk11
> ---
>
> Key: GEODE-5892
> URL: https://issues.apache.org/jira/browse/GEODE-5892
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
>
> {noformat}
> File relativeFile1 = new File("abc.txt");
> System.setProperty("user.dir", "/somewhereElse");
> File relativeFile2 = new File("abc.txt");
> System.out.println(relativeFile1.getAbsolutePath());
> System.out.println(relativeFile2.getAbsolutePath());
> {noformat}
> pre jdk11, the code above will print out "/somewhereElse/abc.txt" in both
> lines, even though the relativeFile objects still point to the files under
> the old user.dir. But in jdk11, the above code will print out "old
> user.dir/abc.txt" in both lines.
> dynamically change user.dir would not affect the relative file's absolute
> path anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5787) Support graceful bouncing DUnit VMs on windows
[ https://issues.apache.org/jira/browse/GEODE-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654217#comment-16654217 ] ASF subversion and git services commented on GEODE-5787: Commit 8ace0e92244285b46866908b35caf05fdacda7c3 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Sai Boorlagadda [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8ace0e9 ] Merge branch 'develop' into feature/GEODE-5787-dunit-internal > Support graceful bouncing DUnit VMs on windows > -- > > Key: GEODE-5787 > URL: https://issues.apache.org/jira/browse/GEODE-5787 > Project: Geode > Issue Type: New Feature > Components: tests >Reporter: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > Process.destroy is not graceful on windows and causes distributed system to > get into suspect processing and network partition when used in DUnit to > restart VMs. > There were existing JDK > [bugs|https://bugs.openjdk.java.net/browse/JDK-8056139] open requesting for > supporting graceful destroy for Windows. > Underlying native implementation on Linux can take advantage of SIGTERM vs > SIGKILL and JDK support process.destroy and process.destroyForcibly, where as > on Windows this differentiation is not possible so its unlikely that we will > see JDK support for graceful destroy. > A better approach would be to invoke 'System.exit( n )' using VM.invoke. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5879) Use and enforce consistent gradle declaration behavior
[ https://issues.apache.org/jira/browse/GEODE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654211#comment-16654211 ] ASF subversion and git services commented on GEODE-5879: Commit 89105618d7877cce23ffa7456ba97aec621c1160 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~rhoughton] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8910561 ] GEODE-5879 Enforces consistent syntax in gradle dependency declaration (#2611) Always use a parentesis around the thing being depended on. Do not space pad between configuration and parenthesis before dependency Prefer single quote around the package names Co-authored-by: Robert Houghton Co-authored-by: Patrick Rhomberg > Use and enforce consistent gradle declaration behavior > -- > > Key: GEODE-5879 > URL: https://issues.apache.org/jira/browse/GEODE-5879 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Gradle syntax is permissive about dependency declaration, unless exclusions > are needed. Then the input must be in a parenthetical block before opening > the closure. Fix this everywhere, and then use a spotless rule to make it > consistent forever -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5845) Document that an enum should never be used for keys
[ https://issues.apache.org/jira/browse/GEODE-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654214#comment-16654214 ] ASF subversion and git services commented on GEODE-5845: Commit 2f5fe0a8bcbd3245531abf33e43adae2f93f0272 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f5fe0a ] GEODE-5845 Document not to use enums for keys (#2605) * GEODE-5845 Document not to use enums for keys * GEODE-5845 Revise docs (on not having enums as keys) per review > Document that an enum should never be used for keys > --- > > Key: GEODE-5845 > URL: https://issues.apache.org/jira/browse/GEODE-5845 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Maybe it should be obvious, but an enum type should never be used for an > entry key. To make this explicitly clear, add this advice to the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5845) Document that an enum should never be used for keys
[ https://issues.apache.org/jira/browse/GEODE-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654216#comment-16654216 ] ASF subversion and git services commented on GEODE-5845: Commit 2f5fe0a8bcbd3245531abf33e43adae2f93f0272 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f5fe0a ] GEODE-5845 Document not to use enums for keys (#2605) * GEODE-5845 Document not to use enums for keys * GEODE-5845 Revise docs (on not having enums as keys) per review > Document that an enum should never be used for keys > --- > > Key: GEODE-5845 > URL: https://issues.apache.org/jira/browse/GEODE-5845 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Maybe it should be obvious, but an enum type should never be used for an > entry key. To make this explicitly clear, add this advice to the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654213#comment-16654213 ] ASF subversion and git services commented on GEODE-5864: Commit b6158bf09a1e5e832d6d564a1b780096084c598b in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b6158bf ] GEODE-5864: Adds support for private/public github. Co-authored-by: Robert Houghton Co-authored-by: Jacob Barrett > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5857) Race conditions during JMX registration and cleanup
[ https://issues.apache.org/jira/browse/GEODE-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654212#comment-16654212 ] ASF subversion and git services commented on GEODE-5857: Commit 76420dcd93e17f009aa73ca8188d135158358323 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~mcmellawatt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=76420dc ] GEODE-5857: Handle JMX race conditions during registration and cleanup > Race conditions during JMX registration and cleanup > --- > > Key: GEODE-5857 > URL: https://issues.apache.org/jira/browse/GEODE-5857 > Project: Geode > Issue Type: Bug > Components: jmx, management >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Unregistering an MBean twice results in an InstanceNotFoundException, which > gets wrapped in a ManagementException and logged as a warning. This should > not be a warning as an InstanceNotFoundException implies the MBean has > already been unregistered, and a second unregistration is basically a no-op. > The same logic applies to registration of an MBean -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5845) Document that an enum should never be used for keys
[ https://issues.apache.org/jira/browse/GEODE-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654215#comment-16654215 ] ASF subversion and git services commented on GEODE-5845: Commit 2f5fe0a8bcbd3245531abf33e43adae2f93f0272 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f5fe0a ] GEODE-5845 Document not to use enums for keys (#2605) * GEODE-5845 Document not to use enums for keys * GEODE-5845 Revise docs (on not having enums as keys) per review > Document that an enum should never be used for keys > --- > > Key: GEODE-5845 > URL: https://issues.apache.org/jira/browse/GEODE-5845 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Maybe it should be obvious, but an enum type should never be used for an > entry key. To make this explicitly clear, add this advice to the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5676) ClusterConfigLocatorRestartDUnitTest hung in CI
[
https://issues.apache.org/jira/browse/GEODE-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654209#comment-16654209
]
ASF subversion and git services commented on GEODE-5676:
Commit df30df1c8e9a1216a3f9bd07b712e3c4fa99031d in geode's branch
refs/heads/feature/GEODE-5787-dunit-internal from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=df30df1 ]
GEODE-5676: Disconnect system before closing SocketCreatorFactory
The MemberStarterRule was closing SocketCreatorFactory before calling
DistributedSystem.disconnect. In the case of
ClusterConfigLocatorRestartDUnitTest there was a reconnect thread
running in the background that ended up throwing a NullPointerException
if the SocketCreatorFactory was closed. This led to an infinite loop in
the reconnect thread.
We should not be messing with the internal state of Geode until we call
disconnect to stop all of Geode's background threads.
Co-Authored-By: Dale Emery
> ClusterConfigLocatorRestartDUnitTest hung in CI
> ---
>
> Key: GEODE-5676
> URL: https://issues.apache.org/jira/browse/GEODE-5676
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.8.0
>
> Attachments: callstacks.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This test hung in a couple of runs of DistributedTest
>
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds//430
>
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds//370
> {noformat}
> Started @ 2018-08-30 04:23:46.599 +
> 2018-08-30 04:48:33.135 +
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> serverRestartsAfterLocatorReconnects
> Ended @ 2018-08-30 05:21:34.897 +
> {noformat}
> It seems to be stuck in tear down
> {noformat}
> "ReconnectThread" #416 prio=5 os_prio=0 tid=0x7fa86cad2000 nid=0xd07 in
> Object.wait() [0x7fa744ecd000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2697)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2558)
> - locked <0xe00bedc8> (a java.lang.Object)
> - locked <0xe07af498> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xe00bedd8> (a java.lang.Class for
> org.apache.geode.cache.CacheFactory)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1041)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:3987)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1552)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$1(GMSMembershipManager.java:2564)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager$$Lambda$81/1816825082.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> "RMI TCP Connection(8)-172.17.0.13" #32 daemon prio=5 os_prio=0
> tid=0x7fa874001800 nid=0x2ff waiting for monitor entry
> [0x7fa8f0d15000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1367)
> - waiting to lock <0xe07af498> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1022)
> at
> org.apache.geode.test.junit.rules.MemberStarterRule.disconnectDSIfAny(MemberStarterRule.java:182)
> at
> org.apache.geode.test.junit.rules.MemberStarterRule.after(MemberStarterRule.java:129)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.stopElementInsideVM(ClusterStartupRule.java:385)
> at
> org.apache.geode.test.junit.rules.VMProvider.lambda$stop$fe0d42dc$1(VMProvider.java:42)
> at
> org.apache.geode.test.junit.rules.VMProvider$$Lambda$77/1844235204.run(Unknown
> Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654205#comment-16654205 ] ASF subversion and git services commented on GEODE-5864: Commit dfb6ed924424897b9c30ba64ddd3530498a9bf6e in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dfb6ed9 ] Merge pull request #2638 from rhoughton-pivot/GEODE-5864 [GEODE-5864] UpdatePassingRef doesn't need docker-geode-build-image. > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654204#comment-16654204 ] ASF subversion and git services commented on GEODE-5864: Commit dfb6ed924424897b9c30ba64ddd3530498a9bf6e in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dfb6ed9 ] Merge pull request #2638 from rhoughton-pivot/GEODE-5864 [GEODE-5864] UpdatePassingRef doesn't need docker-geode-build-image. > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654206#comment-16654206 ] ASF subversion and git services commented on GEODE-5864: Commit 65e4e0fb44a8d5630461b08a4e76b2c0e9ce108e in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=65e4e0f ] [GEODE-5864] Get rid of docker-geode-build-resource. Co-authored-by: Sean Goller Co-authored-by: Robert Houghton > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5844) String.Format() argument mismatch in SystemAdmin.initHelpMap()
[ https://issues.apache.org/jira/browse/GEODE-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654210#comment-16654210 ] ASF subversion and git services commented on GEODE-5844: Commit 567569bb129d1d8acc0a709edf8b0f4e73be7c92 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~propeller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=567569b ] GEODE-5844: Make log format match args > String.Format() argument mismatch in SystemAdmin.initHelpMap() > -- > > Key: GEODE-5844 > URL: https://issues.apache.org/jira/browse/GEODE-5844 > Project: Geode > Issue Type: Bug > Components: general >Reporter: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > An argument count in String.Format() mismatch can cause a > java.util.MissingFormatArgumentException exception for some commands in > SystemAdmin.initHelpMap(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654207#comment-16654207 ] ASF subversion and git services commented on GEODE-5864: Commit c80d85baafee1d2e296130d49528d633c9b035ea in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c80d85b ] Merge pull request #2639 from rhoughton-pivot/GEODE-5864 [GEODE-5864] Get rid of docker-geode-build-resource. > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654208#comment-16654208 ] ASF subversion and git services commented on GEODE-5864: Commit c80d85baafee1d2e296130d49528d633c9b035ea in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c80d85b ] Merge pull request #2639 from rhoughton-pivot/GEODE-5864 [GEODE-5864] Get rid of docker-geode-build-resource. > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5892) File's absolute path does not change after user.dir is changed in jdk11
[
https://issues.apache.org/jira/browse/GEODE-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-5892:
---
Description:
{noformat}
File relativeFile1 = new File("abc.txt");
System.setProperty("user.dir", "/somewhereElse");
File relativeFile2 = new File("abc.txt");
System.out.println(relativeFile1.getAbsolutePath());
System.out.println(relativeFile2.getAbsolutePath());
{noformat}
pre jdk11, the code above will print out "/somewhereElse/abc.txt" in both
lines, even though the relativeFile objects still point to the files under the
old user.dir. But in jdk11, the above code will print out "old
user.dir/abc.txt" in both lines.
dynamically change user.dir would not affect the relative file's absolute path
anymore.
was:
{noformat}
File relativeFile1 = new File("abc.txt");
System.setProperty("user.dir", "/somewhereElse");
File relativeFile2 = new File("abc.txt");
System.out.println(relativeFile1.getAbsolutePath());
System.out.println(relativeFile2.getAbsolutePath());
{noformat}
pre jdk11, the code above will print out "/somewhereElse/abc.txt" in both
lines, even though the relativeFile objects still point to the files under the
old user.dir. But in jdk11, the above code will print out "old
user.dir/abc.txt" in both lines.
dynamically change user.dir never worked reliably pre jdk11, in jdk11, it's
made very clear that this won't work anymore.
> File's absolute path does not change after user.dir is changed in jdk11
> ---
>
> Key: GEODE-5892
> URL: https://issues.apache.org/jira/browse/GEODE-5892
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
>
> {noformat}
> File relativeFile1 = new File("abc.txt");
> System.setProperty("user.dir", "/somewhereElse");
> File relativeFile2 = new File("abc.txt");
> System.out.println(relativeFile1.getAbsolutePath());
> System.out.println(relativeFile2.getAbsolutePath());
> {noformat}
> pre jdk11, the code above will print out "/somewhereElse/abc.txt" in both
> lines, even though the relativeFile objects still point to the files under
> the old user.dir. But in jdk11, the above code will print out "old
> user.dir/abc.txt" in both lines.
> dynamically change user.dir would not affect the relative file's absolute
> path anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5892) File's absolute path does not change after user.dir is changed in jdk11
[
https://issues.apache.org/jira/browse/GEODE-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-5892:
---
Description:
{noformat}
File relativeFile1 = new File("abc.txt");
System.setProperty("user.dir", "/somewhereElse");
File relativeFile2 = new File("abc.txt");
System.out.println(relativeFile1.getAbsolutePath());
System.out.println(relativeFile2.getAbsolutePath());
{noformat}
pre jdk11, the code above will print out "/somewhereElse/abc.txt" in both
lines, even though the relativeFile objects still point to the files under the
old user.dir. But in jdk11, the above code will print out "old
user.dir/abc.txt" in both lines.
dynamically change user.dir never worked reliably pre jdk11, in jdk11, it's
made very clear that this won't work anymore.
was:
{noformat}
File relativeFile = new File("abc.txt");
System.setProperty("user.dir", "/somewhereElse");
System.out.println(relativeFile.getAbsolutePath());
{noformat}
pre jdk11, the code above will print out "/somewhereElse/abc.txt" even though
the relativeFile object still point to the file under the old user.dir. But in
jdk11, the above code will print out "old user.dir/abc.txt".
dynamically change user.dir never worked reliably pre jdk11, in jdk11, it's
made very clear that this won't work anymore.
> File's absolute path does not change after user.dir is changed in jdk11
> ---
>
> Key: GEODE-5892
> URL: https://issues.apache.org/jira/browse/GEODE-5892
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
>
> {noformat}
> File relativeFile1 = new File("abc.txt");
> System.setProperty("user.dir", "/somewhereElse");
> File relativeFile2 = new File("abc.txt");
> System.out.println(relativeFile1.getAbsolutePath());
> System.out.println(relativeFile2.getAbsolutePath());
> {noformat}
> pre jdk11, the code above will print out "/somewhereElse/abc.txt" in both
> lines, even though the relativeFile objects still point to the files under
> the old user.dir. But in jdk11, the above code will print out "old
> user.dir/abc.txt" in both lines.
> dynamically change user.dir never worked reliably pre jdk11, in jdk11, it's
> made very clear that this won't work anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5845) Document that an enum should never be used for keys
[ https://issues.apache.org/jira/browse/GEODE-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-5845. Resolution: Fixed Fix Version/s: 1.8.0 > Document that an enum should never be used for keys > --- > > Key: GEODE-5845 > URL: https://issues.apache.org/jira/browse/GEODE-5845 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Maybe it should be obvious, but an enum type should never be used for an > entry key. To make this explicitly clear, add this advice to the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5892) File's absolute path does not change after user.dir is changed in jdk11
[
https://issues.apache.org/jira/browse/GEODE-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-5892:
---
Summary: File's absolute path does not change after user.dir is changed in
jdk11 (was: jdk11 does not allow dynamically change user.dir anymore)
> File's absolute path does not change after user.dir is changed in jdk11
> ---
>
> Key: GEODE-5892
> URL: https://issues.apache.org/jira/browse/GEODE-5892
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
>
> {noformat}
> File relativeFile = new File("abc.txt");
> System.setProperty("user.dir", "/somewhereElse");
> System.out.println(relativeFile.getAbsolutePath());
> {noformat}
> pre jdk11, the code above will print out "/somewhereElse/abc.txt" even though
> the relativeFile object still point to the file under the old user.dir. But
> in jdk11, the above code will print out "old user.dir/abc.txt".
> dynamically change user.dir never worked reliably pre jdk11, in jdk11, it's
> made very clear that this won't work anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5845) Document that an enum should never be used for keys
[ https://issues.apache.org/jira/browse/GEODE-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654110#comment-16654110 ] ASF subversion and git services commented on GEODE-5845: Commit 2f5fe0a8bcbd3245531abf33e43adae2f93f0272 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f5fe0a ] GEODE-5845 Document not to use enums for keys (#2605) * GEODE-5845 Document not to use enums for keys * GEODE-5845 Revise docs (on not having enums as keys) per review > Document that an enum should never be used for keys > --- > > Key: GEODE-5845 > URL: https://issues.apache.org/jira/browse/GEODE-5845 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Maybe it should be obvious, but an enum type should never be used for an > entry key. To make this explicitly clear, add this advice to the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5845) Document that an enum should never be used for keys
[ https://issues.apache.org/jira/browse/GEODE-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654111#comment-16654111 ] ASF subversion and git services commented on GEODE-5845: Commit 2f5fe0a8bcbd3245531abf33e43adae2f93f0272 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f5fe0a ] GEODE-5845 Document not to use enums for keys (#2605) * GEODE-5845 Document not to use enums for keys * GEODE-5845 Revise docs (on not having enums as keys) per review > Document that an enum should never be used for keys > --- > > Key: GEODE-5845 > URL: https://issues.apache.org/jira/browse/GEODE-5845 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Maybe it should be obvious, but an enum type should never be used for an > entry key. To make this explicitly clear, add this advice to the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5845) Document that an enum should never be used for keys
[ https://issues.apache.org/jira/browse/GEODE-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654109#comment-16654109 ] ASF subversion and git services commented on GEODE-5845: Commit 2f5fe0a8bcbd3245531abf33e43adae2f93f0272 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f5fe0a ] GEODE-5845 Document not to use enums for keys (#2605) * GEODE-5845 Document not to use enums for keys * GEODE-5845 Revise docs (on not having enums as keys) per review > Document that an enum should never be used for keys > --- > > Key: GEODE-5845 > URL: https://issues.apache.org/jira/browse/GEODE-5845 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Maybe it should be obvious, but an enum type should never be used for an > entry key. To make this explicitly clear, add this advice to the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5892) jdk11 does not allow dynamically change user.dir anymore
[
https://issues.apache.org/jira/browse/GEODE-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-5892:
--
Assignee: Jinmei Liao
> jdk11 does not allow dynamically change user.dir anymore
>
>
> Key: GEODE-5892
> URL: https://issues.apache.org/jira/browse/GEODE-5892
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
>
> {noformat}
> File relativeFile = new File("abc.txt");
> System.setProperty("user.dir", "/somewhereElse");
> System.out.println(relativeFile.getAbsolutePath());
> {noformat}
> pre jdk11, the code above will print out "/somewhereElse/abc.txt" even though
> the relativeFile object still point to the file under the old user.dir. But
> in jdk11, the above code will print out "old user.dir/abc.txt".
> dynamically change user.dir never worked reliably pre jdk11, in jdk11, it's
> made very clear that this won't work anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5892) jdk11 does not allow dynamically change user.dir anymore
Jinmei Liao created GEODE-5892:
--
Summary: jdk11 does not allow dynamically change user.dir anymore
Key: GEODE-5892
URL: https://issues.apache.org/jira/browse/GEODE-5892
Project: Geode
Issue Type: Sub-task
Reporter: Jinmei Liao
{noformat}
File relativeFile = new File("abc.txt");
System.setProperty("user.dir", "/somewhereElse");
System.out.println(relativeFile.getAbsolutePath());
{noformat}
pre jdk11, the code above will print out "/somewhereElse/abc.txt" even though
the relativeFile object still point to the file under the old user.dir. But in
jdk11, the above code will print out "old user.dir/abc.txt".
dynamically change user.dir never worked reliably pre jdk11, in jdk11, it's
made very clear that this won't work anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654076#comment-16654076 ] ASF subversion and git services commented on GEODE-5864: Commit b6158bf09a1e5e832d6d564a1b780096084c598b in geode's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b6158bf ] GEODE-5864: Adds support for private/public github. Co-authored-by: Robert Houghton Co-authored-by: Jacob Barrett > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5888) A removeAll/putAll operation could remove lockObject held by another thread if region is closing
[ https://issues.apache.org/jira/browse/GEODE-5888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5888: -- Labels: pull-request-available (was: ) > A removeAll/putAll operation could remove lockObject held by another thread > if region is closing > > > Key: GEODE-5888 > URL: https://issues.apache.org/jira/browse/GEODE-5888 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > A bulk operation needs to hold lockObjects in BucketRegion.waitUntilLocked. > However, it may hit RegionDestroyedException instead, and it will release > lockObjects it does not hold. > org.apache.geode.cache.RegionDestroyedException: Partitioned Region @21554698 > [path='/partitionedRegion'; dataPolicy=PERSISTENT_PARTITION; prId=1; > isDestroyed=true; isClosed=true; retryTimeout=360; serialNumber=7; > partition > attributes=PartitionAttributes@2144398013[redundantCopies=0;localMaxMemory=205;totalMaxMemory=2147483647;totalNumBuckets=113;partitionResolver=null;colocatedWith=null;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null]; > on VM > rs-GEM-1352-1526a0i3large-hydra-client-34(dataStoregemfire4_host1_19090:19090):1028] > at > org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7396) > at > org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2745) > at > org.apache.geode.internal.cache.BucketRegion.waitUntilLocked(BucketRegion.java:493) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.doLocalRemoveAll(RemoveAllPRMessage.java:437) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.operateOnPartitionedRegion(RemoveAllPRMessage.java:317) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:325) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367) > at > org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:424) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2873) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:2553) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.access$1300(ClusterDistributionManager.java:109) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.messageReceived(ClusterDistributionManager.java:3411) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.dispatchMessage(GMSMembershipManager.java:1102) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.handleOrDeferMessage(GMSMembershipManager.java:1022) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager$MyDCReceiver.messageReceived(GMSMembershipManager.java:399) > at > org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:722) > at > org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:824) > at > org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3898) > at > org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3508) > at > org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1814) > at org.apache.geode.internal.tcp.Connection.run(Connection.java:1676) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Once the exception is hit, it will remove the lockObjects hold by another > thread performing another operation. > at > org.apache.geode.internal.cache.BucketRegion.removeAndNotifyKeys(BucketRegion.java:454) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.doLocalRemoveAll(RemoveAllPRMessage.java:534) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.operateOnPartitionedRegion(RemoveAllPRMessage.java:317) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:325) > at >
[jira] [Commented] (GEODE-5888) A removeAll/putAll operation could remove lockObject held by another thread if region is closing
[ https://issues.apache.org/jira/browse/GEODE-5888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654051#comment-16654051 ] ASF subversion and git services commented on GEODE-5888: Commit 76be4c1c067ae74cc58b951135da26f808350e12 in geode's branch refs/heads/feature/GEODE-5888 from eshu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=76be4c1 ] GEODE-5888: Do not let operation proceed if partitoned region is closing. * A bulk opertion could remove lockObject due to RegionDestroyedException. * Do not allow a new operation to proceed without checking region readiness. > A removeAll/putAll operation could remove lockObject held by another thread > if region is closing > > > Key: GEODE-5888 > URL: https://issues.apache.org/jira/browse/GEODE-5888 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > A bulk operation needs to hold lockObjects in BucketRegion.waitUntilLocked. > However, it may hit RegionDestroyedException instead, and it will release > lockObjects it does not hold. > org.apache.geode.cache.RegionDestroyedException: Partitioned Region @21554698 > [path='/partitionedRegion'; dataPolicy=PERSISTENT_PARTITION; prId=1; > isDestroyed=true; isClosed=true; retryTimeout=360; serialNumber=7; > partition > attributes=PartitionAttributes@2144398013[redundantCopies=0;localMaxMemory=205;totalMaxMemory=2147483647;totalNumBuckets=113;partitionResolver=null;colocatedWith=null;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null]; > on VM > rs-GEM-1352-1526a0i3large-hydra-client-34(dataStoregemfire4_host1_19090:19090):1028] > at > org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7396) > at > org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2745) > at > org.apache.geode.internal.cache.BucketRegion.waitUntilLocked(BucketRegion.java:493) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.doLocalRemoveAll(RemoveAllPRMessage.java:437) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.operateOnPartitionedRegion(RemoveAllPRMessage.java:317) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:325) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367) > at > org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:424) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2873) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:2553) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.access$1300(ClusterDistributionManager.java:109) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.messageReceived(ClusterDistributionManager.java:3411) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.dispatchMessage(GMSMembershipManager.java:1102) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.handleOrDeferMessage(GMSMembershipManager.java:1022) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager$MyDCReceiver.messageReceived(GMSMembershipManager.java:399) > at > org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:722) > at > org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:824) > at > org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3898) > at > org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3508) > at > org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1814) > at org.apache.geode.internal.tcp.Connection.run(Connection.java:1676) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Once the exception is hit, it will remove the lockObjects hold by another > thread performing another operation. > at > org.apache.geode.internal.cache.BucketRegion.removeAndNotifyKeys(BucketRegion.java:454) > at >
[jira] [Updated] (GEODE-5891) CreateRegionCommandIntegrationTest failed with jdk11
[ https://issues.apache.org/jira/browse/GEODE-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5891: -- Labels: pull-request-available (was: ) > CreateRegionCommandIntegrationTest failed with jdk11 > > > Key: GEODE-5891 > URL: https://issues.apache.org/jira/browse/GEODE-5891 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > > org.apache.geode.management.internal.cli.commands.CreateRegionCommandIntegrationTest > > invalidCompressor FAILED > java.lang.AssertionError: > Expecting: > <"Member | Status > -- | > --- > server | ERROR: class java.lang.String cannot be cast to class > org.apache.geode.compression.Compressor (java.lang.String is in module > java.base of loader 'bootstrap'; org.apache.geode.compression.Compressor is > in unnamed module of loader 'app') > "> > to contain: > <"java.lang.String cannot be cast to > org.apache.geode.compression.Compressor"> > at > org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:85) > at > org.apache.geode.management.internal.cli.commands.CreateRegionCommandIntegrationTest.invalidCompressor(CreateRegionCommandIntegrationTest.java:252) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5891) CreateRegionCommandIntegrationTest failed with jdk11
[ https://issues.apache.org/jira/browse/GEODE-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-5891: -- Assignee: Jinmei Liao > CreateRegionCommandIntegrationTest failed with jdk11 > > > Key: GEODE-5891 > URL: https://issues.apache.org/jira/browse/GEODE-5891 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > > org.apache.geode.management.internal.cli.commands.CreateRegionCommandIntegrationTest > > invalidCompressor FAILED > java.lang.AssertionError: > Expecting: > <"Member | Status > -- | > --- > server | ERROR: class java.lang.String cannot be cast to class > org.apache.geode.compression.Compressor (java.lang.String is in module > java.base of loader 'bootstrap'; org.apache.geode.compression.Compressor is > in unnamed module of loader 'app') > "> > to contain: > <"java.lang.String cannot be cast to > org.apache.geode.compression.Compressor"> > at > org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:85) > at > org.apache.geode.management.internal.cli.commands.CreateRegionCommandIntegrationTest.invalidCompressor(CreateRegionCommandIntegrationTest.java:252) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5891) CreateRegionCommandIntegrationTest failed with jdk11
Jinmei Liao created GEODE-5891: -- Summary: CreateRegionCommandIntegrationTest failed with jdk11 Key: GEODE-5891 URL: https://issues.apache.org/jira/browse/GEODE-5891 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao org.apache.geode.management.internal.cli.commands.CreateRegionCommandIntegrationTest > invalidCompressor FAILED java.lang.AssertionError: Expecting: <"Member | Status -- | --- server | ERROR: class java.lang.String cannot be cast to class org.apache.geode.compression.Compressor (java.lang.String is in module java.base of loader 'bootstrap'; org.apache.geode.compression.Compressor is in unnamed module of loader 'app') "> to contain: <"java.lang.String cannot be cast to org.apache.geode.compression.Compressor"> at org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:85) at org.apache.geode.management.internal.cli.commands.CreateRegionCommandIntegrationTest.invalidCompressor(CreateRegionCommandIntegrationTest.java:252) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5819) Handshake fails on Java11
[
https://issues.apache.org/jira/browse/GEODE-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653992#comment-16653992
]
Jinmei Liao edited comment on GEODE-5819 at 10/17/18 6:20 PM:
--
More SSL failures when we use jdk11 in integration tests:
{quote}
org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest
> testConnectionCountIsProperlyDecremented[use ssl true] FAILED
javax.net.ssl.SSLProtocolException: Connection reset
at sun.security.ssl.Alert.createSSLException(Alert.java:126)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:137)
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
at
org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1076)
at
org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:934)
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.protobuf.UnsafeUtil
(file:/home/geode/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protobuf-java/3.6.0/5333f7e422744d76840c08a106e28e519fbe3acd/protobuf-java-3.6.0.jar)
to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
com.google.protobuf.UnsafeUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.protobuf.UnsafeUtil
(file:/home/geode/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protobuf-java/3.6.0/5333f7e422744d76840c08a106e28e519fbe3acd/protobuf-java-3.6.0.jar)
to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
com.google.protobuf.UnsafeUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
at
org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:896)
at
org.apache.geode.internal.net.SocketCreator.connectForClient(SocketCreator.java:852)
at
org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest.getSSLSocket(CacheConnectionJUnitTest.java:258)
at
org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest.setup(CacheConnectionJUnitTest.java:138)
Caused by:
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:186)
at java.net.SocketInputStream.read(SocketInputStream.java:140)
at
sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448)
at
sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
... 9 more
java.lang.NullPointerException
at
org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest.cleanup(CacheConnectionJUnitTest.java:153)
org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest
> testBasicMessagesAndStats[use ssl true] FAILED
javax.net.ssl.SSLProtocolException: Connection reset
at sun.security.ssl.Alert.createSSLException(Alert.java:126)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:137)
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
at
org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1076)
at
org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:934)
at
org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:896)
at
org.apache.geode.internal.net.SocketCreator.connectForClient(SocketCreator.java:852)
at
[jira] [Commented] (GEODE-5819) Handshake fails on Java11
[
https://issues.apache.org/jira/browse/GEODE-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653992#comment-16653992
]
Jinmei Liao commented on GEODE-5819:
More SSL failures when we use jdk11 in integration tests:
{{org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest
> testConnectionCountIsProperlyDecremented[use ssl true] FAILED
javax.net.ssl.SSLProtocolException: Connection reset
at sun.security.ssl.Alert.createSSLException(Alert.java:126)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:137)
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
at
org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1076)
at
org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:934)
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.protobuf.UnsafeUtil
(file:/home/geode/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protobuf-java/3.6.0/5333f7e422744d76840c08a106e28e519fbe3acd/protobuf-java-3.6.0.jar)
to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
com.google.protobuf.UnsafeUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.protobuf.UnsafeUtil
(file:/home/geode/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protobuf-java/3.6.0/5333f7e422744d76840c08a106e28e519fbe3acd/protobuf-java-3.6.0.jar)
to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
com.google.protobuf.UnsafeUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
at
org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:896)
at
org.apache.geode.internal.net.SocketCreator.connectForClient(SocketCreator.java:852)
at
org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest.getSSLSocket(CacheConnectionJUnitTest.java:258)
at
org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest.setup(CacheConnectionJUnitTest.java:138)
Caused by:
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:186)
at java.net.SocketInputStream.read(SocketInputStream.java:140)
at
sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448)
at
sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
... 9 more
java.lang.NullPointerException
at
org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest.cleanup(CacheConnectionJUnitTest.java:153)
org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest
> testBasicMessagesAndStats[use ssl true] FAILED
javax.net.ssl.SSLProtocolException: Connection reset
at sun.security.ssl.Alert.createSSLException(Alert.java:126)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:137)
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
at
org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1076)
at
org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:934)
at
org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:896)
at
org.apache.geode.internal.net.SocketCreator.connectForClient(SocketCreator.java:852)
at
org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheConnectionJUnitTest.getSSLSocket(CacheConnectionJUnitTest.java:258)
at
[jira] [Updated] (GEODE-5819) Handshake fails on Java11
[
https://issues.apache.org/jira/browse/GEODE-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-5819:
---
Summary: Handshake fails on Java11 (was: Handshake fails on Java10 )
> Handshake fails on Java11
> -
>
> Key: GEODE-5819
> URL: https://issues.apache.org/jira/browse/GEODE-5819
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Patrick Rhomberg
>Priority: Major
>
> *
> [RestAPIsWithSSLDUnitTest|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html].
>
> [testSSLWithMultipleCipherSuite|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html#testSSLWithMultipleCipherSuite]
> *
> [RestAPIsWithSSLDUnitTest|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html].
>
> [testSSLWithMultipleCipherSuiteLegacy|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html#testSSLWithMultipleCipherSuiteLegacy]
> {noformat}
> java.lang.RuntimeException: unexpected exception
> at
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.validateConnection(RestAPIsWithSSLDUnitTest.java:512)
> at
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithMultipleCipherSuite(RestAPIsWithSSLDUnitTest.java:701)
> 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:564)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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:564)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
>
[jira] [Commented] (GEODE-5890) gateway events from the same distributed system did not check misorder
[
https://issues.apache.org/jira/browse/GEODE-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653976#comment-16653976
]
xiaojian zhou commented on GEODE-5890:
--
{noformat}
This is a special scenario of 45799. What happened are:
There're 2 operations for Object_10 both initiated from site 2. But they
arrived at site 1(created the snapshot) and site 3 misordered.
i.e. site 1 got destroy then put, while site 3 got put then destroy.
Operation-1:
destroy from vm_14_edge_2_1_host1_11641: 16:57:30.849 - 16:57:44.203 tid=0xb83
The gateway event was created at site 2, with version tag:
v20; rv20; time=1537315051153 (by bridge_11435)
Operation-2:
putAll from vm_15_edge_2_2_host1_11664: 16:57:32.238 - 16:57:43.890 tid=0xb83
The gateway event was created at site 2, with version tag:
v22; rv2; time=1537315063885 (by bridg_11450)
There's no CME at server, so it has nothing to do with GEODE-3967.
Note: operation-1's gatway events has smaller timestamp than operation-2.
When they arrived at site 3 misordered (this is possible use case), the late
arriving operation-1's gateway event should be ignored by throwing a CME in
processGatewayTag(). But it did not.
The root cause is, when they are from the same site, the method just return
true without checking the timestamp. {noformat}
> gateway events from the same distributed system did not check misorder
> --
>
> Key: GEODE-5890
> URL: https://issues.apache.org/jira/browse/GEODE-5890
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>
> {noformat}
> Host name: rs-GEM-2228-1638a2i3xlarge-hydra-client-28
> OS name: Linux
> Architecture: amd64
> OS version: 3.10.0-862.11.6.el7.x86_64
> Java version: 1.8.0_181
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /usr/local/regr/jdk/jdk1.8.0_181/jre
> #
> Product
> Product-Name: Pivotal GemFire
> Product-Version: 9.6.0
> Native version: native code unavailable
> Build
> Build-Date: 2018-09-18 00:33:49 +
> Build-Id: root 9
> Build-Java-Version: 1.8.0_171
> Build-Platform: Linux 4.4.0-89-generic amd64
> Open
> Source-Date: 2018-09-18 00:29:00 +
> Source-Repository: support/9.6
> Source-Revision: b404fab8c4fe962dc8adab827034efdbc93ab861
> Closed
> GemFire-Source-Date: 2018-09-10 23:15:03 +
> GemFire-Source-Repository: support/9.6
> GemFire-Source-Revision: f5a2b5ec6e6144a0635c41d1605b4586dd8acc6a
> Running on: /10.32.111.152, 4 cpu(s), amd64 Linux
> 3.10.0-862.11.6.el7.x86_64
> #
> Test was run from versioning/newWan/wanVersioning.bt
> Test:
> versioning/newWan/parRegSerialSenderKeysPerWanHct.conf
> bridgeHostsPerSite=3
> bridgeThreadsPerVM=2
> bridgeVMsPerHost=1
> clientMem=256m
> edgeHostsPerSite=2
> edgeThreadsPerVM=5
> edgeVMsPerHost=1
> enableFailover=true
> locatorHostsPerSite=1
> locatorThreadsPerVM=2
> locatorVMsPerHost=1
> maxOps=2
> redundantCopies=1
> resultWaitSec=1200
> serverMem=256m
> wanSites=4
> Run with local.conf:
> hydra.Prms-randomSeed=1537256262399;
> hydra.Prms-randomSeed=1537256262399;
> hydra.GemFirePrms-logLevel = fine;
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1537256262399;
> *** Test failed with this error:
> CLIENT vm_17_thr_50_edge_3_2_host1_11693
> TASK[0] versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA
> ERROR util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> at
> newWan.WANOperationsClient.verifyRegionContents(WANOperationsClient.java:1089)
> at
> versioning.newWan.WanConflictResolverTest.validateEntryOperationFromBBSnapshot(WanConflictResolverTest.java:364)
> at
> versioning.newWan.WanConflictResolverTest.doOpsAndValidateHA(WanConflictResolverTest.java:319)
> at
> versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA(WanConflictResolverTest.java:111)
> at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.execute(MethExecutor.java:181)
> at
[jira] [Created] (GEODE-5890) gateway events from the same distributed system did not check misorder
xiaojian zhou created GEODE-5890:
Summary: gateway events from the same distributed system did not
check misorder
Key: GEODE-5890
URL: https://issues.apache.org/jira/browse/GEODE-5890
Project: Geode
Issue Type: Bug
Components: wan
Reporter: xiaojian zhou
{noformat}
Host name: rs-GEM-2228-1638a2i3xlarge-hydra-client-28
OS name: Linux
Architecture: amd64
OS version: 3.10.0-862.11.6.el7.x86_64
Java version: 1.8.0_181
Java vm name: Java HotSpot(TM) 64-Bit Server VM
Java vendor: Oracle Corporation
Java home: /usr/local/regr/jdk/jdk1.8.0_181/jre
#
Product
Product-Name: Pivotal GemFire
Product-Version: 9.6.0
Native version: native code unavailable
Build
Build-Date: 2018-09-18 00:33:49 +
Build-Id: root 9
Build-Java-Version: 1.8.0_171
Build-Platform: Linux 4.4.0-89-generic amd64
Open
Source-Date: 2018-09-18 00:29:00 +
Source-Repository: support/9.6
Source-Revision: b404fab8c4fe962dc8adab827034efdbc93ab861
Closed
GemFire-Source-Date: 2018-09-10 23:15:03 +
GemFire-Source-Repository: support/9.6
GemFire-Source-Revision: f5a2b5ec6e6144a0635c41d1605b4586dd8acc6a
Running on: /10.32.111.152, 4 cpu(s), amd64 Linux 3.10.0-862.11.6.el7.x86_64
#
Test was run from versioning/newWan/wanVersioning.bt
Test:
versioning/newWan/parRegSerialSenderKeysPerWanHct.conf
bridgeHostsPerSite=3
bridgeThreadsPerVM=2
bridgeVMsPerHost=1
clientMem=256m
edgeHostsPerSite=2
edgeThreadsPerVM=5
edgeVMsPerHost=1
enableFailover=true
locatorHostsPerSite=1
locatorThreadsPerVM=2
locatorVMsPerHost=1
maxOps=2
redundantCopies=1
resultWaitSec=1200
serverMem=256m
wanSites=4
Run with local.conf:
hydra.Prms-randomSeed=1537256262399;
hydra.Prms-randomSeed=1537256262399;
hydra.GemFirePrms-logLevel = fine;
//randomSeed extracted from test:
hydra.Prms-randomSeed=1537256262399;
*** Test failed with this error:
CLIENT vm_17_thr_50_edge_3_2_host1_11693
TASK[0] versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA
ERROR util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
/DefaultRegion to be size 24, but it is size 23
The following 1 keys were missing from /DefaultRegion: [Object_10]
util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
/DefaultRegion to be size 24, but it is size 23
The following 1 keys were missing from /DefaultRegion: [Object_10]
at
newWan.WANOperationsClient.verifyRegionContents(WANOperationsClient.java:1089)
at
versioning.newWan.WanConflictResolverTest.validateEntryOperationFromBBSnapshot(WanConflictResolverTest.java:364)
at
versioning.newWan.WanConflictResolverTest.doOpsAndValidateHA(WanConflictResolverTest.java:319)
at
versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA(WanConflictResolverTest.java:111)
at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hydra.MethExecutor.execute(MethExecutor.java:181)
at hydra.MethExecutor.execute(MethExecutor.java:149)
at hydra.TestTask.execute(TestTask.java:197)
at hydra.RemoteTestModule$1.run(RemoteTestModule.java:213)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5890) gateway events from the same distributed system did not check misorder
[
https://issues.apache.org/jira/browse/GEODE-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiaojian zhou reassigned GEODE-5890:
Assignee: xiaojian zhou
> gateway events from the same distributed system did not check misorder
> --
>
> Key: GEODE-5890
> URL: https://issues.apache.org/jira/browse/GEODE-5890
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>
> {noformat}
> Host name: rs-GEM-2228-1638a2i3xlarge-hydra-client-28
> OS name: Linux
> Architecture: amd64
> OS version: 3.10.0-862.11.6.el7.x86_64
> Java version: 1.8.0_181
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /usr/local/regr/jdk/jdk1.8.0_181/jre
> #
> Product
> Product-Name: Pivotal GemFire
> Product-Version: 9.6.0
> Native version: native code unavailable
> Build
> Build-Date: 2018-09-18 00:33:49 +
> Build-Id: root 9
> Build-Java-Version: 1.8.0_171
> Build-Platform: Linux 4.4.0-89-generic amd64
> Open
> Source-Date: 2018-09-18 00:29:00 +
> Source-Repository: support/9.6
> Source-Revision: b404fab8c4fe962dc8adab827034efdbc93ab861
> Closed
> GemFire-Source-Date: 2018-09-10 23:15:03 +
> GemFire-Source-Repository: support/9.6
> GemFire-Source-Revision: f5a2b5ec6e6144a0635c41d1605b4586dd8acc6a
> Running on: /10.32.111.152, 4 cpu(s), amd64 Linux
> 3.10.0-862.11.6.el7.x86_64
> #
> Test was run from versioning/newWan/wanVersioning.bt
> Test:
> versioning/newWan/parRegSerialSenderKeysPerWanHct.conf
> bridgeHostsPerSite=3
> bridgeThreadsPerVM=2
> bridgeVMsPerHost=1
> clientMem=256m
> edgeHostsPerSite=2
> edgeThreadsPerVM=5
> edgeVMsPerHost=1
> enableFailover=true
> locatorHostsPerSite=1
> locatorThreadsPerVM=2
> locatorVMsPerHost=1
> maxOps=2
> redundantCopies=1
> resultWaitSec=1200
> serverMem=256m
> wanSites=4
> Run with local.conf:
> hydra.Prms-randomSeed=1537256262399;
> hydra.Prms-randomSeed=1537256262399;
> hydra.GemFirePrms-logLevel = fine;
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1537256262399;
> *** Test failed with this error:
> CLIENT vm_17_thr_50_edge_3_2_host1_11693
> TASK[0] versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA
> ERROR util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> at
> newWan.WANOperationsClient.verifyRegionContents(WANOperationsClient.java:1089)
> at
> versioning.newWan.WanConflictResolverTest.validateEntryOperationFromBBSnapshot(WanConflictResolverTest.java:364)
> at
> versioning.newWan.WanConflictResolverTest.doOpsAndValidateHA(WanConflictResolverTest.java:319)
> at
> versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA(WanConflictResolverTest.java:111)
> at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.execute(MethExecutor.java:181)
> at hydra.MethExecutor.execute(MethExecutor.java:149)
> at hydra.TestTask.execute(TestTask.java:197)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:213)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5862) configureEvictionByObjectSizer fails in AcceptanceTestOpenJDK11
[ https://issues.apache.org/jira/browse/GEODE-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653943#comment-16653943 ] Owen Nichols commented on GEODE-5862: - fixed by actually running test on Java 11 as intended: https://github.com/apache/geode/pull/2643 > configureEvictionByObjectSizer fails in AcceptanceTestOpenJDK11 > --- > > Key: GEODE-5862 > URL: https://issues.apache.org/jira/browse/GEODE-5862 > Project: Geode > Issue Type: Sub-task >Reporter: Owen Nichols >Priority: Major > > Example of this failure: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTestOpenJDK11/builds/10] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5878) AcceptanceTest gfsh commands do not respect test JVM version
[
https://issues.apache.org/jira/browse/GEODE-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653944#comment-16653944
]
Owen Nichols commented on GEODE-5878:
-
fixed by actually running test on Java 11 as intended:
https://github.com/apache/geode/pull/2643
> AcceptanceTest gfsh commands do not respect test JVM version
>
>
> Key: GEODE-5878
> URL: https://issues.apache.org/jira/browse/GEODE-5878
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Java11 tests fail due to the gfsh commands (as executed via {{GfshRule}})
> being launched running Java8 rather than the intended test JVM Java11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5860) Extract String code from ConfigureEvictionThroughGfsh
[ https://issues.apache.org/jira/browse/GEODE-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653942#comment-16653942 ] Owen Nichols commented on GEODE-5860: - fixed by actually running test on Java 11 as intended: https://github.com/apache/geode/pull/2643 > Extract String code from ConfigureEvictionThroughGfsh > - > > Key: GEODE-5860 > URL: https://issues.apache.org/jira/browse/GEODE-5860 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5850) Java11 testing in PutCommandWithJsonTest fails due to String declaration of classes.
[
https://issues.apache.org/jira/browse/GEODE-5850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653941#comment-16653941
]
Owen Nichols commented on GEODE-5850:
-
fixed by actually running test on Java 11 as intended:
https://github.com/apache/geode/pull/2643
> Java11 testing in PutCommandWithJsonTest fails due to String declaration of
> classes.
>
>
> Key: GEODE-5850
> URL: https://issues.apache.org/jira/browse/GEODE-5850
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h
> Remaining Estimate: 0h
>
> In iterative testing, we saw the error
> {noformat}
> Error while processing command --value=('name':'Jinmei') --value-class=Customer> Reason :
> java.lang.UnsupportedClassVersionError: Customer has been compiled by a more
> recent version of the Java Runtime (class file version 55.0), this version of
> the Java Runtime only recognizes class file versions up to 52.0
> {noformat}
> This is due to the following:
> * We build in Java8
> * We test in Java11
> * This particular AcceptanceTest declares a class to build into a jar, which
> implicitly gets compiled in the test JVM (Java11)
> * This causes an UnsupportedClassVersionError, since the started locator and
> server are running Java8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5846) Add pipeline jobs for testing on Java 11
[ https://issues.apache.org/jira/browse/GEODE-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653940#comment-16653940 ] Owen Nichols commented on GEODE-5846: - fixed to make it actually run tests on Java 11 as intended: https://github.com/apache/geode/pull/2643 > Add pipeline jobs for testing on Java 11 > > > Key: GEODE-5846 > URL: https://issues.apache.org/jira/browse/GEODE-5846 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Duplicate test jobs to cover permutations of compile JVM and test JVM. At > minimum, need to test OpenJdk8-compiled geode on both OpenJdk8 and OpenJdk11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5846) Add pipeline jobs for testing on Java 11
[ https://issues.apache.org/jira/browse/GEODE-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5846: -- Labels: pull-request-available (was: ) > Add pipeline jobs for testing on Java 11 > > > Key: GEODE-5846 > URL: https://issues.apache.org/jira/browse/GEODE-5846 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > > Duplicate test jobs to cover permutations of compile JVM and test JVM. At > minimum, need to test OpenJdk8-compiled geode on both OpenJdk8 and OpenJdk11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5857) Race conditions during JMX registration and cleanup
[ https://issues.apache.org/jira/browse/GEODE-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-5857. - Resolution: Fixed > Race conditions during JMX registration and cleanup > --- > > Key: GEODE-5857 > URL: https://issues.apache.org/jira/browse/GEODE-5857 > Project: Geode > Issue Type: Bug > Components: jmx, management >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Unregistering an MBean twice results in an InstanceNotFoundException, which > gets wrapped in a ManagementException and logged as a warning. This should > not be a warning as an InstanceNotFoundException implies the MBean has > already been unregistered, and a second unregistration is basically a no-op. > The same logic applies to registration of an MBean -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5857) Race conditions during JMX registration and cleanup
[ https://issues.apache.org/jira/browse/GEODE-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653897#comment-16653897 ] ASF subversion and git services commented on GEODE-5857: Commit 76420dcd93e17f009aa73ca8188d135158358323 in geode's branch refs/heads/develop from [~mcmellawatt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=76420dc ] GEODE-5857: Handle JMX race conditions during registration and cleanup > Race conditions during JMX registration and cleanup > --- > > Key: GEODE-5857 > URL: https://issues.apache.org/jira/browse/GEODE-5857 > Project: Geode > Issue Type: Bug > Components: jmx, management >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Unregistering an MBean twice results in an InstanceNotFoundException, which > gets wrapped in a ManagementException and logged as a warning. This should > not be a warning as an InstanceNotFoundException implies the MBean has > already been unregistered, and a second unregistration is basically a no-op. > The same logic applies to registration of an MBean -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5889) deploy_meta improvements
[ https://issues.apache.org/jira/browse/GEODE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5889: -- Labels: pull-request-available (was: ) > deploy_meta improvements > > > Key: GEODE-5889 > URL: https://issues.apache.org/jira/browse/GEODE-5889 > Project: Geode > Issue Type: Bug >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > deploy_meta should: > * require a fork name. don't default to apache if not specified! > * explain how to install gcloud, if it isn't already installed > * work around concourse hiccups like reg/orange/brown jobs by retriggering > them once > * ensure window image is ready before starting windows jobs for the first > time > * display the correct URL when the pipeline is up -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5889) deploy_meta improvements
Owen Nichols created GEODE-5889: --- Summary: deploy_meta improvements Key: GEODE-5889 URL: https://issues.apache.org/jira/browse/GEODE-5889 Project: Geode Issue Type: Bug Reporter: Owen Nichols deploy_meta should: * require a fork name. don't default to apache if not specified! * explain how to install gcloud, if it isn't already installed * work around concourse hiccups like reg/orange/brown jobs by retriggering them once * ensure window image is ready before starting windows jobs for the first time * display the correct URL when the pipeline is up -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5888) A removeAll/putAll operation could remove lockObject held by another thread if region is closing
[ https://issues.apache.org/jira/browse/GEODE-5888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-5888: --- Assignee: Eric Shu > A removeAll/putAll operation could remove lockObject held by another thread > if region is closing > > > Key: GEODE-5888 > URL: https://issues.apache.org/jira/browse/GEODE-5888 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > A bulk operation needs to hold lockObjects in BucketRegion.waitUntilLocked. > However, it may hit RegionDestroyedException instead, and it will release > lockObjects it does not hold. > org.apache.geode.cache.RegionDestroyedException: Partitioned Region @21554698 > [path='/partitionedRegion'; dataPolicy=PERSISTENT_PARTITION; prId=1; > isDestroyed=true; isClosed=true; retryTimeout=360; serialNumber=7; > partition > attributes=PartitionAttributes@2144398013[redundantCopies=0;localMaxMemory=205;totalMaxMemory=2147483647;totalNumBuckets=113;partitionResolver=null;colocatedWith=null;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null]; > on VM > rs-GEM-1352-1526a0i3large-hydra-client-34(dataStoregemfire4_host1_19090:19090):1028] > at > org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7396) > at > org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2745) > at > org.apache.geode.internal.cache.BucketRegion.waitUntilLocked(BucketRegion.java:493) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.doLocalRemoveAll(RemoveAllPRMessage.java:437) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.operateOnPartitionedRegion(RemoveAllPRMessage.java:317) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:325) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367) > at > org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:424) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2873) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:2553) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.access$1300(ClusterDistributionManager.java:109) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.messageReceived(ClusterDistributionManager.java:3411) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.dispatchMessage(GMSMembershipManager.java:1102) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.handleOrDeferMessage(GMSMembershipManager.java:1022) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager$MyDCReceiver.messageReceived(GMSMembershipManager.java:399) > at > org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:722) > at > org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:824) > at > org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3898) > at > org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3508) > at > org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1814) > at org.apache.geode.internal.tcp.Connection.run(Connection.java:1676) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Once the exception is hit, it will remove the lockObjects hold by another > thread performing another operation. > at > org.apache.geode.internal.cache.BucketRegion.removeAndNotifyKeys(BucketRegion.java:454) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.doLocalRemoveAll(RemoveAllPRMessage.java:534) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.operateOnPartitionedRegion(RemoveAllPRMessage.java:317) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:325) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367) > at >
[jira] [Created] (GEODE-5888) A removeAll/putAll operation could remove lockObject held by another thread if region is closing
Eric Shu created GEODE-5888: --- Summary: A removeAll/putAll operation could remove lockObject held by another thread if region is closing Key: GEODE-5888 URL: https://issues.apache.org/jira/browse/GEODE-5888 Project: Geode Issue Type: Bug Components: regions Reporter: Eric Shu A bulk operation needs to hold lockObjects in BucketRegion.waitUntilLocked. However, it may hit RegionDestroyedException instead, and it will release lockObjects it does not hold. org.apache.geode.cache.RegionDestroyedException: Partitioned Region @21554698 [path='/partitionedRegion'; dataPolicy=PERSISTENT_PARTITION; prId=1; isDestroyed=true; isClosed=true; retryTimeout=360; serialNumber=7; partition attributes=PartitionAttributes@2144398013[redundantCopies=0;localMaxMemory=205;totalMaxMemory=2147483647;totalNumBuckets=113;partitionResolver=null;colocatedWith=null;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null]; on VM rs-GEM-1352-1526a0i3large-hydra-client-34(dataStoregemfire4_host1_19090:19090):1028] at org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7396) at org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2745) at org.apache.geode.internal.cache.BucketRegion.waitUntilLocked(BucketRegion.java:493) at org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.doLocalRemoveAll(RemoveAllPRMessage.java:437) at org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.operateOnPartitionedRegion(RemoveAllPRMessage.java:317) at org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:325) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367) at org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:424) at org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2873) at org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:2553) at org.apache.geode.distributed.internal.ClusterDistributionManager.access$1300(ClusterDistributionManager.java:109) at org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.messageReceived(ClusterDistributionManager.java:3411) at org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.dispatchMessage(GMSMembershipManager.java:1102) at org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.handleOrDeferMessage(GMSMembershipManager.java:1022) at org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager$MyDCReceiver.messageReceived(GMSMembershipManager.java:399) at org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:722) at org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:824) at org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3898) at org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3508) at org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1814) at org.apache.geode.internal.tcp.Connection.run(Connection.java:1676) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Once the exception is hit, it will remove the lockObjects hold by another thread performing another operation. at org.apache.geode.internal.cache.BucketRegion.removeAndNotifyKeys(BucketRegion.java:454) at org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.doLocalRemoveAll(RemoveAllPRMessage.java:534) at org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.operateOnPartitionedRegion(RemoveAllPRMessage.java:317) at org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:325) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367) at org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:424) at org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2873) at org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:2553) at org.apache.geode.distributed.internal.ClusterDistributionManager.access$1300(ClusterDistributionManager.java:109)
[jira] [Updated] (GEODE-5888) A removeAll/putAll operation could remove lockObject held by another thread if region is closing
[ https://issues.apache.org/jira/browse/GEODE-5888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-5888: Affects Version/s: 1.1.0 > A removeAll/putAll operation could remove lockObject held by another thread > if region is closing > > > Key: GEODE-5888 > URL: https://issues.apache.org/jira/browse/GEODE-5888 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Priority: Major > > A bulk operation needs to hold lockObjects in BucketRegion.waitUntilLocked. > However, it may hit RegionDestroyedException instead, and it will release > lockObjects it does not hold. > org.apache.geode.cache.RegionDestroyedException: Partitioned Region @21554698 > [path='/partitionedRegion'; dataPolicy=PERSISTENT_PARTITION; prId=1; > isDestroyed=true; isClosed=true; retryTimeout=360; serialNumber=7; > partition > attributes=PartitionAttributes@2144398013[redundantCopies=0;localMaxMemory=205;totalMaxMemory=2147483647;totalNumBuckets=113;partitionResolver=null;colocatedWith=null;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null]; > on VM > rs-GEM-1352-1526a0i3large-hydra-client-34(dataStoregemfire4_host1_19090:19090):1028] > at > org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7396) > at > org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2745) > at > org.apache.geode.internal.cache.BucketRegion.waitUntilLocked(BucketRegion.java:493) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.doLocalRemoveAll(RemoveAllPRMessage.java:437) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.operateOnPartitionedRegion(RemoveAllPRMessage.java:317) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:325) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367) > at > org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:424) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2873) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:2553) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.access$1300(ClusterDistributionManager.java:109) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.messageReceived(ClusterDistributionManager.java:3411) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.dispatchMessage(GMSMembershipManager.java:1102) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.handleOrDeferMessage(GMSMembershipManager.java:1022) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager$MyDCReceiver.messageReceived(GMSMembershipManager.java:399) > at > org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:722) > at > org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:824) > at > org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3898) > at > org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3508) > at > org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1814) > at org.apache.geode.internal.tcp.Connection.run(Connection.java:1676) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Once the exception is hit, it will remove the lockObjects hold by another > thread performing another operation. > at > org.apache.geode.internal.cache.BucketRegion.removeAndNotifyKeys(BucketRegion.java:454) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.doLocalRemoveAll(RemoveAllPRMessage.java:534) > at > org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.operateOnPartitionedRegion(RemoveAllPRMessage.java:317) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:325) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367) > at >
[jira] [Assigned] (GEODE-5760) CI failure: Expected exception Not found in QueryMonitorDUnitTest.testQueryMonitorRegionWithIndex
[
https://issues.apache.org/jira/browse/GEODE-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5760:
---
Assignee: Kenneth Howe
> CI failure: Expected exception Not found in
> QueryMonitorDUnitTest.testQueryMonitorRegionWithIndex
> -
>
> Key: GEODE-5760
> URL: https://issues.apache.org/jira/browse/GEODE-5760
> Project: Geode
> Issue Type: Bug
> Components: cq
>Reporter: Bill
>Assignee: Kenneth Howe
>Priority: Major
> Labels: swat
>
> In
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/415
> {code}
> > Task :geode-cq:distributedTest
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest >
> testQueryMonitorRegionWithIndex FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest$$Lambda$104/648688972.run
> in VM 4 running on Host 17a0abd8c00d with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:450)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:419)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:362)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:70)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.testQueryMonitorRegionWithIndex(QueryMonitorDUnitTest.java:239)
> Caused by:
> java.lang.AssertionError: Expected exception Not found. Expected
> exception with message:
> "Query execution taking more than the max execution time"
> Found
> Pool unexpected socket timed out on client connection=Pooled
> Connection to localhost:37885: Connection[localhost:37885]@176708196). Server
> unreachable: could not connect after 1 attempts
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.verifyException(QueryMonitorDUnitTest.java:410)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.exuteQuery(QueryMonitorDUnitTest.java:363)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.lambda$testQueryMonitorRegionWithIndex$bb17a952$3(QueryMonitorDUnitTest.java:239)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5887) checkRegisteredKeys function consumes alot of CPU
[
https://issues.apache.org/jira/browse/GEODE-5887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yossi reginiano updated GEODE-5887:
---
Priority: Minor (was: Major)
> checkRegisteredKeys function consumes alot of CPU
> -
>
> Key: GEODE-5887
> URL: https://issues.apache.org/jira/browse/GEODE-5887
> Project: Geode
> Issue Type: Improvement
>Reporter: yossi reginiano
>Priority: Minor
> Fix For: 1.8.0
>
>
> {color:#33}in our many runs we have observed that the following function
> - AcceptorImpl:checkRegisteredKeys consumes about 6% of total CPU{color}
> {color:#33}this function go over all the registered connections to the
> JVM server , check if it was closed - and if so remove that connection from
> the registration{color}
> {color:#33}this is done continuously while we have any registered
> key{color}
> {color:#33}we have run the flow with update runSelectorLoop() function in
> which checkRegisteredKeys function is not being called continuously but
> rather every second , and observed about 7% reduction in the function CPU
> consumption - with no negative effect on the flow (was strictly verified in
> multiple runs){color}
> {color:#33}we suggest to insert the following change into
> AcceptorImpl::runSelectorLoop (of course *timeLimit* will come as a parameter
> from the properties file){color}
>
> {color:#33}try {
> *long initialTime = System.currentTimeMillis();*
> *long timeLimit = 1000;*
>
> logger.info(LocalizedMessage.create(LocalizedStrings.AcceptorImpl_SELECTOR_ENABLED));
> while (this.selector.isOpen() && !Thread.currentThread().isInterrupted()) {
> {
> SystemFailure.checkFailure();
> //
> this.cache.getDistributedSystem().getCancelCriterion().checkCancelInProgress(null);
> if (this.cache.isClosed()) { // bug 38834
> break; // TODO should just ask cache's CancelCriterion
> }
> if (this.cache.getCancelCriterion().isCancelInProgress()) {
> break;
> }
> ServerConnection sc;
> *long delta = System.currentTimeMillis() - initialTime;*
> *if (delta >= timeLimit) {*
> *registeredKeys = checkRegisteredKeys(registeredKeys);*
> *initialTime = System.currentTimeMillis();*
> *}*
> if (registeredKeys == 0) {{color}
> {color:#33} {color}
> {color:#33}do note that due to many TO in this account - min-connections
> property was increased , which also causes checkRegisteredKeys to consume
> more CPU{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5887) checkRegisteredKeys function consumes alot of CPU
yossi reginiano created GEODE-5887:
--
Summary: checkRegisteredKeys function consumes alot of CPU
Key: GEODE-5887
URL: https://issues.apache.org/jira/browse/GEODE-5887
Project: Geode
Issue Type: Improvement
Reporter: yossi reginiano
Fix For: 1.8.0
{color:#33}in our many runs we have observed that the following function -
AcceptorImpl:checkRegisteredKeys consumes about 6% of total CPU{color}
{color:#33}this function go over all the registered connections to the JVM
server , check if it was closed - and if so remove that connection from the
registration{color}
{color:#33}this is done continuously while we have any registered key{color}
{color:#33}we have run the flow with update runSelectorLoop() function in
which checkRegisteredKeys function is not being called continuously but rather
every second , and observed about 7% reduction in the function CPU consumption
- with no negative effect on the flow (was strictly verified in multiple
runs){color}
{color:#33}we suggest to insert the following change into
AcceptorImpl::runSelectorLoop (of course *timeLimit* will come as a parameter
from the properties file){color}
{color:#33}try {
*long initialTime = System.currentTimeMillis();*
*long timeLimit = 1000;*
logger.info(LocalizedMessage.create(LocalizedStrings.AcceptorImpl_SELECTOR_ENABLED));
while (this.selector.isOpen() && !Thread.currentThread().isInterrupted()) {
{
SystemFailure.checkFailure();
//
this.cache.getDistributedSystem().getCancelCriterion().checkCancelInProgress(null);
if (this.cache.isClosed()) { // bug 38834
break; // TODO should just ask cache's CancelCriterion
}
if (this.cache.getCancelCriterion().isCancelInProgress()) {
break;
}
ServerConnection sc;
*long delta = System.currentTimeMillis() - initialTime;*
*if (delta >= timeLimit) {*
*registeredKeys = checkRegisteredKeys(registeredKeys);*
*initialTime = System.currentTimeMillis();*
*}*
if (registeredKeys == 0) {{color}
{color:#33} {color}
{color:#33}do note that due to many TO in this account - min-connections
property was increased , which also causes checkRegisteredKeys to consume more
CPU{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5887) checkRegisteredKeys function consumes alot of CPU
[
https://issues.apache.org/jira/browse/GEODE-5887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yossi reginiano updated GEODE-5887:
---
Priority: Major (was: Minor)
> checkRegisteredKeys function consumes alot of CPU
> -
>
> Key: GEODE-5887
> URL: https://issues.apache.org/jira/browse/GEODE-5887
> Project: Geode
> Issue Type: Improvement
>Reporter: yossi reginiano
>Priority: Major
> Fix For: 1.8.0
>
>
> {color:#33}in our many runs we have observed that the following function
> - AcceptorImpl:checkRegisteredKeys consumes about 6% of total CPU{color}
> {color:#33}this function go over all the registered connections to the
> JVM server , check if it was closed - and if so remove that connection from
> the registration{color}
> {color:#33}this is done continuously while we have any registered
> key{color}
> {color:#33}we have run the flow with update runSelectorLoop() function in
> which checkRegisteredKeys function is not being called continuously but
> rather every second , and observed about 7% reduction in the function CPU
> consumption - with no negative effect on the flow (was strictly verified in
> multiple runs){color}
> {color:#33}we suggest to insert the following change into
> AcceptorImpl::runSelectorLoop (of course *timeLimit* will come as a parameter
> from the properties file){color}
>
> {color:#33}try {
> *long initialTime = System.currentTimeMillis();*
> *long timeLimit = 1000;*
>
> logger.info(LocalizedMessage.create(LocalizedStrings.AcceptorImpl_SELECTOR_ENABLED));
> while (this.selector.isOpen() && !Thread.currentThread().isInterrupted()) {
> {
> SystemFailure.checkFailure();
> //
> this.cache.getDistributedSystem().getCancelCriterion().checkCancelInProgress(null);
> if (this.cache.isClosed()) { // bug 38834
> break; // TODO should just ask cache's CancelCriterion
> }
> if (this.cache.getCancelCriterion().isCancelInProgress()) {
> break;
> }
> ServerConnection sc;
> *long delta = System.currentTimeMillis() - initialTime;*
> *if (delta >= timeLimit) {*
> *registeredKeys = checkRegisteredKeys(registeredKeys);*
> *initialTime = System.currentTimeMillis();*
> *}*
> if (registeredKeys == 0) {{color}
> {color:#33} {color}
> {color:#33}do note that due to many TO in this account - min-connections
> property was increased , which also causes checkRegisteredKeys to consume
> more CPU{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
