Russ Given that our repositories are pluggable it is important that we'd surface this sort of information via some API friendly mechanism. We should consider, in my opinion, providing some status gathering call(s) to the ContentRepository API.
Otherwise, there is not a safe mechanism to do this with. We actually realized this was being abused previously via the properties mechanism and refactorings in 1.0 helped make that cleaner so now we need to just provide a nice mechanism to do what you're seeking. Having said this, please do also consider just using an external monitoring service for things like directory usage,etc.. Since you're only needing this information for passive usage purposes in NiFi there is probably not much of a benefit of hosting it in nifi. What do you think? Thanks Joe On Fri, Dec 2, 2016 at 11:11 AM, Russell Bateman <[email protected]> wrote: > /nifi.properties/ locations, such as > nifi.content.repository.directory.default, are typically specified as > relative paths, but I suppose they could be arbitrarily complex. Whatever > the case, I need to discover the actual path to the content subdirectory at > runtime not because I want to create, delete, read or change files there, > but only to know what volume this subdirectory is on so that I can use > File.getUsableSpace()in a custom processor I'm writing that will monitor > space left. > > Is there a reliable way to discover this, directly or via a property using > NiFi Expression Language? > > Thanks, > > Russ
