[
https://issues.apache.org/jira/browse/CAMEL-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841221#comment-16841221
]
Volker Althaus commented on CAMEL-13532:
----------------------------------------
The test case in in the provided attached Zip file. It's a simple Maven project
with a JUnit test. You eventually have to adapt the local path to the processed
file.
I have to correct myself - the breaking change was between 2.20.4 and 2.21.0.
It looks like there was a fundamental refactoring around the FileConsumer (like
the introduction of GenericFileConsumer where I suspect the bug)
> file2: pollEnrich with sendEmptyMessageWhenIdle does not send correct
> Exchanges
> -------------------------------------------------------------------------------
>
> Key: CAMEL-13532
> URL: https://issues.apache.org/jira/browse/CAMEL-13532
> Project: Camel
> Issue Type: Bug
> Components: came-core
> Affects Versions: 2.20.4, 2.21.5, 2.22.3, 2.23.2, 2.24.0
> Reporter: Volker Althaus
> Priority: Major
> Attachments: camel-fileconsumer-bug.log, camel-fileconsumer-bug.zip
>
>
> I use the file component in pollEnrich with sendEmptyMessageWhenIdle=true and
> readLock=changed
> In 2.20.4 and before the attached test case worked, from 2.21.0 on it fails.
> My test writes several characters delayed into a file so that the component
> runs into a timeout after 10000ms on the first call. This is correct.
> On the second call the writing of the file is finished within the 10000ms, my
> expectation is the correct processing of the file in my route, but it fails
> because the Exchange has an empty body.
> I debugged the thing an saw that in the variable
> GenericFilePollingConsumer.queue there are two exchanges instead of one. The
> first one sems to be the "empty" message from the first call without a
> GenericFile in the In-Body, and the second Exchange in the queue is the
> correct one with the GenericFile from the second call.
> Because it's a FiFo, only the first, empty one is returned (in
> EventDrivenPollingConsumer.receive()) so that the route states that there is
> nothing to do.
> I suspect an error in the processing of the empty message, so that it is not
> cleared or taken properly from the queue so that it remains there and
> conflicts with later calls.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
