You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Vladimir Strigun (JIRA)" <ji...@apache.org> on 2006/01/23 19:14:28 UTC
[jira] Created: (HARMONY-40) FileChannel assotiated with
FileOutputStream not closed after closing output stream
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] Assigned: (HARMONY-40) FileChannel assotiated with
FileOutputStream not closed after closing output stream
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-40?page=all ]
Tim Ellison reassigned HARMONY-40:
----------------------------------
Assign To: Tim Ellison
> 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
Posted by "Vladimir Strigun (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (HARMONY-40) FileChannel assotiated with
FileOutputStream not closed after closing output stream
Posted by "Vladimir Strigun (JIRA)" <ji...@apache.org>.
[ 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
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream
not closed after closing output stream
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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.
>>>> <code>
>>>> .....
>>>> FileChannel channel = null;
>>>> try{
>>>> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
>>>> channel = fos.getChannel();
>>>> }catch(Exception e){
>>>> }
>>>> /*continue operate on channel*/
>>>> .....
>>>> </code>
>>>>
>>>> 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
Posted by Paulex Yang <pa...@gmail.com>.
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.
>>>> <code>
>>>> .....
>>>> FileChannel channel = null;
>>>> try{
>>>> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
>>>> channel = fos.getChannel();
>>>> }catch(Exception e){
>>>> }
>>>> /*continue operate on channel*/
>>>> .....
>>>> </code>
>>>>
>>>> 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
Posted by Tim Ellison <t....@gmail.com>.
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.
>>> <code>
>>> .....
>>> FileChannel channel = null;
>>> try{
>>> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
>>> channel = fos.getChannel();
>>> }catch(Exception e){
>>> }
>>> /*continue operate on channel*/
>>> .....
>>> </code>
>>>
>>> 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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream
not closed after closing output stream
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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.
>> <code>
>> .....
>> FileChannel channel = null;
>> try{
>> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
>> channel = fos.getChannel();
>> }catch(Exception e){
>> }
>> /*continue operate on channel*/
>> .....
>> </code>
>>
>> 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
Posted by Tim Ellison <t....@gmail.com>.
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.
> <code>
> .....
> FileChannel channel = null;
> try{
> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
> channel = fos.getChannel();
> }catch(Exception e){
> }
> /*continue operate on channel*/
> .....
> </code>
>
> 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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
Posted by Rodrigo Kumpera <ku...@gmail.com>.
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 <ku...@gmail.com> wrote:
> On 1/25/06, Paulex Yang <pa...@gmail.com> 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 <pa...@gmail.com> 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.
> > >> <code>
> > >> .....
> > >> FileChannel channel = null;
> > >> try{
> > >> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
> > >> channel = fos.getChannel();
> > >> }catch(Exception e){
> > >> }
> > >> /*continue operate on channel*/
> > >> .....
> > >> </code>
> > >>
> > >> 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
Posted by Rodrigo Kumpera <ku...@gmail.com>.
On 1/25/06, Paulex Yang <pa...@gmail.com> 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 <pa...@gmail.com> 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.
> >> <code>
> >> .....
> >> FileChannel channel = null;
> >> try{
> >> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
> >> channel = fos.getChannel();
> >> }catch(Exception e){
> >> }
> >> /*continue operate on channel*/
> >> .....
> >> </code>
> >>
> >> 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
Posted by Paulex Yang <pa...@gmail.com>.
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 <pa...@gmail.com> 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.
>> <code>
>> .....
>> FileChannel channel = null;
>> try{
>> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
>> channel = fos.getChannel();
>> }catch(Exception e){
>> }
>> /*continue operate on channel*/
>> .....
>> </code>
>>
>> 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
Posted by Rodrigo Kumpera <ku...@gmail.com>.
Aren't channels supposed to hold references to the original streams?
On 1/24/06, Paulex Yang <pa...@gmail.com> 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.
> <code>
> .....
> FileChannel channel = null;
> try{
> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
> channel = fos.getChannel();
> }catch(Exception e){
> }
> /*continue operate on channel*/
> .....
> </code>
>
> 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
Posted by Paulex Yang <pa...@gmail.com>.
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.
<code>
.....
FileChannel channel = null;
try{
FileOutputStream fos = new FileOutputStream("somefile.txt", false);
channel = fos.getChannel();
}catch(Exception e){
}
/*continue operate on channel*/
.....
</code>
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
Posted by "Vladimir Strigun (JIRA)" <ji...@apache.org>.
[ 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] Closed: (HARMONY-40) FileChannel assotiated with
FileOutputStream not closed after closing output stream
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-40?page=all ]
Tim Ellison closed HARMONY-40:
------------------------------
> 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] Resolved: (HARMONY-40) FileChannel assotiated with
FileOutputStream not closed after closing output stream
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-40?page=all ]
Tim Ellison resolved HARMONY-40:
--------------------------------
Resolution: Cannot Reproduce
Vladimir,
As you say, the bug cannot be reproduced, it has been fixed by HARMONY-42.
I've added the regression test to NIO module at repo revision 380839.
Please confirm that the problem is fixed for you.
> 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
Posted by "Paulex Yang (JIRA)" <ji...@apache.org>.
[ 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;)
<quote>
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.
<code>
.....
FileChannel channel = null;
try{
FileOutputStream fos = new FileOutputStream("somefile.txt", false);
channel = fos.getChannel();
}catch(Exception e){
}
/*continue operate on channel*/
.....
</code>
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.
</quote>
> 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
Posted by "Vladimir Strigun (JIRA)" <ji...@apache.org>.
[ 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