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