Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not use broken suds.cache.ObjectCache #108

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

khvn26
Copy link

@khvn26 khvn26 commented Jan 11, 2019

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 khvn26 changed the title Fix #4 Do not use broken suds.cache.ObjectCache Jan 11, 2019
@khvn26
Copy link
Author

khvn26 commented Mar 21, 2019

Any movement on this?

@tector
Copy link

tector commented May 6, 2020

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

@yuzeh
Copy link

yuzeh commented Mar 21, 2022

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
Copy link
Collaborator

qitia commented Mar 22, 2022

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.

None yet

4 participants