This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • OptaPlanner

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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, ?option=value&option=value&...

URI Options

...

No options supported yet.

Message Headers

...

(since v 2.16)

Name

Default Value

Type

Context

Description

solverId

DEFAULT_SOLVER

String

Shared

The endpoint keeps a map of Solver instances. solverId specifies a the map key to use.

threadPoolSize

10

int

Producer

Specifies the size the of thread pool to use for processing async Solution messages.

async

false

Boolean

Producer

Specify whether to use another thread for submitting Solution instances rather than blocking the current thread.

Message Headers (since v 2.16)

Name

Default Value

Type

Context

Description

CamelOptaPlannerSolverIdnullStringSharedSpecifies the solverId to use
CamelOptaPlannerIsAsyncPUTStringProducerSpecify whether to use another thread for submitting Solution instances rather than blocking the current thread.

Message Body

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

Termination

The solving will take as long as specified in the solverConfig.

Code Block
xml
xml
<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.

 

Samples

Solve an planning problem that's on the ActiveMQ queue with OptaPlanner:

...