What Kind of Cacheing Does the Java NFS Client Use?

Its cache model is quite similar to other NFS client implementations. File and directory data are cached from between 3 and 30 seconds, depending on the frequency of file or directory modification. That is, if the file is being changed every 10 seconds then the cache time will be set to 10 seconds, but if the file or directory hasn't changed for 6 months then it'll be cached for up to 30 seconds. When the cache time expires, the client will revalidate the cached data via a GETATTR request to the server. If the file or directory on the server is changed, then the cached copy is invalidated. The client uses the attributes returned by NFS v3 READ, WRITE, and LOOKUP calls avoiding unnecessary GETATTR revalidations.

To avoid hogging the JVM heap, the client avoids aggressive caching of file data. Only the current, read-ahead or write-behind buffers are cached. This has no impact on sequential file access, but could cause performance problems for applications that frequently re-read files exceeding a buffer in size (8k for v2, 32k for v3). The list of names in an NFS directory is cached when the directory is first read. If the server is read using NFS version 3 then the client will use the READDIRPLUS request and obtain the filehandles and attributes of all the directory entries. Note that a file tree walk or other procedure that touches lots of NFS files will eventually run the client out of memory. This memory limitation will be fixed in future versions of the client.