Not all files seem to be closed after context manager exits

[nikoladze]

First found this using uproot, but i believe the issue comes from ffspec-xrootd. I see an issue when reading several files successively from the dcache storage at LMU.

This example hangs after having processed the 50th file which i believe is the current setting for "max movers" on that dcache storage

urls = long_list_of_xrootd_urls

import fsspec

for i, url in enumerate(urls):
    with fsspec.open(url) as f:
        print(i, url[-100:], end="\r")
        f.fs.cat_file(url, 0, 10)

I'm not a dcache expert, but i believe the settings on the maximum number of "movers" lead to requests being queued when one opens more connections than the maximum amount. I suspect some connections are not closed and it has something to do with the file handle cache introduced in #54 since calling invalidate_cache() seems to make the problem disappear - the following does not cause any issues:

for i, url in enumerate(urls):
    with fsspec.open(url) as f:
        print(i, url[-100:], end="\r")
        f.fs.cat_file(url, 0, 10)
    f.fs.invalidate_cache()

Also, no issues if i use f.read(...) instead of f.fs.cat_file(...)

Version used:

>>> import fsspec_xrootd
>>> fsspec_xrootd.__version__
'0.3.0'

[nsmith-]

Have you tried playing with the cache size and/or ttl?
https://github.com/CoffeaTeam/fsspec-xrootd/blob/6e36c038e4269db351f17d89e62fddb105578d58/src/fsspec_xrootd/xrootd.py#L278-L279
Perhaps setting the cache size to 50 will alleviate the issue for your storage system?

[nsmith-]

You can pass in these storage options with fsspec.open(url, filehandle_cache_size=50) etc.

[nikoladze]

indeed that seems to work fine (for cache sizes up to around 30) and file_handle_cache_size seems to be also passed through correctly when using uproot.open. Thanks!