geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kirk Lund (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (GEODE-4180) Reference to locator view file and/or its contents are not cleaned up properly during cache close
Date Fri, 05 Jan 2018 22:36:00 GMT

     [ https://issues.apache.org/jira/browse/GEODE-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kirk Lund reassigned GEODE-4180:
--------------------------------

    Assignee: Kirk Lund

> 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)

Mime
View raw message