-
Bug
-
Resolution: Duplicate
-
P4
-
7
-
None
-
generic
-
generic
The existing \java.util.logging.FileHandlerimplementation silently ignores
the IOException thrown by FileChannel.tryLock() when testing with the lock
currently being hold by anyone and assumes that locking is not supported and
proceed without the lock. There could be potentially two processes writing
to the same log file.
412 try {
413 FileLock fl = fc.tryLock();
414 if (fl == null) {
415 // We failed to get the lock. Try next file.
416 continue;
417 }
418 // We got the lock OK.
419 } catch (IOException ix) {
420 // We got an IOException while trying to get the lock.
421 // This normally indicates that locking is not supported
422 // on the target directory. We have to proceed without
423 // getting a lock. Drop through.
424 }
the IOException thrown by FileChannel.tryLock() when testing with the lock
currently being hold by anyone and assumes that locking is not supported and
proceed without the lock. There could be potentially two processes writing
to the same log file.
412 try {
413 FileLock fl = fc.tryLock();
414 if (fl == null) {
415 // We failed to get the lock. Try next file.
416 continue;
417 }
418 // We got the lock OK.
419 } catch (IOException ix) {
420 // We got an IOException while trying to get the lock.
421 // This normally indicates that locking is not supported
422 // on the target directory. We have to proceed without
423 // getting a lock. Drop through.
424 }
- duplicates
-
JDK-8048020 Regression on java.util.logging.FileHandler
-
- Closed
-