allthingssecurity opened a new pull request, #29124: URL: https://github.com/apache/camel/pull/29124
## CAMEL-26541: camel-core - interceptSendToEndpoint: an endpoint created while a route starts or stops gets the interceptors of the running routes Since CAMEL-25140 a route registers its `interceptSendToEndpoint` interceptor when it starts and unregisters it when it stops; `register`/`unregister` update the wrapped endpoints in the endpoint registry. A new endpoint (such as a `toD` endpoint) took the interceptors in `registerEndpoint` without the manager lock, and `AbstractCamelContext.addEndpointToRegistry` puts it in the registry only after the endpoint strategies returned. A route that starts or stops between the two steps does not see the endpoint: - start: the running route's interceptor is missing on the endpoint; - stop or remove: the stopped route's interceptor stays on it, and the sends that use it (routes without an interceptor of their own, a `ProducerTemplate`) fail with `RouteStoppingException`. After a remove this stays when the route is added again, and then the route's own sends fail too. ### Fix - `registerEndpoint` reads the registrations under the manager's read lock; `addPattern`, `register` and `unregister` take the write lock. It is a read lock so that endpoints are still created in parallel (a prototype `toD` creates one per exchange). An endpoint that matches no pattern takes no lock, as before. - The manager remembers the wrappers it hands out (weak keys, as a `toD` endpoint can be evicted from the registry), and `register`/`unregister` update those too, so a wrapper that is not in the registry yet is not missed. The lock alone is not enough: the put is still outside the manager. This keeps the CAMEL-25140 design (the design doc of CAMEL-25142 lists `interceptSendToEndpoint` as done) and only closes the window. Under the lock only the endpoint registry, the intercept endpoint factory and the uri matching run, as before, so the read lock adds no lock-order cycle. Not covered: a route added at runtime with a new uri pattern, while a matching endpoint is being created, can leave that endpoint unwrapped until the next start of a route with `interceptSendToEndpoint` (as before this change). ### Tests `InterceptSendToEndpointNewEndpointRouteLifecycleTest` pauses the thread that creates the endpoint just before the registry put, and starts, stops, or removes and adds again the route meanwhile. The 3 cases fail on main and with the lock alone; the 2 controls (the same steps one after the other) pass. Found with a TLA+ model of the manager. Cost: a route start or stop also goes through the wrappers that are not in the registry (2-3 ms instead of 0.5 ms with a few thousand fresh `toD` endpoints). A prototype `toD` that matches a pattern does 0.7-0.8 instead of 1.1 million sends/s with 8 threads. Endpoints that match no pattern: unchanged. No upgrade guide entry (a bug fix, nothing to do). Affects 4.23.0; cherry-picks cleanly onto camel-4.23.x. Follow-up: CAMEL-YYYYY (the interceptor of a route with `autoStartup=false` is active before the route starts). _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]
