Hi,
You can also use Wiretap's onPrepareRef option and use custom processor to
copy the content of the cached body.
Franz, would you be so kind and create a pull request with your fix?
Somebody will review it and merge. Thanks in advance!
Cheers!
wt., 21.04.2015 o 16:25 użytkownik Franz Paul Forsthofer <
emc2...@googlemail.com> napisał:
> 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
> >>
>
