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
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.
View this message in context:
Sent from the Drools: User forum mailing list archive at Nabble.com
rules-users mailing list