You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Stephan Siano (JIRA)" <ji...@apache.org> on 2013/12/20 13:28:10 UTC

[jira] [Commented] (CAMEL-7087) StreamCache does not reset at the end of the pipeline

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