[
https://issues.apache.org/jira/browse/GEODE-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-4180:
-----------------------------
Affects Version/s: 1.4.0
> Reference to locator view file and/or its contents are not cleaned up
> properly during cache close
> -------------------------------------------------------------------------------------------------
>
> Key: GEODE-4180
> URL: https://issues.apache.org/jira/browse/GEODE-4180
> Project: Geode
> Issue Type: Bug
> Components: locator
> Affects Versions: 1.4.0
> Reporter: Kirk Lund
>
> I wrote a new dunit test (I'll update this ticket when it's merged to
> develop). 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
> [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
> 2) createsRegionMappingWithMinimumParams
> [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}]
> 3) createsRegionMappingInService
> [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}]
> 4) recreatesCacheFromClusterConfigWithRegionMapping
> [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}]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
