search

sam / doubleshot

Build and Dependency Management for mixed Java/Ruby projects.
MIT License
19 stars 22 forks source link

listen is flaky #59

Open sam opened 12 years ago

sam commented 12 years ago

The Listen gem (or our usage of it, same result) is flaky. It fails to start a Listener a third of the time, and occassionally falls back to polling for no known reason.

It seems like it's pretty likely this is going to continue to give us headaches going forward. We should look into alternatives.

The only other Ruby library I'm aware of is Watchr, but it's not maintained. We should either pull that in and patch up the 1.9 compatibility warnings, or look into Java library alternatives. I suspect that a Java alternative would be the most reliable and cross-platform robust, but I think Watchr is pretty simple, so as long as it doesn't resort to polling as it's default mode of operation and takes advantage of platform specific features for file system events, then it might make sense to spike that before going too far down other paths.

Either way this only impacts a version small portion of Doubleshot as a whole, in a single file, so it shouldn't be a huge effort.

Apache has at least a couple different packages for a File System Monitor. One I've seen used in JCI that appears to be non-recursive (which would be annoying as we'd have to glob for subdirectories first), and this one I haven't really looked at yet: http://commons.apache.org/io/api-2.4/org/apache/commons/io/monitor/package-summary.html

If we go down the JAR route, it'd probably be worth polling irc.freenode.net#jruby and see if anyone has any suggestions/experience to offer.

sam commented 11 years ago

BTW, the sum total of the Listen code in Doubleshot is in these two locations:

sam commented 11 years ago

Eric, please give this one a shot. Let me know if you have any questions. Like I said, I'd probably start by vendoring in Watchr and patching up the RbConfig 1.9 warnings.

sam commented 11 years ago

We'll replace Listen with OnChange when it's ready as a static dependency in our pom.xml.

Once this is done we'll lose compatibility with Java6 since OnChange uses java.nio.file.WatchService, which was introduced with Java7. Java7 is a manual install on OSX and older common *nix versions, but I can live with that. Use the latest JVM. It's a year (or so) old at this point.