etzel-mes commented on PR #28212: URL: https://github.com/apache/camel/pull/28212#issuecomment-6310782813
Thanks for the review, Claus. c92824359d3 addresses B, C and D and adds the javadoc for A; the reasoning for A is in its thread. 1. I agree, and I would put them in the dev console rather than in a health check. A refused node is a problem of that one node, usually its configuration, and a health check that goes down for it would mark the whole application unhealthy, for example take it out of service, without fixing the node. A `milo-client` dev console that lists each connection with its session state and its refused nodes, with the latest status of each, would answer it. If you agree, I will open a JIRA for it as a follow-up. 2. Yes, that is intended. An attempt that fails does not change the nodes: they stay refused and were reported once, and the monitored nodes are not affected. Rebuilding the connection would interrupt the monitored nodes and send the same request again, and a WARN every 10 seconds would repeat itself for as long as the server answers that way. You are right that the failure of the attempt itself is not shown above DEBUG, only the refusal of the node was; I would show it in the dev console from question 1, as the latest status of each refused node. For the two examples: Milo already answers `Bad_TooManyOperations` itself by sending the items again one per call, so it only reaches us for a single item, and `Bad_ServiceUnsupported` would mean a server without the MonitoredItem services, which fails the registration of any node already. A lost subscription or session is recovered as before, and the next attempt goes to the recovered subscription. _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]
