allthingssecurity opened a new pull request, #28319:
URL: https://github.com/apache/camel/pull/28319

   # Description
   
   [CAMEL-25846](https://issues.apache.org/jira/browse/CAMEL-25846)
   
   `TahuEdgeProducer` keeps the `TahuEdgeClient` of each Edge Node in a static 
map. A stopped Edge Node producer shut its client down but left it in the map, 
and a Tahu `EdgeClient` cannot run again after `shutdown()` (`run()` returns at 
once). The producer created when the route started again took the shut down 
client from the map: it never connected again, and every message was dropped 
with an ERROR log while the exchange completed. Device producers kept the old 
client too.
   
   Changes:
   - `TahuEdgeNodeProducer.doStop`: after the shutdown, remove the client from 
the map and shut down its executor. `doStart`: create a new client when the map 
has none.
   - A new client gets the metric maps of the Edge Node and of its Devices 
again. A producer keeps its metric map in a static map by descriptor from its 
start to its stop, so nothing is kept for producers that stopped (a new 
CamelContext in the same JVM does not get the maps of an old one), and a 
producer that starts after its Edge Node got a new client adds its map to that 
client. Producers to the same endpoint share its map, so the map is counted and 
stays while one of them runs.
   - Device producers take the current client of their Edge Node when they 
publish; they never create one in that case.
   - `TahuEdgeClient.getClientExecutorService()`: the executor of the client, 
so that it can be shut down with it.
   
   No option changed, so no upgrade guide entry.
   
   Tests:
   - New `TahuEdgeProducerRestartTest` (3 tests) with `FakeMqttBroker`, a small 
in-process MQTT 3.1.1 broker that acknowledges connections, subscriptions and 
publishes and records the published topics. The real Tahu client connects to 
it. Restarting the Edge Node route (and, in the second test, only that route 
while a Device route keeps running) must lead to a new NBIRTH/DBIRTH and to the 
next NDATA/DDATA. The waits use Awaitility (20 seconds). Without the change 
both fail (`ConditionTimeoutException ... not published; connects: 1, 
published: [... NBIRTH ..., ... NDATA ..., ... DDEATH ..., ... NDEATH ...]`); 
with the change both pass.
   - 
`deviceStillBornAfterTheEdgeNodeRestartWhenOneOfTwoProducersOfTheDeviceStopped` 
(found in review): two routes send to the same Device endpoint, so their 
producers share its metric map; one of them stops, then the Edge Node route is 
restarted. The new client must still have the Device's metric map, so the 
Device is born again (DBIRTH) and its data published. Without the per-map count 
(the stopped producer removed the shared map) it fails with 
`ConditionTimeoutException ... not published` waiting for the second DBIRTH. 
With the change it passes.
   - camel-tahu unit tests with the change: 10 run, 0 failures.
   
   How it was found: variant analysis of CAMEL-25838 (a client that is shut 
down or replaced while state that belongs to it is kept or lost), then the 
JUnit tests.
   
   What was not run: a real MQTT broker (the IT tests need a container); the 
full root build.
   
   # 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): 
[CAMEL-25846](https://issues.apache.org/jira/browse/CAMEL-25846).
   
   # 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-tahu. No option changed. 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]

Reply via email to