etzel-mes commented on PR #29197: URL: https://github.com/apache/camel/pull/29197#issuecomment-6651907787
We tried this against real OPC UA servers, since CAMEL-25835 and CAMEL-25713 are ours. The fix holds. We built camel-milo at `b40a45f891` and again with only the `SubscriptionManager` change reverted, and ran the route from the JIRA in a container against opc-plc 2.15.4 and node-opcua 2.186.17. A second consumer on the same connection only logged its values, and a timer made awaited writes. Each row is 45 s after the server became reachable. | Case | Without the fix | With the fix | |---|---|---| | 1 CPU, 1 such consumer, opc-plc starts late (2 runs each) | 0 route writes, 0 Good values, 0 timer writes | 37 and 34 route writes, 36 and 33 Good values, 22 and 21 timer writes | | 1 CPU, 1 such consumer, packets to opc-plc silently dropped, then restored | 0, 0, 0 | 36, 35, 22 | | 1 CPU, 1 such consumer, node-opcua starts late | 0, 0, 0 | 43, 42, 21 | | 2 CPUs, 2 such consumers, opc-plc starts late | 0, 0, 0 | 72, 35, 21 | | 2 CPUs, 1 such consumer, opc-plc starts late | 37, 36, 23 (no hang, as the JIRA says) | not run | Stopping the context took about 45 s without the fix and under 0.2 s with it. In every run with the fix the consumer still got its `Bad_NoCommunication` report first, now on `milo-shared-thread-pool-*`, and then Good values. Without the fix the thread dump shows the `MiloClient` thread parked in `DefaultAsyncProcessorAwaitManager.await` under `deliverLoss`, as described. Thanks for finding this one, @allthingssecurity. _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]
