[
https://issues.apache.org/jira/browse/DERBY-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802732#action_12802732
]
Kristian Waagan commented on DERBY-4519:
----------------------------------------
Hi Knut,
I think we can address the additional problem you spotted here as well. The
question is which thresholds to use.
Assuming available() will give reasonable answers in most cases (may very well
be the case if we are reading from internal store streams), which limits should
we impose on the buffer size?
[64, 8192], which could look like something like this?
(BufferedInputStream uses 8 KB as default buffer size)
int bufferLen = Math.min(Math.max(in.available(), 64), 8192).
Based on the experiences from DERBY-3791, I would be careful about defaulting
to a largish size if we do get reasonable answers from available().
> Infinite loop in StreamFileContainer.writeColumn
> ------------------------------------------------
>
> Key: DERBY-4519
> URL: https://issues.apache.org/jira/browse/DERBY-4519
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.0.2.1, 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0,
> 10.5.3.0, 10.6.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.6.0.0
>
> Attachments: derby-4519-1a-argument_swap.diff
>
>
> The offset and length argument have been swapped in the calls to
> InputStream.read(byte,offset, length) and write(byte,offset, length). This
> code is inside a do-while (true) loop, and the only normal way out is when
> InputStream.read returns -1. This will never happen since the stream is asked
> to read zero bytes. Derby ends up eating up all available CPU, limited to a
> single core / CPU.
> The bug hasn't been observed because Derby is materializing all values when
> calling this code. Enabling streaming capabilities in the sorter revealed it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
