Optaplanner 增量分数状态和解决方案之间的早期终止增量

Question

I'm using an incremental score calculator class because of the heavy use of maps and calculations which did not scale well in drools.

It seems to work well, but as I've had to debug I've noticed differences between the number of moves used in the final solution and the moves processed by my before/afterVariableChanged handlers. This causes a diffenence between what is actually assigned in the solution and the state in my incremental score objects. Based on some logs it looks like the incremental does not know when the solution has stopped accepting moves because of early termination (i'm using secondsSpentLimit).

How can I stop my incremental score implentation from receiving before/afterVariableChanged events that would not be considered in the solution because of early termination?

Answer 1

Can you turn on TRACE logging to confirm this behavior?

In essence, LocalSearch looks like this (with moveThreadCount=NONE (= default)):

for (each step && not terminated) {
    stepStarted()
    for (each move && not terminated) {
         doMove(); // Triggers variable listeners
         if (better move) updateBestSolution();
         undoMove(); // Triggers variable listeners
    }
    stepEnded()
}

So termination is atomic versus move evaluation. So your issue should have another cause.

With moveThreadCount=4 etc this story becomes a bit more complex, but each move thread has it's own ScoreDirector, so they pretty much work in isolation.

That being said, incremental java score calculation and shadow variables together can drive people insane... This is mainly caused because the before events happen in the middle of doMove()'s, right before a variable changes. At that time, half of the model can already be in an intermediate state that is impossible to understand, due to other variables that move was already changing. FWIW, take a look at VariableListener.requiresUniqueEntityEvents() , it might help a bit... Or try ConstraintStreams (BAVET implementation if you favor speed over functionality).