[
https://issues.apache.org/jira/browse/CAMEL-25962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-25962 started by shashank.
----------------------------------------
> camel-kamelet - removing a Kamelet's route waits for ever while a source
> Kamelet's threads() pool stays busy, and does not wait for a component's own
> thread pool
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25962
> URL: https://issues.apache.org/jira/browse/CAMEL-25962
> Project: Camel
> Issue Type: Improvement
> Components: camel-kamelet
> Reporter: shashank
> Assignee: shashank
> Priority: Minor
>
> With CAMEL-25839 the route of a Kamelet endpoint that is used once and
> discarded ({{toD}}, {{recipientList}}, {{routingSlip}} with {{cacheSize=-1}},
> {{pollEnrich}}) is stopped and removed on a thread of the Kamelet component.
> The calling route can continue on a thread that the Kamelet's route owns, so
> the removal waits:
> * for the calling exchange to be done, when the endpoint is shut down inside
> the producer callback ({{toD}});
> * for the thread pools that the route's EIPs created ({{threads()}} and the
> others, tracked with {{LifecycleStrategy.onThreadPoolAdd}} by route id) to be
> idle, in every case.
> Two cases are not covered when the endpoint is shut down where the calling
> exchange is not known ({{recipientList}}, {{routingSlip}}, {{pollEnrich}}
> with {{cacheSize=-1}}):
> # A thread pool that a component of the route creates for itself, such as the
> worker pool of an asynchronous {{kafka}} producer (the kafka-sink Kamelet,
> {{synchronous=false}} by default). The pool is not created by an EIP, so it
> has no route id. {{KafkaProducer.doStop}} calls
> {{shutdownGraceful(workerPool, shutdownTimeout)}}: it waits for the calling
> route to leave the worker thread, up to 30 s by default, while {{stopRoute}}
> holds the lock of the CamelContext, then interrupts it.
> # Executor services that are not a {{ThreadPoolExecutor}} (virtual threads):
> the removal cannot tell whether a thread is still running, so it does not
> wait.
> h3. Possible fix
> For 1: attribute the thread pools created while the Kamelet's route is
> created and started (on the thread that creates it) to that route, or check
> the {{ExecutorServiceManager}} for pools whose source is a service of the
> route. For 2: count the running tasks of the route's virtual-thread executors
> (a wrapper that counts them). Alternatively, a core hook that gives a
> prototype endpoint the exchange of the calling route when {{recipientList}},
> {{routingSlip}} and {{pollEnrich}} shut it down (for example, shut the
> prototype endpoint down from an on-completion of the original exchange),
> which would cover both.
> Affected: main, once CAMEL-25839 is merged (before it, the route was never
> removed).
> Also (Claus Ibsen, third review of #28260, reproduced with a probe test on
> ee985a1c22): the removal task retries every 100 ms with no limit. For the
> endpoint of a removed route that consumed from a source Kamelet, the first
> attempt runs at once, so with fast steps the pool is usually idle and the
> route is removed (timer every 60 s or every 100 ms: removed within about 1
> s). When the {{threads()}} pool is busy at that moment (a slow step: HTTP
> call, database; in the probe {{delay(500).syncDelayed()}} with a timer every
> 100 ms), every new message then waits up to 30 s on {{kamelet:sink}}
> ({{block=true}}), the pool never goes idle again, and the Kamelet's route was
> still there after 45 s in 3 of 3 runs (434 "still has an active thread:
> removing it later" TRACE lines). Not a regression: before CAMEL-25839 that
> route was never removed. Proposed fix (Claus): skip the idle wait when the
> endpoint was the input of a removed route, since no calling route runs on
> that pool; otherwise stop the route anyway after the shutdown strategy
> timeout. Test: his {{KameletSourceRemovalProbeTest}} (source template with
> {{threads(2)}} and a slow step, consumer route removed at runtime, the
> Kamelet's route must be gone within 30 s).
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
