[
https://issues.apache.org/activemq/browse/CAMEL-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58997#action_58997
]
Willem Jiang commented on CAMEL-2496:
-------------------------------------
After digging the code, I found the FileInputStreamCache is closed when the
XPathBuilder.getDocument() is called, and the temp file is deleted, so you get
the FileNotFoundException when the XPathBuilder wants to reset the InputStream.
I can also reproduce this issue in Camel 2.x.
To work around this issue, we should not use the FileInputStreamCache as it
can't be reset after it is closed.
> StreamCache/Splitter race condition
> -----------------------------------
>
> Key: CAMEL-2496
> URL: https://issues.apache.org/activemq/browse/CAMEL-2496
> Project: Apache Camel
> Issue Type: Bug
> Affects Versions: 1.6.2
> Reporter: Stan Lewis
> Attachments: test-case.txt
>
>
> Attached patch introduces a test that shows the following symptom:
> org.apache.camel.RuntimeCamelException: java.io.FileNotFoundException:
> /var/folders/vC/vCA487MkHEeSaIu9LmlkrU+++TI/-Tmp-/camel-tmp-627613/cos3755307044377901165.tmp
> (No such file or directory)
> org.apache.camel.RuntimeCamelException: java.io.FileNotFoundException:
> /var/folders/vC/vCA487MkHEeSaIu9LmlkrU+++TI/-Tmp-/camel-tmp-627613/cos3755307044377901165.tmp
> (No such file or directory)
> at
> org.apache.camel.converter.stream.FileInputStreamCache.reset(FileInputStreamCache.java:52)
> at
> org.apache.camel.converter.stream.StreamCacheConverter$StreamSourceCache.reset(StreamCacheConverter.java:126)
> at
> org.apache.camel.util.MessageHelper.resetStreamCache(MessageHelper.java:105)
> at
> org.apache.camel.builder.xml.XPathBuilder.getDocument(XPathBuilder.java:548)
> at
> org.apache.camel.builder.xml.XPathBuilder.evaluateAs(XPathBuilder.java:428)
> at
> org.apache.camel.builder.xml.XPathBuilder.evaluate(XPathBuilder.java:118)
> at
> org.apache.camel.processor.Splitter.createProcessorExchangePairs(Splitter.java:72)
> at
> org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:155)
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:80)
> at
> org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.java:189)
> at
> org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.java:133)
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:68)
> at
> org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(StreamCachingInterceptor.java:87)
> at
> org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:82)
> at
> org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:52)
> at
> org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:72)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:637)
> I believe it must be a race condition when several threads are passing
> through the splitter, in the above case I'm using a seda queue with 5
> threads. Am logging this now as I'm not sure what time I'll have to
> investigate further this week.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
