etzel-mes opened a new pull request, #28556:
URL: https://github.com/apache/camel/pull/28556
# Description
Follow-up of CAMEL-25617 (#28387), JIRA: CAMEL-26339. This implements the
first two directions of the ticket.
**Failed polls.** The triggered consumer still fails every poll that cannot
read the PLC, so the consumer health check, `bridgeErrorHandler` and a custom
`exceptionHandler` see each failure as before. What changes is the consumer's
default exception handler, which the consumer now sets itself, as
`NettyConsumer` does with `NettyConsumerExceptionHandler`:
- the first failed poll of a run is logged at WARN with the stack trace, as
before;
- the following ones are logged at DEBUG with the message only, as
`GridFsConsumer` does since CAMEL-25711;
- the first poll that reads the PLC again logs one INFO line with the number
of failed polls.
A configured `exceptionHandler` or `bridgeErrorHandler=true` still replaces
this handler.
**`autoReconnect=false`.** `Plc4XEndpoint.reconnectIfNeeded()` logs
"Connection lost and auto-reconnect is turned off, shutting down Plc4XEndpoint"
and stops the endpoint once per lost connection, instead of on every call, and
not at all when no connection could be set up. So the producer and the polling
consumer, which share it, fail their exchanges without repeating the warning.
Once the endpoint has shut the lost connection down, the triggered consumer
fails that poll and stops polling with `getScheduler().unscheduleTask()`, as
`repeatCount` does. That failure is logged at WARN even within a run, and
restarting the route starts polling again. Unscheduling from the poll
interrupts the polling thread, so the consumer clears that interrupt before the
failure is reported.
**What PLC4X still logs.** With `autoReconnect=true`, every poll during an
outage still tries to connect. PLC4X's TCP transport logs each failed attempt
at ERROR with the stack trace and then throws the same failure to Camel
(`TcpTransportInstance`, lines 136–141 in 1.0.0, unchanged on `develop`).
`DriverBase` also logs an INFO line ("Using connection string") for each
attempt. In the live run below, a 10 s outage at `period=100` gave 97 of those
ERROR lines, each with about 24 stack frames. Camel already reports the
failure, so a logger level for
`org.apache.plc4x.java.transport.tcp.TcpTransportInstance` can silence them. I
did not find a Camel-side way to handle this that I would prefer, so
suggestions are welcome.
**Not included: the backoff options** (the third direction). They would also
thin out the PLC4X lines above, since there would be fewer connect attempts
during an outage, at the price of noticing the PLC's return later. But they
need new endpoint options. Making `Plc4XEndpoint` a `ScheduledPollEndpoint`
brings all scheduler options to every plc4x endpoint, including `delay` next to
the existing `period`. Some of those options do not fit a trigger:
- `backoffIdleThreshold` counts every poll without a rising edge as idle, so
it thins out the polls and short trigger pulses can be missed;
- `sendEmptyMessageWhenIdle` sends an empty exchange on every such poll.
Declaring just `backoffErrorThreshold` and `backoffMultiplier` on the
endpoint would fit, but I found no other component that does it that way. So I
left them out; if you would rather have those two options now, I can add them
to this PR.
**Verification.** Module build only (`mvn install -Psourcecheck` in
`components/camel-plc4x`; the root build was not run). The module's 43 tests
were green in three consecutive runs with
`-Dsurefire.rerunFailingTestsCount=0`. The new route tests fail on the code
before the change, except the one that checks that `bridgeErrorHandler` still
gets every failure, which passes before and after. There are no generated
changes, and the catalog copy of the component doc is byte-identical.
The live check ran against the snap7 1.4.2 S7 server: a triggered consumer
with `period=100` ran for 30 s, the server was stopped after 10 s and started
again 10 s later, with the camel-plc4x jar from before and after this change:
| 10 s outage, `period=100` | before | after |
|---|---|---|
| `autoReconnect=true`: "Failed polling endpoint" at WARN with stack trace |
95 | 1 |
| `autoReconnect=true`: the same at DEBUG, message only | – | 97 |
| `autoReconnect=true`: INFO when a poll succeeds again | – | 1 ("after 98
failed polls") |
| `autoReconnect=true`: PLC4X `TcpTransportInstance` ERROR with stack trace
| 95 | 97 |
| `autoReconnect=false`: "Failed polling endpoint" at WARN | 194 | 1 |
| `autoReconnect=false`: "Connection lost ... shutting down Plc4XEndpoint" |
194 | 1 |
| `autoReconnect=false`: failed polls | 194, until the run ended | 1, then
polling stopped |
@davsclaus could you have a look? (I cannot request reviewers.)
# 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.
# 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.
The code, tests and documentation were written with Claude Code (Claude Opus
5.5) under my direction; every commit carries the `Co-Authored-By` trailer.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
_Claude Code on behalf of etzel-mes_
--
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]
