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

Too many open files issues #705

Closed
botev opened this issue Mar 14, 2018 · 3 comments
Closed

Too many open files issues #705

botev opened this issue Mar 14, 2018 · 3 comments

Comments

@botev
Copy link

botev commented Mar 14, 2018

Hi,
I'm using zeep for accessing a SOAP service. However, for some reason it seems that there is an issue with zeep closing sockets or some temporary files as after some period of time I always get the same error:

'Connection aborted.', OSError(24, 'Too many open files'))

Is there any workaround this?

@mvantellingen
Copy link
Owner

Could you please provide more info? (Like the wsdl?)

@shrhawk-entertainer
Copy link

any update on this ?

CharString added a commit to CharString/python-zeep that referenced this issue Sep 15, 2023
I bumped into this when opening several wsdl which in turn opened lots
of xsd, with 'file://' scheme.

The issue was that the `resp.raw.close` nor `resp.raw.release_conn` set
in the `FileAdapter` were ever called.

It's unclear to me whether this should be fixed in requests. It doesn't
do that great a job at resource management for the naive user aka
Human™. It makes sense to me that exhaustively reading `Response.raw`
should close it unless the caller explicitly set `stream` on the
request. Probably by using this `closing` pattern in the generator in
`Response.iter_content`.

Workarounds without this fix:
 - using a scheme-less url as zeep will assume it's a local path and
   open the file as a context manager.
 - use one of the caches from `zeep.cache` to hide duplicate open resources.
Kuv added a commit to Kuv/python-zeep that referenced this issue Apr 21, 2024
🐛[mvantellingen#705] Properly close 'file://' resources
@nguyendon
Copy link

I am running into this issue as well when I am load testing. It looks like any newly created sockets are never closed by the application. They sit in CLOSE_WAIT indefinitely.

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

No branches or pull requests

4 participants