[
https://issues.apache.org/jira/browse/CAMEL-26049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-26049:
--------------------------------
Fix Version/s: 4.24.0
> camel-coap - CamelContext.stop() leaves the non-daemon CoapServer threads
> running, and every producer start leaks a bound client endpoint
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26049
> URL: https://issues.apache.org/jira/browse/CAMEL-26049
> Project: Camel
> Issue Type: Bug
> Components: camel-coap
> Reporter: shashank
> Assignee: shashank
> Priority: Major
> Fix For: 4.24.0
>
>
> Two leaks, both because Californium 3.14 only releases threads and sockets on
> {{destroy()}} (main 0c1e85c8631c):
> # {{CoAPComponent.doStop}} calls {{stop()}} on its {{CoapServer}}s, never
> {{destroy()}}, and keeps the {{servers}} map. {{CoapServer.stop()}} keeps the
> server executors ({{CoapServer(main)#N}}, {{CoapServer(secondary)#N}}, not
> daemon threads). After a CamelContext with a coap consumer is stopped the JVM
> does not exit on its own (Camel Main, standalone, containers then need a
> SIGKILL), and every CamelContext in the same JVM adds 3 threads.
> # {{CoAPProducer}} creates its client with {{CoAPEndpoint.createCoapClient}},
> which builds the client's own {{CoapEndpoint}} (bound UDP socket with
> receiver and sender threads, or DTLS/TCP connector threads). {{doStop}} calls
> {{client.shutdown()}}, which only shuts the client's executors down (javap)
> and does not destroy that endpoint. Each route restart, and each producer
> evicted from a {{toD}} or ProducerTemplate cache, leaks a bound socket and 2
> or more threads.
> *Fix*: {{CoAPComponent.doStop}} destroys the servers and clears the map
> (consumers get the server from {{getServer}} on each start, so a restarted
> context creates them again); {{CoAPProducer.doStop}} destroys the endpoint of
> the client it created. A client set on the component or endpoint is left
> alone.
> *Tests*: new {{CoAPComponentStopDestroysServersTest}} (2) and
> {{CoAPProducerStopDestroysEndpointTest}} (1).
> * {{stoppingTheCamelContextReleasesTheServerThreads}} fails on main:
> {{non-daemon CoapServer threads still alive after CamelContext.stop() ==>
> expected: <[]> but was: <[CoapServer(main)#1, CoapServer(secondary)#1,
> CoapServer(secondary)#2]>}};
> * {{routeRestartsReleaseTheEndpointsOfTheStoppedProducers}} fails on main:
> {{UDP receiver threads of stopped CoAP producers still alive after 5 restarts
> ==> expected: <0> but was: <10>}};
> * {{aCamelContextStartedAgainServesAgain}} is a control that passes on main
> and with the fix.
> Unit tests of camel-coap with the fix: 85 run, 0 failures.
> *Not changed*: the observe consumer ({{CoAPObserver}}) keeps its client
> endpoint too, but there the endpoint must stay until the cancel request of
> CAMEL-25742 has gone out; {{CoAPConsumer}} has no {{doStop}} (a stopped route
> stays registered on its resource). Follow-ups.
> *How it was found*: a per-class thread/fd leak check over module test suites
> and a route restart probe (r75).
> *Affected*: main, camel-4.23.x, camel-4.22.x, camel-4.18.x and camel-4.14.x
> (same code). Read, not run.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
