[
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 <RMI TCP Connection(1)-192.168.1.18>
> tid=20] recovery file not found:
> /var/folders/28/m__9dv1906n60kmz7t71wm680000gn/T/junit543979839291182624/vm-0-createsRegionMappingOnceOnly/locator0view.dat
> [vm0] [info 2017/12/29 10:59:31.135 PST <RMI TCP Connection(1)-192.168.1.18>
> tid=20] received new view: View[192.168.1.18(58582:locator)<ec><v0>:32770|0]
> members: [192.168.1.18(58582:locator)<ec><v0>:32770]
> [vm0] old view is: null
> {noformat}
> 2) createsRegionMappingWithMinimumParams
> {noformat}
> [vm0] [info 2017/12/29 10:59:34.580 PST <RMI TCP Connection(1)-192.168.1.18>
> tid=20] Peer locator recovering from
> /var/folders/28/m__9dv1906n60kmz7t71wm680000gn/T/junit1076413749574999935/vm-0-createsRegionMappingWithMinimumParams/locator0view.dat
> [vm0] [info 2017/12/29 10:59:34.580 PST <RMI TCP Connection(1)-192.168.1.18>
> tid=20] Peer locator recovered membership is
> View[192.168.1.18(58582:locator)<ec><v0>:32770|-1] members:
> [192.168.1.18(58580)<v1>:32771{lead}]
> {noformat}
> 3) createsRegionMappingInService
> {noformat}
> [vm0] [info 2017/12/29 10:59:40.538 PST <RMI TCP Connection(1)-192.168.1.18>
> tid=20] Peer locator recovering from
> /var/folders/28/m__9dv1906n60kmz7t71wm680000gn/T/junit8253504123764665822/vm-0-createsRegionMappingInService/locator0view.dat
> [vm0] [info 2017/12/29 10:59:40.538 PST <RMI TCP Connection(1)-192.168.1.18>
> tid=20] Peer locator recovered membership is
> View[192.168.1.18(58582:locator)<ec><v0>:32770|-1] members:
> [192.168.1.18(58580)<v1>:32771{lead}]
> {noformat}
> 4) recreatesCacheFromClusterConfigWithRegionMapping
> {noformat}
> [vm0] [info 2017/12/29 10:59:46.495 PST <RMI TCP Connection(1)-192.168.1.18>
> tid=20] Peer locator recovering from
> /var/folders/28/m__9dv1906n60kmz7t71wm680000gn/T/junit1056719983598139185/vm-0-recreatesCacheFromClusterConfigWithRegionMapping/locator0view.dat
> [vm0] [info 2017/12/29 10:59:46.496 PST <RMI TCP Connection(1)-192.168.1.18>
> tid=20] Peer locator recovered membership is
> View[192.168.1.18(58582:locator)<ec><v0>:32770|-1] members:
> [192.168.1.18(58580)<v1>:32771{lead}]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
