Hi Geert, it is a bug. You can try as a workaround to set the threshold (streamCachingStrategy.setSpoolThreshold(huge_number);) to a huge number; then the body will be kept in memory.
Alternatively, you can modify the code of the Camel class org.apache.camel.processor.WireTapProcessor. You have to modifiy the method configureCopyExchange in the following way: private Exchange configureCopyExchange(Exchange exchange) throws IOException { // must use a copy as we dont want it to cause side effects of the original exchange Exchange copy = ExchangeHelper.createCorrelatedCopy(exchange, false); if (copy.getIn().getBody() instanceof FileInputStreamCache) { //the file stream must be copied, otherwise you get errors because the stream file is removed when the parent route is finished FileInputStreamCache streamCache = (FileInputStreamCache) exchange.getIn().getBody(); CachedOutputStream cos = new CachedOutputStream(copy); try { IOHelper.copy(streamCache, cos); } finally { IOHelper.close(streamCache, cos); streamCache.reset(); } copy.getIn().setBody(cos.newStreamCache()); } // set MEP to InOnly as this wire tap is a fire and forget copy.setPattern(ExchangePattern.InOnly); return copy; } The idea behind this is to make a copy of the stream cache file, so that you get an additional stream cache file for the second route (in your case for the route "direct:x"). This second stream cache file will be deleted when the second route is finished. I also hope that this issue will be fixed. I am no committer so I cannot say when this issue will be solved; I have made contributions which solved a similar problem in the aggregator and splitter. I think you can open a Jira ticket with the above solution suggestion. Regards Franz On Tue, Apr 21, 2015 at 11:13 AM, Geert Vanheusden <geer...@aviovision.com> wrote: > Hi Franz, > > is this something that will be fixed in an upcoming release? Is it a bug or > does it work as designed? > Can we use a workaround to avoid this behaviour, for example by not > deleting the temp files? > > > Kind regards, > > Geert > > On Tue, Apr 21, 2015 at 10:37 AM, Franz Paul Forsthofer < > emc2...@googlemail.com> wrote: > >> Hello Geert, >> >> there is no solution yet for your problem. Currently the stream cache >> file is removed at the end of the route which created the file. In >> your case the stream cache file is deleted when the "direct:start" >> route is finished. The wire tap runs in a separate thread and >> therefore it can happen that it tries to read the cached file when it >> is already deleted, especially when you have a delay in the wiretap >> route ("direct:x"). >> >> >> Regards Franz >> >> On Fri, Apr 17, 2015 at 6:05 PM, Geert Vanheusden >> <geer...@aviovision.com> wrote: >> > Hi, >> > >> > I noticed a bug where the body (StreamCache) was already removed before >> the >> > exchange reached the end (in the Wiretap route). >> > >> > I found the following ticket >> > https://issues.apache.org/jira/browse/CAMEL-8386 and code >> > >> https://fisheye6.atlassian.com/changelog/camel-git?cs=4661cbb94513d6047e58581b23dcd4a6fad166f7 >> > but I think it still doesn't fix the Wiretap problem. >> > >> > Here you can find my test (executed on 2.15.1). If you disable the >> > StreamCaching or remove the delay it works, enabling it again will break >> > the test. >> > >> > ============ >> > import org.apache.camel.builder.RouteBuilder; >> > import org.apache.camel.component.mock.MockEndpoint; >> > import org.apache.camel.impl.DefaultStreamCachingStrategy; >> > import org.apache.camel.spi.StreamCachingStrategy; >> > import org.apache.camel.test.junit4.CamelTestSupport; >> > import org.junit.Before; >> > import org.junit.Test; >> > >> > public class WireTapTest extends CamelTestSupport { >> > >> > private MockEndpoint y; >> > private MockEndpoint z; >> > >> > @Before >> > public void prepareEndpoints() { >> > y = getMockEndpoint("mock:file:y"); >> > z = getMockEndpoint("mock:file:z"); >> > } >> > >> > @Test >> > public void >> > >> testSendingAMessageUsingWiretapShouldNotDeleteStreamBeforeWiretappedExcangeIsComplete() >> > throws InterruptedException { >> > y.expectedMessageCount(1); >> > z.expectedMessageCount(1); >> > >> > // test.txt should contain more than one character >> > template.sendBody("direct:start", >> > this.getClass().getResourceAsStream("/test.txt")); >> > >> > assertMockEndpointsSatisfied(); >> > } >> > >> > @Override >> > protected RouteBuilder createRouteBuilder() throws Exception { >> > return new RouteBuilder() { >> > @Override >> > public void configure() throws Exception { >> > StreamCachingStrategy streamCachingStrategy = new >> > DefaultStreamCachingStrategy(); >> > streamCachingStrategy.setSpoolThreshold(1); >> > context.setStreamCachingStrategy(streamCachingStrategy); >> > context.setStreamCaching(true); >> > >> > from("direct:start") >> > .wireTap("direct:x") >> > .to("file:y"); >> > >> > from("direct:x") >> > .delay(2000) >> > .to("file:z"); >> > } >> > }; >> > } >> > >> > @Override >> > public String isMockEndpoints() { >> > return "(file:z|file:y)"; >> > } >> > } >> > ============= >> > >> > If you run the test you can clearly see the temp file deletion followed >> by >> > the closed stream exception: >> > >> > Tried 1 to delete file: >> > >> /var/folders/db/brq60fqj4vb8mnx_5nlz36nw0000gn/T/camel/camel-tmp-00cd1ce2-7d44-47fe-b357-008e8146f770/cos8797132745923044996.tmp >> > with result: true >> > >> > Cannot reset stream from file >> > >> /var/folders/db/brq60fqj4vb8mnx_5nlz36nw0000gn/T/camel/camel-tmp-00cd1ce2-7d44-47fe-b357-008e8146f770/cos8797132745923044996.tmp >> > >> > I encountered the same issue during a more complex route that does some >> > splitting (zip file) and multicasting. This occurred on Camel 2.14.1 so >> it >> > could be fixed by https://issues.apache.org/jira/browse/CAMEL-8284 but I >> > need to test this. >> > >> > Kind regards, >> > >> > Geert >>