2

I am being able to use Jnotify for listening events as file cration, modification etc. My concern is how Jnotify works. I mean what it uses get event. Is it safe to use in refrence of resource uses. I read in another SO question -- https://stackoverflow.com/questions/11100003/why-does-jnotify-consume-so-much-resources -- that it consume much resources.

Another way I can solve my problem is a while loop till a condition then program is shutdown.

Which will be better to use consumes less resources.

Community
  • 1
  • 1
Abhishek bhutra
  • 1,400
  • 1
  • 11
  • 29

2 Answers2

5

linnotify talks to the kernel to get notified of filesystem changes. No polling, the kernel notifies on changes to the subscribed folders.

jnotify is a JNI wrapper around libjnotify.

Nonetheless, if you are using Java 7, all that is history, replaced by the new java file I/O (NIO.2) package.

Miquel
  • 15,405
  • 8
  • 54
  • 87
  • thanks for fast response.so it is safe to use? and will not eat resources?? – Abhishek bhutra Jul 24 '12 at 13:59
  • Which one? Neither Java File I/O or jnotify will eat resources, both will subscribe and *not* poll the filesystem. jnotify has some portability issues because of the native library. Java 7's file I/O does not have the problem (since it was solved when making the whole JVM run in that system). So, if you can use Java 7, go for file I/O. Otherwise, you have no choice but go to `jnotify` (or poll the filesystem wherever you can't get `jnotify` to run) – Miquel Jul 24 '12 at 14:05
  • 1
    The Java 7 WatchService should be the answer, but... it is unacceptably slow. My tests show latency times of 8s on MacOS and 200-500ms on Linux. See http://stackoverflow.com/questions/9588737/is-java-7-watchservice-slow-for-anyone-else – Assen Kolov Nov 26 '14 at 15:59
  • This is because the Java 7 WatchService falls back to polling on platforms where there is native support. Linux and Windows are currently the only systems for which there is native support for WatchService. On other systems, options (with native support and better performance) include jnotify, jpathwatch, and BarbaryWatchService. For more info, see: http://wiki.netbeans.org/NativeFileNotifications – Zac B Feb 04 '17 at 20:37
  • So to this day JNotify is actually more portable than the JVM support of monitoring files. The official package supports Windows, Mac and Linux and there is an unofficial FreeBSD support here: http://jnotify.o-notation.org/ Speaks volumes on the sad state of Java. a project I created at 2005 is still better than the official support that came back years later. – Omry Yadan Mar 10 '17 at 08:28
2

From the site...

JNotify Linux support

JNotify Linux API is a thin wrapper around Linux INotify API. Since Linux INotify API does not support recursive listening on a directory, JNotify add this functionality by createing an INotify watch on every sub directory under the watched directory (transparently). this process takes a time which is linear to the number of directories in the tree being recursively watched, and require system resources, namely - INotify watches, which are limited, by default to 8192 watches per processes.

The limitations are documented. Also gives idea about implementation.

Your problem is related to File changed listener in Java , the highly voted answer there is DefaultFileMonitor, from Apache commons. I suggest you give it a try.

Community
  • 1
  • 1
Jayan
  • 18,003
  • 15
  • 89
  • 143
  • thanx for reply.I have implemented that. Just needed expert advice if we can use it in production enviornment and causes no harm such as high resource usages – Abhishek bhutra Jul 24 '12 at 14:05