allthingssecurity opened a new pull request, #27693: URL: https://github.com/apache/camel/pull/27693
# Description [CAMEL-25545](https://issues.apache.org/jira/browse/CAMEL-25545) `PgEventConsumer` created one `BackgroundTask` for reconnecting in `doInit` and ran that same task in `reconnect()` for every lost connection. A `BackgroundTask` completes only once: after its first successful attempt the latch is 0, and `run()` then returns at once without calling the task (the scheduled attempt is cancelled before its initial delay, and `runTaskWrapper` is a no-op for a completed task). The other users of the task API (camel-master, camel-sjms, camel-kafka) build a new task for each use. So the consumer reconnected after the first connection loss (the reconnect was added with CAMEL-22146), and after the next one it stayed disconnected: no `LISTEN`, no notifications routed, nothing logged after the "Connection to PostgreSQL lost" warning, and the route still started. A database that restarts twice while the route runs was enough. Now `reconnect()` creates a new task (same pool, name and budget) for each reconnect. The field that holds the current task is volatile, as it is set from the thread of the driver that reports the lost connection. Related: CAMEL-23646 was an earlier fix in this same callback (the `BackgroundTask` callbacks of sjms, pgevent and master); it did not change that one task is used for every reconnect. A stop and start of the same consumer (a route restart) is not affected and needs no change: `BaseService.init()` runs `doInit` again after a stop, so the reconnect pool that `doStop` shuts down is created again. I checked this with a throwaway test (stop, start, `closed()`, then a notification): it passes with and without this change, so it is not part of the PR. There is no upgrade guide note, because nothing changes for a consumer that has not lost its connection twice. Tests: - New `PgEventConsumerReconnectTest`, without a database: a mocked `DataSource` (the `datasource` option) hands out mocked `PGConnection`s, and the test calls `closed()` on the listener as the driver does. After two connection losses the consumer must have opened three connections, and the third must have executed `LISTEN testchannel` and got the notification listener. - Without the change: `The consumer must reconnect after the second connection loss ==> expected: <3> but was: <2>`. - With the change: camel-pgevent 1 unit test (the module had none), 0 failures. The integration tests need a PostgreSQL container and were not run. - `mockito-junit-jupiter` is added as a test dependency of camel-pgevent. Not changed here: a consumer that is stopped while a reconnect is still waiting leaves the calling thread waiting on the task. I can look at that separately. Found by reading how the task API is used across components, with a small TLA+ model of the reconnect: "when reconnect() has returned the consumer listens to the channel" holds for one connection loss and is violated for two; with a new task per reconnect it holds. I then reproduced it with the consumer. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-pgevent, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
