[
https://issues.apache.org/jira/browse/OAK-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493161#comment-13493161
]
Thomas Mueller commented on OAK-430:
------------------------------------
Same as InputStream.read() and MicroKernel.read(..), the method readBlob(..)
method returns the length actually read. In this case it only reads 80 bytes
(the stored binary), and returns 80. So I would say it is not a bug, even
thought it's not the most optimal solution (the client has to call the read()
method again).
Is it OK if I close the bug for now? But I'm for changing the logic if turns
out to be a performance problem.
> Incorrect read logic in AbstractBlobStore
> -----------------------------------------
>
> Key: OAK-430
> URL: https://issues.apache.org/jira/browse/OAK-430
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
> Reporter: Mete Atamel
> Assignee: Thomas Mueller
> Priority: Minor
> Attachments: diff.txt
>
>
> AbstractBlobStore has incorrect read logic that manifests itself in this
> scenario:
> -Set block size to 80 and min block size to something less than 80 (eg. 48)
> -Write a blob of length 81
> -Try to read blob of length 81
> At this point, you get a blob of length 81 but the last byte in the array is
> zero (i.e. the last byte is not read correctly). I think this is because in
> blob write, first 80 bytes are written as a block and then the last byte is
> inlined since it's less than 48. This is all fine but while reading the blob,
> after reading the first 80 bytes from the block, 1 byte is forgotten.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
