[jboss-jira] [JBoss JIRA] Commented: (JBRULES-681) Multi-threaded local search solving

[Geoffrey De Smet (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBRULES-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12510807#action_12510807 ] 

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