[ https://issues.apache.org/jira/browse/CLOUDSTACK-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722003#comment-15722003 ]
ASF GitHub Bot commented on CLOUDSTACK-9564: -------------------------------------------- GitHub user rhtyd opened a pull request: https://github.com/apache/cloudstack/pull/1816 CLOUDSTACK-9564: Fix NPE due to intermittent test assertion The test assertion on a pool object may return a null object, as objects can be randomly expired/tombstoned. This will fix a NPE sometimes seen due to recently merge for the fix for CLOUDSTACK-9564. (I'll merge this if Travis passes) /cc @abhinandanprateek @murali-reddy You can merge this pull request into a Git repository by running: $ git pull https://github.com/shapeblue/cloudstack 4.9-fix-npe-vmware Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1816.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1816 ---- commit dcbf3c8689ed3eaed8653763ec27d2907671c72b Author: Rohit Yadav <rohit.ya...@shapeblue.com> Date: 2016-12-05T11:15:33Z CLOUDSTACK-9564: Fix NPE due to intermittent test assertion The test assertion on a pool object may return a null object, as objects can be randomly expired/tombstoned. This will fix a NPE sometimes seen due to recently merge for the fix for CLOUDSTACK-9564. Signed-off-by: Rohit Yadav <rohit.ya...@shapeblue.com> ---- > Fix memory leak in VmwareContextPool > ------------------------------------ > > Key: CLOUDSTACK-9564 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9564 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Reporter: Rohit Yadav > Assignee: Rohit Yadav > > In a recent management server crash, it was found that the largest > contributor to memory leak was in VmwareContextPool where a registry is held > (arraylist) that grows indefinitely. The list itself is not used anywhere or > consumed. There exists a hashmap (pool) that returns a list of contexts for > existing poolkey (address/username) that is used instead. The fix would be to > get rid of the registry and limit the hashmap context list length for any > poolkey. -- This message was sent by Atlassian JIRA (v6.3.4#6332)