Skip to content

Do not use broken suds.cache.ObjectCache - #108

Open
Kim Gustyr (khvn26) wants to merge 1 commit into
BingAds:masterfrom
aoricom:master
Open

Do not use broken suds.cache.ObjectCache#108
Kim Gustyr (khvn26) wants to merge 1 commit into
BingAds:masterfrom
aoricom:master

Conversation

@khvn26

@khvn26 Kim Gustyr (khvn26) commented Jan 11, 2019

Copy link
Copy Markdown

Please consider fixing #4 since it seriously affects library usage in production.

This PR introduces a simple in-memory cache to use by default not only during ServiceClient instantiation, but also with the module-level suds.Client instance which provides the object factory for the library internals.

Without the fix, /tmp/suds was becoming enormous pretty fast even when providing a custom cache in suds_options since _CAMPAIGN_MANAGEMENT_SERVICE_V12 was still using suds.cache.ObjectCache.

The fix does not change dependencies or monkey-patch anything.

@khvn26 Kim Gustyr (khvn26) changed the title Fix #4 Do not use broken suds.cache.ObjectCache Jan 11, 2019
@khvn26

Copy link
Copy Markdown
Author

Any movement on this?

@tector

tector commented May 6, 2020

Copy link
Copy Markdown

This solution looks good to me!
I desperately wasted multiple days on fixing suds cache issues...
Please do merge it Microsoft Advertising (@BingAds), Eric Urban (@eric-urban), qitia

@yuzeh

Copy link
Copy Markdown

This is seriously affecting us in production right now. Would be great if we could default to not using a file-system cache, or any cache at all.

@qitia

qitia commented Mar 22, 2022

Copy link
Copy Markdown
Contributor

yes I agree that we should not using cache at all - since v13.0.9.1, we are using local 'proxies' to cache wsdl. So there should be no benefit to have the cache. we will work on merging this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants