[jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[ http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12367818 ] Vladimir Strigun commented on HARMONY-40: - Thanks, Tim. Can't reproduce with latest sources. > FileChannel assotiated with FileOutputStream not closed after closing output > stream > --- > > Key: HARMONY-40 > URL: http://issues.apache.org/jira/browse/HARMONY-40 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Vladimir Strigun > Assignee: Tim Ellison > > When I receive FileChannel from file output stream, write something to stream > and then close it, channel, assotiated with the stream is still open. I'll > attach unit test for the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[ http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12366330 ] Vladimir Strigun commented on HARMONY-40: - This bug is a part of Harmony-42 issue. I can't reproduce it with latest sources. Anyway, I think suggested test can be added to tests/java/io . > FileChannel assotiated with FileOutputStream not closed after closing output > stream > --- > > Key: HARMONY-40 > URL: http://issues.apache.org/jira/browse/HARMONY-40 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Vladimir Strigun > > When I receive FileChannel from file output stream, write something to stream > and then close it, channel, assotiated with the stream is still open. I'll > attach unit test for the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
Tim Ellison wrote:
I accept your point. Since this comment was quite specific to the issue
then it seemed fitting to keep that as a JIRA comment, if a jira comment
opens up a wider consideration then I agree it should be responded to on
the dev list.
To be clear, I certainly agree that it belonged in JIRA. It just got me
thinking about one of my pet peeves that I have no solution for, which
is in itself a pet peeve
geir
In this instance, Paulex has a good point about why Vladimir's suggested
patch will not work. If that comment is not made in the JIRA then there
is no indication to JIRA readers that the proposed change is in dispute.
Bright ideas always welcome, of course.
Regards,
Tim
Geir Magnusson Jr wrote:
Interesting problem. I do agree with you - keeping it in one place is a
good thing, and JIRA is that place.
However, I always find it hard to read jira comment streams - they don't
feel the same as discussion in regular dev@ mail.
I have no idea what to do about this. I've thought about doing
discussion here, and then dropping a mail thread ID into the JIRA. That
actually would work nicely, maybe. I've also thought about getting JIRA
to reformat comments mail to be more like a regular quoted discussion
(maybe put that at top, and regular JIRA output at bottom of mail.)
Clearly I have no real solution. I figured I'd just complain in case
someone else has a bright idea... :)
geir
Tim Ellison wrote:
Paulex,
IMHO This would be better as a comment on the JIRA issue itself, then we
can keep them all together. Would you like to repeat yourself there ;-)
Thanks
Tim
Paulex Yang wrote:
The patch does work in some case, but it is not enough.
First, when the channel is closed, the relevant stream(FileInputStream,
FileOutputStream or RandomAccessFile) also needs to closed. So only add
codes to the FileOutputStream is not enough.
Second, the FileOutputStream/FileInputStream will close itself in the
finalize() method(as Java spec says), and with your patch, current
implementation in Harmony will close the channel at that time, too. This
is very dangerous, because if someone writes code like below, the fos
may be garbage collected and closed, and channel will also be closed, so
that the following operation on channel will throw unexpected exception.
.
FileChannel channel = null;
try{
FileOutputStream fos = new FileOutputStream("somefile.txt", false);
channel = fos.getChannel();
}catch(Exception e){
}
/*continue operate on channel*/
.
Third, the native close operation should only be executed once, so that
some synchronization mechanism on the channel and stream should be
introduced, which should also avoid deadlock when one thread is calling
fos.close() while the other is calling channel.close().
As a conclusion, the close issue is yet another reason that the three
classes IO package need to be refactored to based on same JNI interface
with FileChannel. Pls. refer to my work on JIRA issue #42.
Vladimir Strigun (JIRA)
[
http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705
]
Vladimir Strigun commented on HARMONY-40:
-
Forced close of file current file channel in file output stream can be
added (diff for current FileOutputStream)
173a174,177
if (channel != null) {
channel.close();
channel = null;
}
FileChannel assotiated with FileOutputStream not closed after closing
output stream
---
Key: HARMONY-40
URL: http://issues.apache.org/jira/browse/HARMONY-40
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When I receive FileChannel from file output stream, write something
to stream and then close it, channel, assotiated with the stream is
still open. I'll attach unit test for the issue.
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
Isn't the idea to have a shared implementation that both FileChannel
and java.io stream. Can't we just use some sort of reference counting
to close it on finalize?
On 1/25/06, Rodrigo Kumpera <[EMAIL PROTECTED]> wrote:
> On 1/25/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
> > Agree, it should, but currently not in Harmony.
> >
> > Rodrigo Kumpera wrote:
> > > Aren't channels supposed to hold references to the original streams?
> > >
> > > On 1/24/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
> > >
> > >> The patch does work in some case, but it is not enough.
> > >>
> > >> First, when the channel is closed, the relevant stream(FileInputStream,
> > >> FileOutputStream or RandomAccessFile) also needs to closed. So only add
> > >> codes to the FileOutputStream is not enough.
> > >>
> > >> Second, the FileOutputStream/FileInputStream will close itself in the
> > >> finalize() method(as Java spec says), and with your patch, current
> > >> implementation in Harmony will close the channel at that time, too. This
> > >> is very dangerous, because if someone writes code like below, the fos
> > >> may be garbage collected and closed, and channel will also be closed, so
> > >> that the following operation on channel will throw unexpected exception.
> > >>
> > >> .
> > >> FileChannel channel = null;
> > >> try{
> > >> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
> > >> channel = fos.getChannel();
> > >> }catch(Exception e){
> > >> }
> > >> /*continue operate on channel*/
> > >> .
> > >>
> > >>
> > >> Third, the native close operation should only be executed once, so that
> > >> some synchronization mechanism on the channel and stream should be
> > >> introduced, which should also avoid deadlock when one thread is calling
> > >> fos.close() while the other is calling channel.close().
> > >>
> > >> As a conclusion, the close issue is yet another reason that the three
> > >> classes IO package need to be refactored to based on same JNI interface
> > >> with FileChannel. Pls. refer to my work on JIRA issue #42.
> > >>
> > >> Vladimir Strigun (JIRA)
> > >>
> > >>> [
> > >>> http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705
> > >>> ]
> > >>>
> > >>> Vladimir Strigun commented on HARMONY-40:
> > >>> -
> > >>>
> > >>> Forced close of file current file channel in file output stream can be
> > >>> added (diff for current FileOutputStream)
> > >>> 173a174,177
> > >>>
> > >>>
> > if (channel != null) {
> > channel.close();
> > channel = null;
> > }
> >
> >
> > >>>
> > FileChannel assotiated with FileOutputStream not closed after closing
> > output stream
> > ---
> >
> > Key: HARMONY-40
> > URL: http://issues.apache.org/jira/browse/HARMONY-40
> > Project: Harmony
> > Type: Bug
> > Components: Classlib
> > Reporter: Vladimir Strigun
> >
> >
> > >>>
> > When I receive FileChannel from file output stream, write something to
> > stream and then close it, channel, assotiated with the stream is still
> > open. I'll attach unit test for the issue.
> >
> >
> > >>>
> > >> --
> > >> Paulex Yang
> > >> China Software Development Lab
> > >> IBM
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
> >
> >
>
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
On 1/25/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
> Agree, it should, but currently not in Harmony.
>
> Rodrigo Kumpera wrote:
> > Aren't channels supposed to hold references to the original streams?
> >
> > On 1/24/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
> >
> >> The patch does work in some case, but it is not enough.
> >>
> >> First, when the channel is closed, the relevant stream(FileInputStream,
> >> FileOutputStream or RandomAccessFile) also needs to closed. So only add
> >> codes to the FileOutputStream is not enough.
> >>
> >> Second, the FileOutputStream/FileInputStream will close itself in the
> >> finalize() method(as Java spec says), and with your patch, current
> >> implementation in Harmony will close the channel at that time, too. This
> >> is very dangerous, because if someone writes code like below, the fos
> >> may be garbage collected and closed, and channel will also be closed, so
> >> that the following operation on channel will throw unexpected exception.
> >>
> >> .
> >> FileChannel channel = null;
> >> try{
> >> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
> >> channel = fos.getChannel();
> >> }catch(Exception e){
> >> }
> >> /*continue operate on channel*/
> >> .
> >>
> >>
> >> Third, the native close operation should only be executed once, so that
> >> some synchronization mechanism on the channel and stream should be
> >> introduced, which should also avoid deadlock when one thread is calling
> >> fos.close() while the other is calling channel.close().
> >>
> >> As a conclusion, the close issue is yet another reason that the three
> >> classes IO package need to be refactored to based on same JNI interface
> >> with FileChannel. Pls. refer to my work on JIRA issue #42.
> >>
> >> Vladimir Strigun (JIRA)
> >>
> >>> [
> >>> http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705
> >>> ]
> >>>
> >>> Vladimir Strigun commented on HARMONY-40:
> >>> -
> >>>
> >>> Forced close of file current file channel in file output stream can be
> >>> added (diff for current FileOutputStream)
> >>> 173a174,177
> >>>
> >>>
> if (channel != null) {
> channel.close();
> channel = null;
> }
>
>
> >>>
> FileChannel assotiated with FileOutputStream not closed after closing
> output stream
> ---
>
> Key: HARMONY-40
> URL: http://issues.apache.org/jira/browse/HARMONY-40
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Vladimir Strigun
>
>
> >>>
> When I receive FileChannel from file output stream, write something to
> stream and then close it, channel, assotiated with the stream is still
> open. I'll attach unit test for the issue.
>
>
> >>>
> >> --
> >> Paulex Yang
> >> China Software Development Lab
> >> IBM
> >>
> >>
> >>
> >>
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
Agree, it should, but currently not in Harmony.
Rodrigo Kumpera wrote:
Aren't channels supposed to hold references to the original streams?
On 1/24/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
The patch does work in some case, but it is not enough.
First, when the channel is closed, the relevant stream(FileInputStream,
FileOutputStream or RandomAccessFile) also needs to closed. So only add
codes to the FileOutputStream is not enough.
Second, the FileOutputStream/FileInputStream will close itself in the
finalize() method(as Java spec says), and with your patch, current
implementation in Harmony will close the channel at that time, too. This
is very dangerous, because if someone writes code like below, the fos
may be garbage collected and closed, and channel will also be closed, so
that the following operation on channel will throw unexpected exception.
.
FileChannel channel = null;
try{
FileOutputStream fos = new FileOutputStream("somefile.txt", false);
channel = fos.getChannel();
}catch(Exception e){
}
/*continue operate on channel*/
.
Third, the native close operation should only be executed once, so that
some synchronization mechanism on the channel and stream should be
introduced, which should also avoid deadlock when one thread is calling
fos.close() while the other is calling channel.close().
As a conclusion, the close issue is yet another reason that the three
classes IO package need to be refactored to based on same JNI interface
with FileChannel. Pls. refer to my work on JIRA issue #42.
Vladimir Strigun (JIRA)
[
http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705 ]
Vladimir Strigun commented on HARMONY-40:
-
Forced close of file current file channel in file output stream can be added
(diff for current FileOutputStream)
173a174,177
if (channel != null) {
channel.close();
channel = null;
}
FileChannel assotiated with FileOutputStream not closed after closing output
stream
---
Key: HARMONY-40
URL: http://issues.apache.org/jira/browse/HARMONY-40
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When I receive FileChannel from file output stream, write something to stream
and then close it, channel, assotiated with the stream is still open. I'll
attach unit test for the issue.
--
Paulex Yang
China Software Development Lab
IBM
--
Paulex Yang
China Software Development Lab
IBM
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
Aren't channels supposed to hold references to the original streams?
On 1/24/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
> The patch does work in some case, but it is not enough.
>
> First, when the channel is closed, the relevant stream(FileInputStream,
> FileOutputStream or RandomAccessFile) also needs to closed. So only add
> codes to the FileOutputStream is not enough.
>
> Second, the FileOutputStream/FileInputStream will close itself in the
> finalize() method(as Java spec says), and with your patch, current
> implementation in Harmony will close the channel at that time, too. This
> is very dangerous, because if someone writes code like below, the fos
> may be garbage collected and closed, and channel will also be closed, so
> that the following operation on channel will throw unexpected exception.
>
> .
> FileChannel channel = null;
> try{
> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
> channel = fos.getChannel();
> }catch(Exception e){
> }
> /*continue operate on channel*/
> .
>
>
> Third, the native close operation should only be executed once, so that
> some synchronization mechanism on the channel and stream should be
> introduced, which should also avoid deadlock when one thread is calling
> fos.close() while the other is calling channel.close().
>
> As a conclusion, the close issue is yet another reason that the three
> classes IO package need to be refactored to based on same JNI interface
> with FileChannel. Pls. refer to my work on JIRA issue #42.
>
> Vladimir Strigun (JIRA)
> > [
> > http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705
> > ]
> >
> > Vladimir Strigun commented on HARMONY-40:
> > -
> >
> > Forced close of file current file channel in file output stream can be
> > added (diff for current FileOutputStream)
> > 173a174,177
> >
> >> if (channel != null) {
> >> channel.close();
> >> channel = null;
> >> }
> >>
> >
> >
> >> FileChannel assotiated with FileOutputStream not closed after closing
> >> output stream
> >> ---
> >>
> >> Key: HARMONY-40
> >> URL: http://issues.apache.org/jira/browse/HARMONY-40
> >> Project: Harmony
> >> Type: Bug
> >> Components: Classlib
> >> Reporter: Vladimir Strigun
> >>
> >
> >
> >> When I receive FileChannel from file output stream, write something to
> >> stream and then close it, channel, assotiated with the stream is still
> >> open. I'll attach unit test for the issue.
> >>
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
Well, copy done ;-)
Tim Ellison wrote:
I accept your point. Since this comment was quite specific to the issue
then it seemed fitting to keep that as a JIRA comment, if a jira comment
opens up a wider consideration then I agree it should be responded to on
the dev list.
In this instance, Paulex has a good point about why Vladimir's suggested
patch will not work. If that comment is not made in the JIRA then there
is no indication to JIRA readers that the proposed change is in dispute.
Bright ideas always welcome, of course.
Regards,
Tim
Geir Magnusson Jr wrote:
Interesting problem. I do agree with you - keeping it in one place is a
good thing, and JIRA is that place.
However, I always find it hard to read jira comment streams - they don't
feel the same as discussion in regular dev@ mail.
I have no idea what to do about this. I've thought about doing
discussion here, and then dropping a mail thread ID into the JIRA. That
actually would work nicely, maybe. I've also thought about getting JIRA
to reformat comments mail to be more like a regular quoted discussion
(maybe put that at top, and regular JIRA output at bottom of mail.)
Clearly I have no real solution. I figured I'd just complain in case
someone else has a bright idea... :)
geir
Tim Ellison wrote:
Paulex,
IMHO This would be better as a comment on the JIRA issue itself, then we
can keep them all together. Would you like to repeat yourself there ;-)
Thanks
Tim
Paulex Yang wrote:
The patch does work in some case, but it is not enough.
First, when the channel is closed, the relevant stream(FileInputStream,
FileOutputStream or RandomAccessFile) also needs to closed. So only add
codes to the FileOutputStream is not enough.
Second, the FileOutputStream/FileInputStream will close itself in the
finalize() method(as Java spec says), and with your patch, current
implementation in Harmony will close the channel at that time, too. This
is very dangerous, because if someone writes code like below, the fos
may be garbage collected and closed, and channel will also be closed, so
that the following operation on channel will throw unexpected exception.
.
FileChannel channel = null;
try{
FileOutputStream fos = new FileOutputStream("somefile.txt", false);
channel = fos.getChannel();
}catch(Exception e){
}
/*continue operate on channel*/
.
Third, the native close operation should only be executed once, so that
some synchronization mechanism on the channel and stream should be
introduced, which should also avoid deadlock when one thread is calling
fos.close() while the other is calling channel.close().
As a conclusion, the close issue is yet another reason that the three
classes IO package need to be refactored to based on same JNI interface
with FileChannel. Pls. refer to my work on JIRA issue #42.
Vladimir Strigun (JIRA)
[
http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705
]
Vladimir Strigun commented on HARMONY-40:
-
Forced close of file current file channel in file output stream can be
added (diff for current FileOutputStream)
173a174,177
if (channel != null) {
channel.close();
channel = null;
}
FileChannel assotiated with FileOutputStream not closed after closing
output stream
---
Key: HARMONY-40
URL: http://issues.apache.org/jira/browse/HARMONY-40
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When I receive FileChannel from file output stream, write something
to stream and then close it, channel, assotiated with the stream is
still open. I'll attach unit test for the issue.
--
Paulex Yang
China Software Development Lab
IBM
[jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[
http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363945 ]
Paulex Yang commented on HARMONY-40:
As Tim asked, copied from my comment on mailing list;)
The patch does work in some case, but it is not enough.
First, when the channel is closed, the relevant stream(FileInputStream,
FileOutputStream or RandomAccessFile) also needs to closed. So only add codes
to the FileOutputStream is not enough.
Second, the FileOutputStream/FileInputStream will close itself in the
finalize() method(as Java spec says), and with your patch, current
implementation in Harmony will close the channel at that time, too. This is
very dangerous, because if someone writes code like below, the fos may be
garbage collected and closed, and channel will also be closed, so that the
following operation on channel will throw unexpected exception.
.
FileChannel channel = null;
try{
FileOutputStream fos = new FileOutputStream("somefile.txt", false);
channel = fos.getChannel();
}catch(Exception e){
}
/*continue operate on channel*/
.
Third, the native close operation should only be executed once, so that some
synchronization mechanism on the channel and stream should be introduced, which
should also avoid deadlock when one thread is calling fos.close() while the
other is calling channel.close().
As a conclusion, the close issue is yet another reason that the three classes
IO package need to be refactored to based on same JNI interface with
FileChannel. Pls. refer to my work on JIRA issue #42.
> FileChannel assotiated with FileOutputStream not closed after closing output
> stream
> ---
>
> Key: HARMONY-40
> URL: http://issues.apache.org/jira/browse/HARMONY-40
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Vladimir Strigun
>
> When I receive FileChannel from file output stream, write something to stream
> and then close it, channel, assotiated with the stream is still open. I'll
> attach unit test for the issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
I accept your point. Since this comment was quite specific to the issue
then it seemed fitting to keep that as a JIRA comment, if a jira comment
opens up a wider consideration then I agree it should be responded to on
the dev list.
In this instance, Paulex has a good point about why Vladimir's suggested
patch will not work. If that comment is not made in the JIRA then there
is no indication to JIRA readers that the proposed change is in dispute.
Bright ideas always welcome, of course.
Regards,
Tim
Geir Magnusson Jr wrote:
> Interesting problem. I do agree with you - keeping it in one place is a
> good thing, and JIRA is that place.
>
> However, I always find it hard to read jira comment streams - they don't
> feel the same as discussion in regular dev@ mail.
>
> I have no idea what to do about this. I've thought about doing
> discussion here, and then dropping a mail thread ID into the JIRA. That
> actually would work nicely, maybe. I've also thought about getting JIRA
> to reformat comments mail to be more like a regular quoted discussion
> (maybe put that at top, and regular JIRA output at bottom of mail.)
>
> Clearly I have no real solution. I figured I'd just complain in case
> someone else has a bright idea... :)
>
> geir
>
>
> Tim Ellison wrote:
>> Paulex,
>>
>> IMHO This would be better as a comment on the JIRA issue itself, then we
>> can keep them all together. Would you like to repeat yourself there ;-)
>>
>> Thanks
>> Tim
>>
>> Paulex Yang wrote:
>>> The patch does work in some case, but it is not enough.
>>>
>>> First, when the channel is closed, the relevant stream(FileInputStream,
>>> FileOutputStream or RandomAccessFile) also needs to closed. So only add
>>> codes to the FileOutputStream is not enough.
>>>
>>> Second, the FileOutputStream/FileInputStream will close itself in the
>>> finalize() method(as Java spec says), and with your patch, current
>>> implementation in Harmony will close the channel at that time, too. This
>>> is very dangerous, because if someone writes code like below, the fos
>>> may be garbage collected and closed, and channel will also be closed, so
>>> that the following operation on channel will throw unexpected exception.
>>>
>>> .
>>> FileChannel channel = null;
>>> try{
>>>FileOutputStream fos = new FileOutputStream("somefile.txt", false);
>>>channel = fos.getChannel();
>>> }catch(Exception e){
>>> }
>>> /*continue operate on channel*/
>>> .
>>>
>>>
>>> Third, the native close operation should only be executed once, so that
>>> some synchronization mechanism on the channel and stream should be
>>> introduced, which should also avoid deadlock when one thread is calling
>>> fos.close() while the other is calling channel.close().
>>>
>>> As a conclusion, the close issue is yet another reason that the three
>>> classes IO package need to be refactored to based on same JNI interface
>>> with FileChannel. Pls. refer to my work on JIRA issue #42.
>>>
>>> Vladimir Strigun (JIRA)
[
http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705
]
Vladimir Strigun commented on HARMONY-40:
-
Forced close of file current file channel in file output stream can be
added (diff for current FileOutputStream)
173a174,177
> if (channel != null) {
> channel.close();
> channel = null;
> }
>
> FileChannel assotiated with FileOutputStream not closed after closing
> output stream
> ---
>
>
>
> Key: HARMONY-40
> URL: http://issues.apache.org/jira/browse/HARMONY-40
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Vladimir Strigun
>
> When I receive FileChannel from file output stream, write something
> to stream and then close it, channel, assotiated with the stream is
> still open. I'll attach unit test for the issue.
>
>>>
>>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
Interesting problem. I do agree with you - keeping it in one place is a
good thing, and JIRA is that place.
However, I always find it hard to read jira comment streams - they don't
feel the same as discussion in regular dev@ mail.
I have no idea what to do about this. I've thought about doing
discussion here, and then dropping a mail thread ID into the JIRA. That
actually would work nicely, maybe. I've also thought about getting JIRA
to reformat comments mail to be more like a regular quoted discussion
(maybe put that at top, and regular JIRA output at bottom of mail.)
Clearly I have no real solution. I figured I'd just complain in case
someone else has a bright idea... :)
geir
Tim Ellison wrote:
Paulex,
IMHO This would be better as a comment on the JIRA issue itself, then we
can keep them all together. Would you like to repeat yourself there ;-)
Thanks
Tim
Paulex Yang wrote:
The patch does work in some case, but it is not enough.
First, when the channel is closed, the relevant stream(FileInputStream,
FileOutputStream or RandomAccessFile) also needs to closed. So only add
codes to the FileOutputStream is not enough.
Second, the FileOutputStream/FileInputStream will close itself in the
finalize() method(as Java spec says), and with your patch, current
implementation in Harmony will close the channel at that time, too. This
is very dangerous, because if someone writes code like below, the fos
may be garbage collected and closed, and channel will also be closed, so
that the following operation on channel will throw unexpected exception.
.
FileChannel channel = null;
try{
FileOutputStream fos = new FileOutputStream("somefile.txt", false);
channel = fos.getChannel();
}catch(Exception e){
}
/*continue operate on channel*/
.
Third, the native close operation should only be executed once, so that
some synchronization mechanism on the channel and stream should be
introduced, which should also avoid deadlock when one thread is calling
fos.close() while the other is calling channel.close().
As a conclusion, the close issue is yet another reason that the three
classes IO package need to be refactored to based on same JNI interface
with FileChannel. Pls. refer to my work on JIRA issue #42.
Vladimir Strigun (JIRA)
[
http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705
]
Vladimir Strigun commented on HARMONY-40:
-
Forced close of file current file channel in file output stream can be
added (diff for current FileOutputStream)
173a174,177
if (channel != null) {
channel.close();
channel = null;
}
FileChannel assotiated with FileOutputStream not closed after closing
output stream
---
Key: HARMONY-40
URL: http://issues.apache.org/jira/browse/HARMONY-40
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When I receive FileChannel from file output stream, write something
to stream and then close it, channel, assotiated with the stream is
still open. I'll attach unit test for the issue.
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
Paulex,
IMHO This would be better as a comment on the JIRA issue itself, then we
can keep them all together. Would you like to repeat yourself there ;-)
Thanks
Tim
Paulex Yang wrote:
> The patch does work in some case, but it is not enough.
>
> First, when the channel is closed, the relevant stream(FileInputStream,
> FileOutputStream or RandomAccessFile) also needs to closed. So only add
> codes to the FileOutputStream is not enough.
>
> Second, the FileOutputStream/FileInputStream will close itself in the
> finalize() method(as Java spec says), and with your patch, current
> implementation in Harmony will close the channel at that time, too. This
> is very dangerous, because if someone writes code like below, the fos
> may be garbage collected and closed, and channel will also be closed, so
> that the following operation on channel will throw unexpected exception.
>
> .
> FileChannel channel = null;
> try{
>FileOutputStream fos = new FileOutputStream("somefile.txt", false);
>channel = fos.getChannel();
> }catch(Exception e){
> }
> /*continue operate on channel*/
> .
>
>
> Third, the native close operation should only be executed once, so that
> some synchronization mechanism on the channel and stream should be
> introduced, which should also avoid deadlock when one thread is calling
> fos.close() while the other is calling channel.close().
>
> As a conclusion, the close issue is yet another reason that the three
> classes IO package need to be refactored to based on same JNI interface
> with FileChannel. Pls. refer to my work on JIRA issue #42.
>
> Vladimir Strigun (JIRA)
>> [
>> http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705
>> ]
>> Vladimir Strigun commented on HARMONY-40:
>> -
>>
>> Forced close of file current file channel in file output stream can be
>> added (diff for current FileOutputStream)
>> 173a174,177
>>
>>> if (channel != null) {
>>> channel.close();
>>> channel = null;
>>> }
>>>
>>
>>
>>> FileChannel assotiated with FileOutputStream not closed after closing
>>> output stream
>>> ---
>>>
>>>
>>> Key: HARMONY-40
>>> URL: http://issues.apache.org/jira/browse/HARMONY-40
>>> Project: Harmony
>>> Type: Bug
>>> Components: Classlib
>>> Reporter: Vladimir Strigun
>>>
>>
>>
>>> When I receive FileChannel from file output stream, write something
>>> to stream and then close it, channel, assotiated with the stream is
>>> still open. I'll attach unit test for the issue.
>>>
>>
>>
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
The patch does work in some case, but it is not enough.
First, when the channel is closed, the relevant stream(FileInputStream,
FileOutputStream or RandomAccessFile) also needs to closed. So only add
codes to the FileOutputStream is not enough.
Second, the FileOutputStream/FileInputStream will close itself in the
finalize() method(as Java spec says), and with your patch, current
implementation in Harmony will close the channel at that time, too. This
is very dangerous, because if someone writes code like below, the fos
may be garbage collected and closed, and channel will also be closed, so
that the following operation on channel will throw unexpected exception.
.
FileChannel channel = null;
try{
FileOutputStream fos = new FileOutputStream("somefile.txt", false);
channel = fos.getChannel();
}catch(Exception e){
}
/*continue operate on channel*/
.
Third, the native close operation should only be executed once, so that
some synchronization mechanism on the channel and stream should be
introduced, which should also avoid deadlock when one thread is calling
fos.close() while the other is calling channel.close().
As a conclusion, the close issue is yet another reason that the three
classes IO package need to be refactored to based on same JNI interface
with FileChannel. Pls. refer to my work on JIRA issue #42.
Vladimir Strigun (JIRA)
[ http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705 ]
Vladimir Strigun commented on HARMONY-40:
-
Forced close of file current file channel in file output stream can be added
(diff for current FileOutputStream)
173a174,177
if (channel != null) {
channel.close();
channel = null;
}
FileChannel assotiated with FileOutputStream not closed after closing output
stream
---
Key: HARMONY-40
URL: http://issues.apache.org/jira/browse/HARMONY-40
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When I receive FileChannel from file output stream, write something to stream
and then close it, channel, assotiated with the stream is still open. I'll
attach unit test for the issue.
--
Paulex Yang
China Software Development Lab
IBM
[jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[
http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705 ]
Vladimir Strigun commented on HARMONY-40:
-
Forced close of file current file channel in file output stream can be added
(diff for current FileOutputStream)
173a174,177
> if (channel != null) {
> channel.close();
> channel = null;
> }
> FileChannel assotiated with FileOutputStream not closed after closing output
> stream
> ---
>
> Key: HARMONY-40
> URL: http://issues.apache.org/jira/browse/HARMONY-40
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Vladimir Strigun
>
> When I receive FileChannel from file output stream, write something to stream
> and then close it, channel, assotiated with the stream is still open. I'll
> attach unit test for the issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[
http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363701 ]
Vladimir Strigun commented on HARMONY-40:
-
I can't attach testcase, so posting it as a comment:
/* Copyright 2005 The Apache Software Foundation or its licensors, as applicable
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.harmony.tests.java.io;
import java.io.File;
import java.io.FileOutputStream;
import java.nio.channels.FileChannel;
import junit.framework.TestCase;
public class FileOutputStreamTest extends TestCase {
/**
* @tests java.io.FileOutputStream#close()
*/
public void test_close() throws Exception {
File logFile = File.createTempFile("out", "tmp");
logFile.deleteOnExit();
FileOutputStream out = new FileOutputStream(logFile, true);
FileChannel channel = out.getChannel();
out.write(1);
out.close();
assertFalse("Channel is still open", channel.isOpen());
}
}
> FileChannel assotiated with FileOutputStream not closed after closing output
> stream
> ---
>
> Key: HARMONY-40
> URL: http://issues.apache.org/jira/browse/HARMONY-40
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Vladimir Strigun
>
> When I receive FileChannel from file output stream, write something to stream
> and then close it, channel, assotiated with the stream is still open. I'll
> attach unit test for the issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
