[
https://issues.apache.org/jira/browse/CAMEL-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325976#comment-14325976
]
Claus Ibsen commented on CAMEL-8284:
------------------------------------
org.apache.camel.converter.stream.ByteArrayInputStreamCache#copy
Would have been lovely if there was a way for byte array input streams to not
need to copy the byte[] but reuse the same instance to avoid 2x the memory
usage.
But seems like buf[] is protected in the jdk api, and no api to access it.
Also I think we should add the copy method directly to StreamCache so its out
of the box. There is to many interfaces already in Camel.
> MultiCast in Parallel Processing Mode with StreamCache leads to wrong results
> -----------------------------------------------------------------------------
>
> Key: CAMEL-8284
> URL: https://issues.apache.org/jira/browse/CAMEL-8284
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.14.1
> Reporter: Franz Forsthofer
> Assignee: Claus Ibsen
> Fix For: 2.15.0
>
> Attachments:
> 0001-CAMEL-8284-Implement-copy-method-in-NettyChannelBuff.patch,
> 0001-multicast-with-parallel-processing-and-stream-cachin.patch,
> 0001-parallel-processable-stream.patch
>
>
> If the multi-cast processor gets as an input a stream cache in the parallel
> processing mode, then the stream is read by different threads concurrently.
> This leads to wrong results.
> The attached patch solves this issue. The idea of the patch is to provide a
> copy of the stream cache to each thread. The copy will use the same cache of
> the original stream cache, only the stream which accesses the cached data
> will be a separate instance. For this, we introduced the new method
> copy()
> in the StreamCache class.
> See also discussion in
> http://camel.465427.n5.nabble.com/Data-Corruption-in-SFTP-in-Parallel-Multicast-branches-td5761673.html#a5761781
> Franz Forsthofer
> SAP SE
> e-mail: franz.forsthofer[at]sap.com
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
