This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | FileObject.get Input/Output Stream mutual exclusion | ||
---|---|---|---|
Product: | platform | Reporter: | Jaroslav Tulach <jtulach> |
Component: | Filesystems | Assignee: | rmatous <rmatous> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | jglick, ttran |
Priority: | P2 | Keywords: | THREAD |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 40739 | ||
Attachments: |
Test that demonstrates the problem
Simplest fix that detects and reports the problem instead of silently pretending that everything is all right More abitious fix Stream + tests |
Description
Jaroslav Tulach
2004-03-03 19:20:19 UTC
this should be handled w/ extreme care. Yarda's suggested solution introduces a hidden lock Created attachment 16187 [details]
Test that demonstrates the problem
I believe that the current behaviour is buggy and as we have now test I am turning this issue from enh to defect. I am not sure about the priority, but as this can be responsible for any random problem, I am setting this to p2. Created attachment 16188 [details]
Simplest fix that detects and reports the problem instead of silently pretending that everything is all right
This seems like P3 unless there is a known significant problem arising from it. Anyway, the patch looks fine; I can't think of any situation where it would be unwanted. Jarda, okay. Let integrate the patch first thing after you'll be back at work. *After* because in case of trouble you'd be available to resolve it Thanks Created attachment 16205 [details]
More abitious fix
I am suspecting various problems with settings files (as issue 40290) to be caused by this problem - e.g. somebody starts to read the content of setting file until it is fully created and possibly messes up the public id, etc. For that the early detection fix (that throws exception) is enough. If such situation occurs, we will know about it and yes, I cannot think of a situation when it would go wrong. Just instead of reading unfinished content (means wrong content) it throws exception, I believe that is better. If we really get such exception and we will be searching for a solution I offer the more ambitious fix, that contains a recovery mechanism for cases when the read/write collision occurs. For reference: the last-attached patch is a kind of spin lock with timeout. Crude but probably safer than the read-write lock which was also proposed, at least in the absence of a clear global locking strategy for Filesystems. Your patch ensures that you can't get input stream until related output stream is closed. But what about if you get first input stream and then output stream (there may occure various race conditions). There exist FileLock (could be embryo of global locking strategy) in filesystems. There could be possible to get exclusive and non exclusive locks. FileLocks could also call nio.FileLocks to use native locking. There could be provided support for mutual IS & OS exclusion and something like described in #40739. But it deserves API changes, agreement and reviews. So, I think that RFE would be more suitable here. If there are real known problems caused by current behaviour then FileLocks can be already used for mutual IS & OS exclusion (get FileLock also for reading from input stream and somehow handle FileAlreadyLockedException). I modified attached patch. Please see new patch and review. Created attachment 16453 [details]
Stream + tests
Definitively improves current situation. I was not able to find out a test for mutual exclusion of write when an input stream is open, which seems to be also addressed by the changes in code, however. /cvs/openide/src/org/openide/filesystems/AbstractFileObject.java,v new revision: 1.97; previous revision: 1.96 /cvs/openide/src/org/openide/filesystems/StreamPool.java,v <-- new revision: 1.6; previous revision: 1.5 /cvs/openide/test/unit/src/org/openide/filesystems/FileObjectTestHid.java,v new revision: 1.38; previous revision: 1.37 Closed, too old |