[jira] [Updated] (GEODE-4180) Tests should not mutate system property "user.dir"
[ https://issues.apache.org/jira/browse/GEODE-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4180: -- Labels: pull-request-available (was: ) > Tests should not mutate system property "user.dir" > -- > > Key: GEODE-4180 > URL: https://issues.apache.org/jira/browse/GEODE-4180 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.4.0 >Reporter: Kirk Lund >Priority: Major > Labels: pull-request-available > > We temporarily set the member-timeout to max value to allow us to step > through some code in the debugger. We noticed that if we run all 4 tests > together, tests 2-3 were hanging. > After removing the member-timeout setting, we found that all of the tests > after the 1st test are all trying to connect to the non-existent locator from > the 1st test. This causes all tests after the 1st test to take ~2 seconds > longer to run when run together than if you run them by individually. > After digging a bit more, I discovered that even though the test is deleting > the entire directory containing the locator0view.dat file, some code > somewhere must still have an open connection or stream to it because its > contents from the 1st test continue to be read for each subsequent test even > after the file itself and its directory have been deleted. > I believe some static code somewhere is keeping a reference to the file > and/or its contents. So each test continues to read the same content even > though the file no longer exists on disk. > The following shows the relevant messages logged by 4 tests in a DUnit test > that shows tests 2-3 find and using the file and/or its contents from test 1. > Note that I used IntelliJ debugger to confirm that this occurs even after > test 1 deletes the file and its directory. > 1) createsRegionMappingOnceOnly > {noformat} > [vm0] [info 2017/12/29 10:59:30.826 PST > tid=20] recovery file not found: > /var/folders/28/m__9dv1906n60kmz7t71wm68gn/T/junit543979839291182624/vm-0-createsRegionMappingOnceOnly/locator0view.dat > [vm0] [info 2017/12/29 10:59:31.135 PST > tid=20] received new view: View[192.168.1.18(58582:locator):32770|0] > members: [192.168.1.18(58582:locator):32770] > [vm0] old view is: null > {noformat} > 2) createsRegionMappingWithMinimumParams > {noformat} > [vm0] [info 2017/12/29 10:59:34.580 PST > tid=20] Peer locator recovering from > /var/folders/28/m__9dv1906n60kmz7t71wm68gn/T/junit107641374957435/vm-0-createsRegionMappingWithMinimumParams/locator0view.dat > [vm0] [info 2017/12/29 10:59:34.580 PST > tid=20] Peer locator recovered membership is > View[192.168.1.18(58582:locator):32770|-1] members: > [192.168.1.18(58580):32771{lead}] > {noformat} > 3) createsRegionMappingInService > {noformat} > [vm0] [info 2017/12/29 10:59:40.538 PST > tid=20] Peer locator recovering from > /var/folders/28/m__9dv1906n60kmz7t71wm68gn/T/junit8253504123764665822/vm-0-createsRegionMappingInService/locator0view.dat > [vm0] [info 2017/12/29 10:59:40.538 PST > tid=20] Peer locator recovered membership is > View[192.168.1.18(58582:locator):32770|-1] members: > [192.168.1.18(58580):32771{lead}] > {noformat} > 4) recreatesCacheFromClusterConfigWithRegionMapping > {noformat} > [vm0] [info 2017/12/29 10:59:46.495 PST > tid=20] Peer locator recovering from > /var/folders/28/m__9dv1906n60kmz7t71wm68gn/T/junit1056719983598139185/vm-0-recreatesCacheFromClusterConfigWithRegionMapping/locator0view.dat > [vm0] [info 2017/12/29 10:59:46.496 PST > tid=20] Peer locator recovered membership is > View[192.168.1.18(58582:locator):32770|-1] members: > [192.168.1.18(58580):32771{lead}] > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4180) Tests should not mutate system property "user.dir"
[ https://issues.apache.org/jira/browse/GEODE-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-4180: - Summary: Tests should not mutate system property "user.dir" (was: Reference to locator view file and/or its contents are not cleaned up properly during cache close) > Tests should not mutate system property "user.dir" > -- > > Key: GEODE-4180 > URL: https://issues.apache.org/jira/browse/GEODE-4180 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.4.0 >Reporter: Kirk Lund >Priority: Major > > We temporarily set the member-timeout to max value to allow us to step > through some code in the debugger. We noticed that if we run all 4 tests > together, tests 2-3 were hanging. > After removing the member-timeout setting, we found that all of the tests > after the 1st test are all trying to connect to the non-existent locator from > the 1st test. This causes all tests after the 1st test to take ~2 seconds > longer to run when run together than if you run them by individually. > After digging a bit more, I discovered that even though the test is deleting > the entire directory containing the locator0view.dat file, some code > somewhere must still have an open connection or stream to it because its > contents from the 1st test continue to be read for each subsequent test even > after the file itself and its directory have been deleted. > I believe some static code somewhere is keeping a reference to the file > and/or its contents. So each test continues to read the same content even > though the file no longer exists on disk. > The following shows the relevant messages logged by 4 tests in a DUnit test > that shows tests 2-3 find and using the file and/or its contents from test 1. > Note that I used IntelliJ debugger to confirm that this occurs even after > test 1 deletes the file and its directory. > 1) createsRegionMappingOnceOnly > {noformat} > [vm0] [info 2017/12/29 10:59:30.826 PST > tid=20] recovery file not found: > /var/folders/28/m__9dv1906n60kmz7t71wm68gn/T/junit543979839291182624/vm-0-createsRegionMappingOnceOnly/locator0view.dat > [vm0] [info 2017/12/29 10:59:31.135 PST > tid=20] received new view: View[192.168.1.18(58582:locator):32770|0] > members: [192.168.1.18(58582:locator):32770] > [vm0] old view is: null > {noformat} > 2) createsRegionMappingWithMinimumParams > {noformat} > [vm0] [info 2017/12/29 10:59:34.580 PST > tid=20] Peer locator recovering from > /var/folders/28/m__9dv1906n60kmz7t71wm68gn/T/junit107641374957435/vm-0-createsRegionMappingWithMinimumParams/locator0view.dat > [vm0] [info 2017/12/29 10:59:34.580 PST > tid=20] Peer locator recovered membership is > View[192.168.1.18(58582:locator):32770|-1] members: > [192.168.1.18(58580):32771{lead}] > {noformat} > 3) createsRegionMappingInService > {noformat} > [vm0] [info 2017/12/29 10:59:40.538 PST > tid=20] Peer locator recovering from > /var/folders/28/m__9dv1906n60kmz7t71wm68gn/T/junit8253504123764665822/vm-0-createsRegionMappingInService/locator0view.dat > [vm0] [info 2017/12/29 10:59:40.538 PST > tid=20] Peer locator recovered membership is > View[192.168.1.18(58582:locator):32770|-1] members: > [192.168.1.18(58580):32771{lead}] > {noformat} > 4) recreatesCacheFromClusterConfigWithRegionMapping > {noformat} > [vm0] [info 2017/12/29 10:59:46.495 PST > tid=20] Peer locator recovering from > /var/folders/28/m__9dv1906n60kmz7t71wm68gn/T/junit1056719983598139185/vm-0-recreatesCacheFromClusterConfigWithRegionMapping/locator0view.dat > [vm0] [info 2017/12/29 10:59:46.496 PST > tid=20] Peer locator recovered membership is > View[192.168.1.18(58582:locator):32770|-1] members: > [192.168.1.18(58580):32771{lead}] > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)