allthingssecurity opened a new pull request, #27797: URL: https://github.com/apache/camel/pull/27797
# Description [CAMEL-25610](https://issues.apache.org/jira/browse/CAMEL-25610) `InfluxDb2Producer` wrote with the batching write API of the InfluxDB client (`InfluxDBClient.makeWriteApi()`). The write methods of that API only put the data into a buffer of the client and return; a background thread sends the buffer later (by default after one second or 1000 points) and reports a failed request as an event, which the client logs with `java.util.logging`. The producer does not listen to these events. So, with default options: 1. the exchange completed before InfluxDB had received anything; 2. the `try`/`catch` around each write, which sets a `CamelInfluxDb2Exception` on the exchange, was never reached for a failed write; 3. a write that InfluxDB rejected (a line it cannot parse, an unknown bucket, a token that is not authorized) or that could not be sent (server down) was lost, and the route continued after the producer as if the data had been stored: no failed exchange, no redelivery, no dead letter channel. This change uses the synchronous write API (`InfluxDBClient.getWriteApiBlocking()`). `WriteApiBlocking` has the same six write methods with the same parameters; they return after the answer of InfluxDB and throw `InfluxException` for an error answer or a request that could not be sent. The existing catch blocks set it on the exchange. The change in the producer is the type of the field and the call that creates it. What changes for users (4.24 upgrade guide entry, and a new section in the component documentation): - a failed write fails the exchange with a `CamelInfluxDb2Exception` whose cause is the `InfluxException`; - each exchange is one write request, where the client used to collect the points of up to one second into one request, and the client no longer retries a write in the background. A route with a high message rate can send a `Points`, `Measurements` or `Records` body (for example from an aggregator) to write many points with one request. The cost: one synchronous HTTP request per exchange on the thread of the route, and the background batching and retries of the client no longer apply. I did not measure it. Not changed: there is no option to get the batching API back. With it the outcome of a write cannot be the outcome of the exchange; if somebody needs it, it could be added as an option with a listener for the error events of the client. The `retentionPolicy` option still has no effect, as on main. Tests: - New `InfluxDb2ProducerWriteFailureTest` (8 tests). It uses the real `InfluxDBClient` against a local HTTP server (the JDK `HttpServer`) that plays the organization, bucket and write resources of the InfluxDB 2.x API. A point that the server answers with 400, 401, 404 or 503, a `Records` body answered with 400, and a write to a server that is down must fail the exchange and must not reach the step after the producer; an accepted point must be at the server when the exchange completes, and so must an accepted `Record`, whose write request must carry the organization, the bucket and the precision of the endpoint (`org=myOrg`, `bucket=myBucket`, `precision=ms`). - Without the change (the producer of main, same test) all eight fail: `Unexpected null value, expected: <org.apache.camel.component.influxdb2.CamelInfluxDb2Exception> but was: <null>` for the six failure cases, and for the two accepted writes nothing is at the server when the exchange has completed (`expected: <1> but was: <0>` for the point, `expected: <[temperature,location=north value=60.0]> but was: <[]>` for the record). - With the change, camel-influxdb2 tests pass: 21 run, 0 failures. The existing tests use a mocked client; no InfluxDB server was used. How it was found: a sweep of the producers for failures that never reach the exchange, and a small TLA+ model of the write (exchange, buffer of the client, flush, answer of the server). The model is only a sketch of the code; the test above reproduces it on the real producer and client. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [ ] 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). (The ticket is drafted and not filed yet; CAMEL-25610 is a placeholder until it is.) # 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-influxdb2, including the formatter and import-sort plugins, and copied the changed component page to the catalog. 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]
