db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yun Lee (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-3941) Unsafe use of DataInput.skipBytes() in StoredPage and StoredFieldHeader
Date Tue, 31 Mar 2009 14:41:17 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694125#action_12694125
] 

Yun Lee edited comment on DERBY-3941 at 3/31/09 7:39 AM:
---------------------------------------------------------

Knut, thanks for your advice! 

>My preferred solution would be to have a variant of org.apache.derby.iapi.services.io.InputStreamUtil.skipFully()
that could take a DataInput argument. That method uses skip until 0 is returned, then it uses
read() which is guaranteed to block until there is something to read. If read returns -1,
an EOFException is thrown. Currently skipFully() is only implemented for InputStream, I think.


With the util, the problem can be resolved easily. I just doubt, skipPersistent() used in
InputStreamUtil.skipFully() will cause a new problem on time efficiency, as it's possible
to wait a long time for the block finishing.

>I'm not sure I understand your question about *ImageReader and BlockDataInputStream. Those
classes are part of the JDK, aren't they? I didn't find any references to them in the Derby
code.

I'm sorry to have seen the two classes in a careless look at 'call hierachy' window in Eclipse,
:).

I will post a patch on this weekend.

Yun

      was (Author: yunlee):
    Knut, thanks for your advice! 

>My preferred solution would be to have a variant of org.apache.derby.iapi.services.io.InputStreamUtil.skipFully()
that could take a DataInput argument. That method uses skip until 0 is returned, then it uses
read() which is guaranteed to block until there is something to read. If read returns -1,
an EOFException is thrown. Currently skipFully() is only implemented for InputStream, I think.

With the util, the problem can be resolved easily. I just doubt, skipPersistent() used in
InputStreamUtil.skipFully() will cause a new problem on time efficiency, as it's possible
to wait a long time for the block finishing.

>I'm not sure I understand your question about *ImageReader and BlockDataInputStream. Those
classes are part of the JDK, aren't they? I didn't find any references to them in the Derby
code.
I'm sorry to have seen the two classes in a careless look at 'call hierachy' window in Eclipse,
:).

I will post a patch on this weekend.

Yun
  
> Unsafe use of DataInput.skipBytes() in StoredPage and StoredFieldHeader
> -----------------------------------------------------------------------
>
>                 Key: DERBY-3941
>                 URL: https://issues.apache.org/jira/browse/DERBY-3941
>             Project: Derby
>          Issue Type: Bug
>          Components: Newcomer, Store
>            Reporter: Knut Anders Hatlen
>            Assignee: Yun Lee
>            Priority: Minor
>
> Some methods in StoredFileHeader and StoredPage call java.io.DataInput.skipBytes(int)
with the assumption that it always skips the requested number of bytes. According to the javadoc
for skipBytes, it may skip fewer bytes than requested, possibly 0, even if the end of the
stream hasn't been reached.
> The problem exists in these methods:
>   StoredFieldHeader.readFieldDataLength()
>   StoredPage.readRecordFromStream()
>   StoredPage.skipField()
>   StoredPage.readOneColumnFromPage()
>   StoredPage.readRecordFromArray()
> We should change the code so that it works correctly even if skipBytes() were to skip
fewer bytes than requested.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message