[
https://issues.apache.org/jira/browse/CAMEL-26048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-26048.
---------------------------------
Resolution: Fixed
Fixed via https://github.com/apache/camel/pull/28535
> camel-mina - every route restart leaks the acceptor of the stopped consumer
> (a non-daemon thread and its selectors)
> -------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26048
> URL: https://issues.apache.org/jira/browse/CAMEL-26048
> Project: Camel
> Issue Type: Bug
> Components: camel-mina
> Reporter: shashank
> Assignee: shashank
> Priority: Major
> Fix For: 4.24.0
>
>
> {{MinaConsumer}} builds its acceptor (or, in client mode, its connector) and
> its worker pool in the constructor. {{doStop}} only unbinds the address
> (client mode: disposes the connector); {{acceptor.dispose(true)}} and
> {{workerPool.shutdown()}} are only in {{doShutdown}} (main 0c1e85c8631c). A
> route that is stopped and started again does not shut its consumer down:
> {{RouteService}} stops it and the next start creates a new consumer, so the
> old consumer's {{doShutdown}} never runs. Each route restart leaks the
> stopped acceptor: tcp a {{NioSocketAcceptor}} with its acceptor thread (not a
> daemon thread) and one selector per I/O processor ({{availableProcessors() +
> 1}}) plus the worker pool; udp a {{NioDatagramAcceptor}} and its worker pool;
> vm a {{VmPipeAcceptor}} and its idle status checker thread (not a daemon
> thread). Measured on a 10-core machine, 5 restarts of a tcp consumer: 5 more
> {{NioSocketAcceptor-N}} threads and about 210 more open file descriptors,
> never released; the non-daemon threads also keep the JVM running after the
> CamelContext is stopped. Triggers: route stop/start (JMX, control bus, dev
> console, RouteController), route policies that stop and start their route,
> and the start retries of the {{SupervisingRouteController}} (each failed
> attempt creates a new consumer). CAMEL-9738 added the dispose to
> {{doShutdown}}, which this path never reaches. Removing a route (route
> reload, route templates and kamelets created again) shuts the current
> consumer down, so there only consumers left over from earlier restarts leak.
> *Fix*: {{doStop}} disposes the acceptor after the unbind and shuts the worker
> pool down, also in client mode. It waits for the I/O threads
> ({{dispose(true)}}) only when the CamelContext is stopping, so
> {{CamelContext.stop()}} still waits for them as before; a route stop does not
> wait (the address is already unbound). Either way the acceptor is marked
> disposed, so the {{dispose(true)}} of {{doShutdown}} then does nothing (javap
> {{AbstractIoService.dispose}}, mina-core 2.2.9). The protocol setup runs
> again in {{doStart}} when the consumer was stopped, so a consumer that is
> stopped and started again (route or CamelContext suspend/resume, a route
> policy that stops the consumer itself) gets a new acceptor or connector;
> before, it bound the old acceptor again, and in client mode the start failed
> with {{IllegalStateException: The connector is being disposed.}}
> *Tests*: new {{MinaConsumerRestartTest}}, 6 tests (tcp, udp and vm route
> restarts: every stopped acceptor disposed, the tcp and udp worker pools shut
> down, the restarted route receives; same-instance stop/start, also in client
> mode; a route stop calls {{dispose(false)}} and a CamelContext stop
> {{dispose(true)}}), all fail on main, for example {{the acceptor of a stopped
> consumer must be disposed ==> expected: <true> but was: <false>}}, and in
> client mode {{IllegalStateException: The connector is being disposed.}}. Unit
> tests of camel-mina with the fix: 122 run, 0 failures, 4 skipped.
> *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 consumer). Read, not run.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
