[ 
https://issues.apache.org/jira/browse/CAMEL-26682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on CAMEL-26682 started by shashank.
----------------------------------------
> camel-kamelet - removing a Kamelet's route should also account for thread 
> pools its components create and for executors that are not a 
> ThreadPoolExecutor
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-26682
>                 URL: https://issues.apache.org/jira/browse/CAMEL-26682
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-kamelet
>            Reporter: shashank
>            Assignee: shashank
>            Priority: Minor
>
> Follow-up of CAMEL-25962 (apache/camel#29292). When a Kamelet endpoint 
> created while the context runs is shut down, the route the Kamelet created is 
> removed. Since #29292 that removal waits for the route's thread pools to go 
> idle at most the shutdown timeout, or does not wait when the endpoint was 
> only consumed from.
> Two cases are not covered, because the idle check only sees the 
> {{ThreadPoolExecutor}} pools that the route itself registers:
> * a thread pool that a component of the Kamelet's route creates for itself, 
> such as the worker pool of an asynchronous Kafka producer. A caller can still 
> run on such a pool when the route is removed, and the check does not see it;
> * executor services that are not a {{ThreadPoolExecutor}}, such as virtual 
> thread executors. The check cannot tell whether they are idle.
> Both need a way to attribute those executors to the route (for example 
> through the {{ExecutorServiceManager}} source of the executor) and to tell 
> whether they still run a task.
> Also from the review of #29292: after the deadline, {{stopRoute}} can wait up 
> to the shutdown timeout again, so the worst case is about twice the timeout, 
> and shutting the pool down can interrupt the caller still running on it. The 
> WARN logged at the deadline could say that the calling exchange may be 
> interrupted.
> _Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to