You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Yun Lee (JIRA)" <ji...@apache.org> on 2009/03/31 16:41:17 UTC

[jira] Issue Comment Edited: (DERBY-3941) Unsafe use of DataInput.skipBytes() in StoredPage and StoredFieldHeader

    [ 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.