[jboss-jira] [JBoss JIRA] Commented: (JBRULES-681) Multi-threaded local search solving
[
https://jira.jboss.org/jira/browse/JBRULES-681?page=com.atlassian.jira.pl...
]
Geoffrey De Smet commented on JBRULES-681:
------------------------------------------
Couple of proposals to answer it:
1) New method: Move.cloneForSolution(Solution moveWorkingSolution)
* Users need to implement that method
** and somehow find the cloned Exam instance from moveWorkingSolution, based on the
original Exam instance from the stepWorkingMemory
2) Move should have a Long examId, not Exam exam.
* Users need to implement the doMove and undoMove methods by first fetching the Exam from
the solution, before changing it
3) On Exam.getId() we annotate a @Id or @PlannerId
On Move.getExam() we annotate a @MoveFrom
On Move.getToPeriod() or Move.getToRoom() we annotate a @MoveTo
* By a bunch of black magic (reflection etc) that might allow us to clone to move without
forcing the user to another move
* The @MoveFrom and @MoveTo concept are probably needed for a branch and bound
implementation anyway?
* What do we do with complicated moves, like in the smart TravelingTournament example?
4) Make a move declarative (write compiling stuff for etc)
* Don't think it's possible, some moves, especially in vehicle routing and work
queue ordening use cases are pretty complex
** see smart TravelingTournament move
*** too imperative code, too little declarative code
Multi-threaded local search solving
-----------------------------------
Key: JBRULES-681
URL: https://jira.jboss.org/jira/browse/JBRULES-681
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Use Future's to spread all possible moves in each step over a number of threads.
This number of threads is equal to the number of cpu's by default, as no IO is done
during solving.
Problems:
- each thread will needs it own WorkingMemory and during a step, each working memory will
need to be updated
- a bunch of classes will need to be thread safe, or at least visibility save, such as
bestsolutionrecaller.
- Barriers will be needed to collect the result of each step
- decks might be a great way to spread out the load
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira