[jira] [Updated] (CAMEL-25711) 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)

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-25711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-25711:
--------------------------------
    Fix Version/s: 4.24.0

> 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
>             Fix For: 4.24.0
>
>
> {{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)