I'm working on a scheduling solution for traveling engineers. Similar to vehicle routing but with daily routes and more complex constrains (like dependencies between visits).
Thanks, Hagai Shatz On 30 Apr 2014, at 20:31, Geoffrey De Smet <ge0ffrey.s...@gmail.com> wrote: > On 30-04-14 15:07, Hagai wrote: > I do use it from other threads in the following 2 scenarios: > > 1. In a thread that monitors a stream of messages with fact changes. Just > before the thread add a new problem fact change to the solver, the code > checks if the message is relevant by examining the current solution facts. > But if there is a pending problem fact change in the queue, this evaluation > cannot be done and a new problem fact change must be added (even if it will > not do any change when processed). The idea is to minimize the situations > where a message does not result in any change to facts and the solver > restart itself to process the a fact change that does not change anything. > > 2. The solver produce many new solutions when starting and after fact > changes. After some time, less new solutions are found. But when a new > solution is found, some additional improvements are usually found shortly > after. To reduce the amount of new best solutions produced by the > application, a thread is scheduled to read/save/send the best solution after > a short idle time (no new best solution for X ms). To make sure the best > solution is valid, the code checks if every problem facts change processed. > If there are still fact changes to process, the solver will produce another > best solution shortly with the updated facts. Thanks for the feedback: it's very helpful for me to know how it's used better. Out of interest: What kind of planning problem are you solving? > > I hope this fix is simple to do so I can remove my workaround. Yes, I'll fix the problem (I might go for an alternative on the peek()'s) on Friday (holiday tomorrow with plans). > > BTW, I'm looking forward to use the new demon mode (instead of a similar > implementation outside of the solver). Grab 6.1.0-SNAPSHOT if you can't wait. Or read the SNAPSHOT docs. Feedback/concerns welcome. > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/OptaPlanner-Solver-isEveryProblemFactChangeProcessed-return-true-before-the-last-fact-change-is-procd-tp4029389p4029392.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users