jpathwatch 0.93-rc1 has been released. This time round I thought it'd be better to call it a 'release candidate' first and later promote it to full release.
If you find any issues with 0.93 RC1 please post them here.
Thanks
Uwe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found a bug that exists on the Windows platform. When registering the 65th directory, the call to path.register(…) will never return. After digging into the code I found that the problem is due to an exception occurring that prevents a command result from being enqueued. Adding the 65th watched directory will kill the WindowsPathWatchService thread due to the following exception:
java.lang.IllegalArgumentException: handles array is longer than MAXIMUM_WAIT_OBJECTS (64)
As a result of the thread dying unexpectedly, a command result is never enqueued which causes the thread that is waiting for a result to be halted indefinitely.
The simplest thing to do is to probably surround "result = WaitForMultipleObjects(handles, false, INFINITE);" with a try…catch block to ensure that in the finally block a result is always enqueued.
It would be nice if the jpathwatch library could get around the 64 directory limit by using multiple threads (up to 64 handles per thread). Otherwise, if more than 64 directories need to be watched then the user of jpathwatch will need to create multiple instances of the WatchService with special-case code for Windows.
Thanks in advance for looking into this problem and creating such a helpful library!
-Patrick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not even a week ago someone else reported this as well (although it looks like you even went through the effort of debugging it, nice to see people starting to do that :). Looks like that's a call for action, so I'll see what I can do.
As you say, the current work-around is to create multiple WatchService instances (which each have their own thread).
Cheers,
Uwe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do have a patch that solves the problem of only being able to watch up to 63 directories on Windows. I have patched my version of jpathwatch and things are working correctly. Please contact me if you would like to apply my patch to your code.
Thanks,
Patrick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I sent you a reply on your SF email account (but you probably didnt check that account; happens to me all tue time ;-)
I'm definitely interested, can you send me the patch? In order to be accepted, it needs to:
* pass all existimg unit tests (testing on win32 only is fine as you only modify windows code)
* include a new unit test method that can reliably reproduce the problem
If you haven't had a chance for these yet please send the patch anyway, but including this would definitely be a great help for me.
Cheers,
Uwe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
jpathwatch 0.93-rc1 has been released. This time round I thought it'd be better to call it a 'release candidate' first and later promote it to full release.
If you find any issues with 0.93 RC1 please post them here.
Thanks
Uwe
I found a bug that exists on the Windows platform. When registering the 65th directory, the call to path.register(…) will never return. After digging into the code I found that the problem is due to an exception occurring that prevents a command result from being enqueued. Adding the 65th watched directory will kill the WindowsPathWatchService thread due to the following exception:
java.lang.IllegalArgumentException: handles array is longer than MAXIMUM_WAIT_OBJECTS (64)
As a result of the thread dying unexpectedly, a command result is never enqueued which causes the thread that is waiting for a result to be halted indefinitely.
The simplest thing to do is to probably surround "result = WaitForMultipleObjects(handles, false, INFINITE);" with a try…catch block to ensure that in the finally block a result is always enqueued.
It would be nice if the jpathwatch library could get around the 64 directory limit by using multiple threads (up to 64 handles per thread). Otherwise, if more than 64 directories need to be watched then the user of jpathwatch will need to create multiple instances of the WatchService with special-case code for Windows.
Thanks in advance for looking into this problem and creating such a helpful library!
-Patrick
Hi Patrick,
Not even a week ago someone else reported this as well (although it looks like you even went through the effort of debugging it, nice to see people starting to do that :). Looks like that's a call for action, so I'll see what I can do.
As you say, the current work-around is to create multiple WatchService instances (which each have their own thread).
Cheers,
Uwe
Hi Uwe,
I do have a patch that solves the problem of only being able to watch up to 63 directories on Windows. I have patched my version of jpathwatch and things are working correctly. Please contact me if you would like to apply my patch to your code.
Thanks,
Patrick
Hey Patrick,
I sent you a reply on your SF email account (but you probably didnt check that account; happens to me all tue time ;-)
I'm definitely interested, can you send me the patch? In order to be accepted, it needs to:
* pass all existimg unit tests (testing on win32 only is fine as you only modify windows code)
* include a new unit test method that can reliably reproduce the problem
If you haven't had a chance for these yet please send the patch anyway, but including this would definitely be a great help for me.
Cheers,
Uwe