Daemon Thread [thread-1] (Suspended (exception ConcurrentModificationException))
HashMap$ValueIterator(HashMap$HashIterator<E>).nextEntry() line: 793
HashMap$ValueIterator.next() line: 822
PollingPathWatchService.poll() line: 146
PollingPathWatchService.poll(long, TimeUnit) line: 187
PollingPathWatchService.take() line: 193
<<Stack frame removed>>
Executors$RunnableAdapter<T>.call() line: 441
FutureTask$Sync.innerRun() line: 303
FutureTask<V>.run() line: 138
ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
ThreadPoolExecutor$Worker.run() line: 908
Thread.run() line: 662
The iterator created on line 146 of PollingPathWatchService.java throws this exception as when a FileNotFoundExeception is thrown (on line 149) cancelmpl() is called on line 150 which results in a removal of the cancelled key from the keys HashMap which is currently being iterated over.
yep, you're right; that code section is just asking for it, isn't it? ;)
One easy solution would be to iterate over a copy of the keys map, although not as nice performance wise
Just wondering, which platform is this on?
Don't suppose this will be fixed?
I run into the same problem on OSX and monitoring multiple directories.
Was planing on using jpathwatch since the JDK7 version is unreliable in my testing.
As you can see there's not much going on with jpathwatch any more. As
expected, JDK7 has sucked up a lot of the audience (I basically wrote
it in the first place because JDK7 took so long to be released).
Could you provide a test case that reproduces the issue? Ideally one
that I can automate :)
On Wed, May 7, 2014 at 12:04 AM, Hani Naguib
haninaguib-at-users.sf.net |sourceforge.net/Allow_neo-media|
kbllfvx9vt@sneakemail.com wrote:
Related
jpathwatch issues: #6
This and issue #5 are the same thing - the iterator is fail-fast and in both implementations when the underlying collection being iterated changes via the call the cancelImpl() on FileNotFound you get the ConcurrentModificationException (granted it's a rubbish name when in a single thread!)
Simplest one liner change is to make the 'keys' HashMap a ConcurrentHashMap.
Alterntively remove the 'keys.remove()' from cancelImpl() and make it the callers responsibility.. (uff!)
Our junit test is built upon our own framework so won't help directly, but simple steps to reproduce:
Due to the ConcurrentMod exception the watch service is broken, no more events are notified.
jpathwatch otherwise works well on HighSierra/APFS which alternative impl BarbaryWatchService doesn't. Not sure if that's down to their impl or use of the Carbon FSEvents API.
I think there'll be more interest again in jpathwatch with APFS uptake, as Oracle continues to fail to provide a usable Mac implementation, still not in Java 9.
Would be good to fix this issue though! Huge thanks for writing jpathwatch in the first place :)