[
https://issues.apache.org/jira/browse/CAMEL-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853913#comment-13853913
]
Stephan Siano commented on CAMEL-7087:
--------------------------------------
The root cause is currently the StreamCache is reset only before the executin
of the processor, not afterwards. If the consumer gets the exchange back, a
StreamCache in the in-message will remain as it is and does not close.
My patch also resets the stream cache after each processor. This means normally
the reset() will be executed twice on the stream cache (after the previous
processor and before the next), but a reset() on a StreamCache that was reset
before, will only do a null comparison, so it doesn't cost much. I also
considered to remove the reset before the processors, but I am not sure whether
this doesn't break wiretaps or the like.
> StreamCache does not reset at the end of the pipeline
> -----------------------------------------------------
>
> Key: CAMEL-7087
> URL: https://issues.apache.org/jira/browse/CAMEL-7087
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.12.2
> Reporter: Stephan Siano
> Attachments:
> 0001-CAMEL-7087-StreamCache-does-not-reset-at-the-end-of-.patch
>
>
> The StreamCache does not reset at the end of the pipeline.
> The following routes will not work as expected:
> from("direct:c").noStreamCaching().to("direct:d").to("mock:c");
> from("direct:d").streamCaching().process(new TestProcessor());
> (the test processor is a processor that reads the InputMessage)
> If another processor is added after the TestProcessor that does nothing, the
> routes will work as expected.
> This case is a bit synthetic, but in real life a route that starts with a
> InOut CXF endpoint, has an endpoint that generates a Stream and then writes
> the message content to an in only endpoint (file, FTP, log, etc.) will also
> fail, even if stream caching is enabled.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
