[
https://issues.apache.org/jira/browse/CAMEL-25711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-25711 started by shashank.
----------------------------------------
> camel-mongodb-gridfs - the consumer stops polling for good, without a log
> line and with the route still started, after one poll fails (for example
> MongoDB not reachable for longer than the server selection timeout)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25711
> URL: https://issues.apache.org/jira/browse/CAMEL-25711
> Project: Camel
> Issue Type: Bug
> Components: camel-mongodb-gridfs
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> {{GridFsConsumer}} polls with a {{BackgroundTask}} built
> {{withUnlimitedDuration()}} ({{GridFsConsumer.run}}, main 18f53efde6c7
> {{GridFsConsumer.java}} 124-139). Only {{getProcessor().process(exchange)}}
> is inside a {{try}} in {{processCollection}}; the query of the bucket
> ({{getGridFSFileMongoCursor}}, 151), {{cursor.hasNext()}} / {{next()}}, the
> {{findOneAndUpdate}} that marks a file {{processing}} for the file attribute
> strategies (162), {{openDownloadStream}} (166) and the update of the
> persistent timestamp (202) are not. When one of them throws, for example a
> {{MongoTimeoutException}} because MongoDB cannot be reached for longer than
> the server selection timeout (30 s by default) or a
> {{MongoSocketReadException}} when the connection drops while the cursor
> reads, the exception leaves the supplier. {{BackgroundTask.runTaskWrapper}}
> marks the task failed, releases {{run()}} (CAMEL-24286) and rethrows on the
> scheduler thread, so {{scheduleWithFixedDelay}} never runs the task again.
> The consumer then stays started and routes nothing until the route is
> restarted. Nothing is logged: the exception ends in the {{Future}} of the
> scheduled task. This happens with every query strategy, with the default
> options.
> With {{queryStrategy=PersistentTimestamp}} or
> {{PersistentTimestampAndFileAttribute}} there is a second path: {{run()}}
> reads the persistent timestamp collection (105-119) on the consumer's
> executor thread before it schedules the polls. If MongoDB cannot be reached
> when the route starts, {{run()}} throws and no poll is ever scheduled.
> h3. Reproduction
> Two new tests in {{GridFsConsumerTimestampTest}} use the fake bucket of that
> class (Mockito, no MongoDB):
> * {{consumerKeepsPollingAfterAFailedPoll}}, once for each of the 5 query
> strategies: the first 2 queries of the bucket throw
> {{MongoTimeoutException}}, then a file is stored. On main the consumer never
> polls again ({{the consumer did not poll 3 times}}) and the file is never
> routed.
> *
> {{persistentTimestampStrategyKeepsPollingWhenTheTimestampCannotBeReadAtStart}}:
> the first read of the timestamp collection throws. On main no poll runs.
> On main all 6 cases fail; with the fix they pass.
> h3. Proposed fix
> The supplier of the task calls a new {{poll}} method that catches the
> exception, reports the first failure of a run of failures through the
> consumer's {{ExceptionHandler}} (WARN with the stack trace by default; the
> next ones at DEBUG, as the polls run every {{delay}}, 500 ms by default; one
> INFO line when a poll works again), and returns {{false}}. The next poll then
> tries again after {{delay}}. {{camel-mongodb}} also catches the exception of
> a poll and goes on in its consumer thread
> ({{MongoAbstractConsumerThread.java}} 103-110 on main, CAMEL-16025); it logs
> every failure at WARN with the stack trace, this change reports only the
> first of a run of failures because the polls repeat every {{delay}}. The
> persistent timestamp is read by the first poll that can reach MongoDB instead
> of by {{run()}}, so a failure there is retried in the same way. No option or
> default changes.
> Not changed: a file claimed with the {{processing}} attribute (file attribute
> strategies) before the poll fails still keeps that attribute, as before.
> How it was found: CAMEL-24286 names this path in its description, but its fix
> changed only {{BackgroundTask}}, and {{run()}} now returns while the poller
> stays dead. The camel-mongodb consumer had the same "consumer thread ends on
> a server outage" defect (CAMEL-25679). The tests confirmed it.
> Affected: main (18f53efde6c7; tested). camel-4.23.x and camel-4.22.x poll
> with the same {{BackgroundTask}} and have the same uncaught calls and the
> same timestamp read in {{run()}} (read, not run). camel-4.18.x and
> camel-4.14.x have the same uncaught calls, but {{run()}} polls with a
> {{ForegroundTask}} there: the exception leaves {{run()}} and ends the
> consumer thread, with the same result (only the default handler of the thread
> prints it on stderr) (read, not run).
> Duplicate check (2026-10-16): JIRA text "gridfs consumer", "GridFsConsumer",
> "gridfs polling stops" (CAMEL-25607, CAMEL-24905, CAMEL-24272, CAMEL-24286,
> CAMEL-23577, CAMEL-17121: CAMEL-24286 describes the path but fixed only
> BackgroundTask; none about the consumer staying stopped); GitHub pull
> requests "gridfs", "GridFsConsumer" (#27794, #26787, #25217, #25164: none
> about this).
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
