[
https://issues.apache.org/jira/browse/CAMEL-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Althaus updated CAMEL-13532:
-----------------------------------
Description:
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.
was:
I use the file component in pollEnrich with sendEmptyMessageWhenIdle=true and
readLock=changed
In 2.19.x and before the attached test case worked, from 2.20.x 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.
> 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)
