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.

Bug 40738 - FileObject.get Input/Output Stream mutual exclusion
Summary: FileObject.get Input/Output Stream mutual exclusion
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: rmatous
Keywords: THREAD
Depends on:
Blocks: 40739
  Show dependency tree
Reported: 2004-03-03 19:20 UTC by Jaroslav Tulach
Modified: 2008-12-22 21:05 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Test that demonstrates the problem (3.27 KB, patch)
2004-07-11 16:05 UTC, Jaroslav Tulach
Details | Diff
Simplest fix that detects and reports the problem instead of silently pretending that everything is all right (1.17 KB, patch)
2004-07-11 16:09 UTC, Jaroslav Tulach
Details | Diff
More abitious fix (6.25 KB, patch)
2004-07-12 15:57 UTC, Jaroslav Tulach
Details | Diff
Stream + tests (11.22 KB, patch)
2004-07-26 15:13 UTC, rmatous
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2004-03-03 19:20:19 UTC
As part of my work on issue 40290 I have find out
that there is a subtle problem present in the
system that can cause nearly anything to get
broken "once upon a time". The problem is that
when one part of the system is writing to output
stream of a file object, other part can read the
(not yet finished) content. This is sometimes
causing DataObjects to not be propertly
recognized, mime type being wrongly guessed, etc,

I'd like to propose simple solution: Mutual
exclusion of getInputStream() and
getOutputStream(). That way if there is an open
output stream for a file object, nobody else could
get an inputstream, the call would block (for
certain timeout, that is my suggestion).

The implementation shall be pretty straightforward
as there already is StreamPool that registers all
open streams and can be used to implement the
mutual exclusion.

I believe that by fixing this issue a lot of
phantom errors occuring from time to time would
Comment 1 _ ttran 2004-04-04 22:12:49 UTC
this should be handled w/ extreme care.  Yarda's suggested solution
introduces a hidden lock
Comment 2 Jaroslav Tulach 2004-07-11 16:05:02 UTC
Created attachment 16187 [details]
Test that demonstrates the problem
Comment 3 Jaroslav Tulach 2004-07-11 16:07:25 UTC
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.
Comment 4 Jaroslav Tulach 2004-07-11 16:09:27 UTC
Created attachment 16188 [details]
Simplest fix that detects and reports the problem instead of silently pretending that everything is all right
Comment 5 Jesse Glick 2004-07-11 16:44:43 UTC
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.
Comment 6 _ ttran 2004-07-11 20:38:15 UTC
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

Comment 7 Jaroslav Tulach 2004-07-12 15:57:25 UTC
Created attachment 16205 [details]
More abitious fix
Comment 8 Jaroslav Tulach 2004-07-12 16:04:13 UTC
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.
Comment 9 Jesse Glick 2004-07-12 21:38:24 UTC
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.
Comment 10 rmatous 2004-07-22 12:17:09 UTC
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

Comment 11 rmatous 2004-07-26 15:12:23 UTC
I modified attached patch. Please see new patch and  review.
Comment 12 rmatous 2004-07-26 15:13:17 UTC
Created attachment 16453 [details]
Stream + tests
Comment 13 Jaroslav Tulach 2004-07-27 10:01:12 UTC
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.
Comment 14 rmatous 2004-07-29 11:01:06 UTC
new revision: 1.97; previous revision: 1.96

/cvs/openide/src/org/openide/filesystems/,v  <--  new
revision: 1.6; previous revision: 1.5

new revision: 1.38; previous revision: 1.37
Comment 15 Zdenek Konecny 2005-08-05 14:19:40 UTC
Closed, too old