[
https://issues.apache.org/jira/browse/CAMEL-26123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136537#comment-18136537
]
Claus Ibsen commented on CAMEL-26123:
-------------------------------------
PR: https://github.com/apache/camel/pull/28902
* With configFile, the endpoint now creates one SolverManager on first use and
closes it when it stops.
* The solution listeners are kept on the component (per CamelContext), so a
consumer no longer gets the events of other CamelContexts. The solvers map is
per endpoint.
* Sync producers now notify the consumers of the same problemId too
(solveAndListen).
Upgrade guide note: with a shared SolverManager, solving a problem while
another one with the same problemId is still being solved on the same endpoint
now fails, as it already did with a configured SolverManager.
_Claude Code on behalf of Claus Ibsen (davsclaus)_
> camel-optaplanner - with configFile a new SolverManager is created per
> exchange and never closed (thread leak), and consumers get the events of
> every CamelContext
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26123
> URL: https://issues.apache.org/jira/browse/CAMEL-26123
> Project: Camel
> Issue Type: Bug
> Components: camel-optaplanner
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> Found while adding the catalog body types of flink, spring-batch and
> optaplanner (CAMEL-24961, PR #28418).
> h4. 1. With configFile and no solverManager, every exchange leaks a
> SolverManager and its threads
> {{OptaPlannerProducer.getSolverManager}} (main 2a465aa4814c, line 145)
> creates a new {{SolverManager}} from the {{configFile}} for each exchange
> when no {{solverManager}} is configured, and it is never closed. Checked on
> 4.24.0-SNAPSHOT with the CloudBalance example: the live threads went from 16
> to 35 after 20 calls.
> Proposed: create the SolverManager once per endpoint (in doStart) and close
> it in doStop.
> h4. 2. Solvers and listeners are JVM-wide, keyed only by problemId
> {{OptaPlannerEndpoint}} keeps the solvers and the solution listeners in
> static maps ({{SOLVERS}} and {{SOLUTION_LISTENER}}, main 2a465aa4814c, lines
> 41-42), the listeners keyed only by {{problemId}}, which defaults to 1
> ({{OptaPlannerConfiguration}} line 38). A consumer in any CamelContext of the
> JVM receives the best solutions of every async producer with the same
> problemId. Checked on 4.24.0-SNAPSHOT with the CloudBalance example.
> Proposed: keep the solvers and listeners per endpoint (or per CamelContext
> and solver config), not in static maps.
> h4. 3. Sync mode sends no events to consumers
> With {{async=false}} the producer calls {{solverManager.solve(problemId,
> body)}} ({{OptaPlannerProducer}}, main 2a465aa4814c, line 101) without a best
> solution listener, so a consumer on the same problem gets no events, unlike
> async mode. Checked on 4.24.0-SNAPSHOT with the CloudBalance example.
> Proposed: also notify the consumers of the final best solution in sync mode,
> or document that consumers only work with async producers.
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
