You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gary Gregory (JIRA)" <ji...@apache.org> on 2018/03/08 20:07:00 UTC

[jira] [Commented] (CONFIGURATION-687) Memory leak and related issues with CombinedConfigurationBuilder

    [ https://issues.apache.org/jira/browse/CONFIGURATION-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391859#comment-16391859 ] 

Gary Gregory commented on CONFIGURATION-687:
--------------------------------------------

Thank you for your test case and analysis. This sounds nasty indeed. Would you be willing to provide a fix? You can use a PR on GitHub https://github.com/apache/commons-configuration

Gary



> Memory leak and related issues with CombinedConfigurationBuilder
> ----------------------------------------------------------------
>
>                 Key: CONFIGURATION-687
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-687
>             Project: Commons Configuration
>          Issue Type: Bug
>          Components: File reloading
>    Affects Versions: 2.2
>            Reporter: Luke Hamaty
>            Priority: Major
>         Attachments: ReloadCombinedBug.zip
>
>
> In CombinedConfigurationBuilder, each call to resetResult() adds new builders to the list of child builders. Likewise, and likely for the same reason, for ReloadingCombinedConfigurationBuilder, the resetResult() call adds to the list of subcontrollers.
> When resetResult() is called because of an reload update, the next _n_ calls to getReloadingController().checkForReloading() will also initiate reloading,  causing a reset and increasing the number of subcontrollers. So the first change causes 1 reload, the second change causes 2 reloads, and it doubles each time, so the 7th touch leads to 128 reloads!
> Functionally, there are no apparent symptoms until memory exhaustion and/or thrashing occur.
> This seems to be happen because CombinedConfigurationBuilder.initResultInstance rebuilds from the parameters without clearing all of the existing state, particularly _sourceData_, so SourceData ends up adding the reconstructed builders on top of the existing ones. Correcting this could be as simple as cleaning up and clearing sourceData to force creation of new SourceData.
> Code in attached zip (maven project) demonstrates the issue.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)