The reason for the memory leak is that we use suds objects as keys for the _datastore_browser_mapping cache. Suds objects do not implement __eq__ and __hash__ properly for VIM types such as ManagedObjectReference, we always have cache miss and thus _datastore_browser_mapping grows with every created instance.
This is how it looks like after two spawn() operations:
(Pdb) self._datastore_browser_mapping
{(obj){
value = "datastore-10"
_type = "Datastore"
}: (val){
value = "datastoreBrowser-datastore-10"
_type = "HostDatastoreBrowser"
}, (obj){
value = "datastore-10"
_type = "Datastore"
}: (val){
value = "datastoreBrowser-datastore-10"
_type = "HostDatastoreBrowser"
}}
The solution is to use the 'value' property of the MoRef as we do for the _datastore_dc_mapping.
I will submit a patch shortly.
The reason for the memory leak is that we use suds objects as keys for the _datastore_ browser_ mapping cache. Suds objects do not implement __eq__ and __hash__ properly for VIM types such as ManagedObjectRe ference, we always have cache miss and thus _datastore_ browser_ mapping grows with every created instance.
This is how it looks like after two spawn() operations:
(Pdb) self._datastore _browser_ mapping er-datastore- 10" rowser" er-datastore- 10" rowser"
{(obj){
value = "datastore-10"
_type = "Datastore"
}: (val){
value = "datastoreBrows
_type = "HostDatastoreB
}, (obj){
value = "datastore-10"
_type = "Datastore"
}: (val){
value = "datastoreBrows
_type = "HostDatastoreB
}}
The solution is to use the 'value' property of the MoRef as we do for the _datastore_ dc_mapping.
I will submit a patch shortly.