The optaplanner: component solves the planning problem contained in a message with OptaPlanner.
For example: feed it an unsolved Vehicle Routing problem and it solves it.
The component supports consumer as BestSolutionChangedEvent listener and producer for processing Solution and ProblemFactChange
Maven users will need to add the following dependency to their
pom.xml for this component:
You can append query options to the URI in the following format,
No options supported yet.
(since v 2.16)
The endpoint keeps a map of Solver instances. solverId specifies a the map key to use.
Specifies the size the of thread pool to use for processing async Solution messages.
Specify whether to use another thread for submitting Solution instances rather than blocking the current thread.
Message Headers (since v 2.16)
|CamelOptaPlannerSolverId||null||String||Shared||Specifies the solverId to use|
|CamelOptaPlannerIsAsync||PUT||String||Producer||Specify whether to use another thread for submitting Solution instances rather than blocking the current thread.|
Camel takes the planning problem for the IN body, solves it and returns it on the OUT body.
(since v 2.16) The IN body object must implement the optaplanner interface
Solution.supports the following use cases:
- If the body is instance of Solution, then it will be solved using the solver identified by solverId and either synchronously or asynchronously.
- If the body is instance of ProblemFactChange, then it will trigger addProblemFactChange. If the processing is asynchronously, then it will wait till isEveryProblemFactChangeProcessed before returning result.
- If the body is none of the above types, then the producer will return the best result from the solver identified by solverId
The solving will take as long as specified in the
<solver> ... <termination> <!-- Terminate after 10 seconds, unless it's not feasible by then yet --> <terminationCompositionStyle>AND</terminationCompositionStyle> <secondsSpentLimit>10</secondsSpentLimit> <bestScoreLimit>-1hard/0soft</bestScoreLimit> </termination> ... <solver>
NOTE While the Solver is solving, it will effectively hog the camel thread. Future improvements might include solving in a separate thread:
- Asynchronous solving: 1 request starts the solving and registers a callback. When the Solver terminates, the best Solution is returned through the callback.
- 2 phase request solving: 1 request starts the solving on a separate thread. Another request (with an id to the first request) terminates the Solver with Solver.terminateEarly() and returns the best Solution.
Solve an planning problem that's on the ActiveMQ queue with OptaPlanner: