You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an example, when a TiffAdapter is created it holds a handle to an open TIFF file (via tifffile.TiffFile). After __init__() completes, that file handle is used by calls to metadata(), read(), and read_block(). The latter two already cache the array data for future reads. I believe the file handle never gets closed until the server shuts down. I see this as hundreds of ResourceWarnings when running the test suite.
I expect other file-backed adapters act similarly.
With cached read operations already in use (and assuming metadata() results could be cached), is it necessary to keep the file open for performance (server response time)? Did earlier versions already try opening the file on demand when the cache misses?
Alternatively, I suppose the server could have a cold timeout...so that if a file hasn't been accessed for X minutes, then the file handle gets closed.
The text was updated successfully, but these errors were encountered:
I wonder whether object_cache should be overhauled ~now. Like the old (now replaced) implementation of tiled.client.cache.Cache, it's a proof of principle put in place when we were still evaluating whether Tiled was even viable as a concept.
I think something much, much simpler would address the use case. Perhaps a TTL cache of file handles.
As an example, when a
TiffAdapter
is created it holds a handle to an open TIFF file (viatifffile.TiffFile
). After__init__()
completes, that file handle is used by calls tometadata()
,read()
, andread_block()
. The latter two already cache the array data for future reads. I believe the file handle never gets closed until the server shuts down. I see this as hundreds ofResourceWarning
s when running the test suite.I expect other file-backed adapters act similarly.
With cached read operations already in use (and assuming
metadata()
results could be cached), is it necessary to keep the file open for performance (server response time)? Did earlier versions already try opening the file on demand when the cache misses?Alternatively, I suppose the server could have a cold timeout...so that if a file hasn't been accessed for X minutes, then the file handle gets closed.
The text was updated successfully, but these errors were encountered: