[
https://issues.apache.org/jira/browse/GEODE-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314112#comment-16314112
]
Kirk Lund edited comment on GEODE-4180 at 1/5/18 11:18 PM:
-----------------------------------------------------------
Looks like we'll need to devise a scheme for handling default user.dir usage if
we want to be able to write integration tests that write to the file system
without risking file-based test pollution.
The easiest solution is to change any calls like this:
{noformat}
this.viewFile = new File("locator" + server.getPort() + "view.dat");
{noformat}
...to this alternative that allows a test to override the current working
directory:
{noformat}
this.viewFile = new File(System.getProperty("user.dir"), "locator" +
server.getPort() + "view.dat");
{noformat}
If I make the above change to GMSLocator, the problem is fixed and I can write
tests that use unique working directories.
was (Author: klund):
Looks like we'll have devise a scheme for handling default user.dir usage if we
want to be able to write integration tests that write to the file system
without risking file-based test pollution.
The easiest solution is to change any calls like this:
{noformat}
this.viewFile = new File("locator" + server.getPort() + "view.dat");
{noformat}
...to this alternative that allows a test to override the current working
directory:
{noformat}
this.viewFile = new File(System.getProperty("user.dir"), "locator" +
server.getPort() + "view.dat");
{noformat}
If I make the above change to GMSLocator, the problem is fixed and I can write
tests that use unique working directories.
> 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, tests
> Affects Versions: 1.4.0
> Reporter: Kirk Lund
> Assignee: Kirk Lund
>
> 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
(v6.4.14#64029)
