1

The last few versions of OptaPlanner all seem to have a bug in locating the meetingSchedulingSolverConfig(.xml), as this file is seemingly ignored. If I'm supposed to be using a different file to set the parameter(s) instead of the xml now, I have no idea where it is.

Running a clean version of 9.38.0, you can go in to the meetingSchedulingSolverConfig.xml file, tweak the parameters (environment mode, move thread count, etc.), add search phases, but the file will tell you it's using default parameters [environment mode (REPRODUCIBLE), move thread count (NONE)] in the command line, and will quit after 5 minutes of running as is set in the default config file. It appears to have stopped following the config file when several of the examples were removed, I first noticed it attempting to move from 8.27 to 8.37, also tried 8.35 and 8.32.

Geoffrey De Smet
  • 26,223
  • 11
  • 73
  • 120
Rob Attrell
  • 11
  • 1

2 Answers2

1

I cannot reproduce this bug on Timefold Solver 0.9.39 (fork of OptaPlanner 9.38.0). I don't recall that this code has received any improvements recently, nor on Timefold, nor on OptaPlanner:

enter image description here

Have you tried introducing an XML syntax error in the SolverConfig XML to see if throws a ParserException when it picks up that file?

Are doing any form of SolverConfig.clone(), for example to set termination time per request? Or any form of Spring or Quarkus integration that picks up src/main/resources/solverConfig.xml by default?

Geoffrey De Smet
  • 26,223
  • 11
  • 73
  • 120
  • I can actually delete everything in the solverconfig file and rebuild so the file is just empty and it still runs just fine, it's very weird. I'm very open to the idea I'm doing something else wrong but if I take the exact same steps with a fresh build on 8.27 and it does pick up my changes like in your screenshot. – Rob Attrell Jun 21 '23 at 15:18
  • Follow up, based on the knowledge that it does in fact work when someone who fully knows what they're doing tries (thanks Geoffrey), I did some testing and found that with the last few versions of OptaPlanner only(?), copying optaplanner-examples-9.xx.x.Final.jar from target to binaries after building no longer allows it to fully run, I tried after moving optaplanner-examples-9.xx.x.Final.jar and optaplanner-examples-9.xx.x.Final-sources.jar and then it picked up my change right away. I inherited this last year and was told copying optaplanner-examples-9.xx.x.Final.jar is all you need... – Rob Attrell Jun 21 '23 at 16:49
  • TLDR: do not copy the examples.jar in your lib folder. Feel free to copy its source files. – Geoffrey De Smet Jul 01 '23 at 15:55
0

Here is a working answer for anybody else who happens to go through the same progression as I did yesterday. The workflow I inherited from our previous OptaPlanner admin was after compiling was complete, copy optaplanner-examples-9.xx.x.Final.jar from target to binaries, and then run the program.

The last few versions of OptaPlanner only(?), copying just optaplanner-examples-9.xx.x.Final.jar no longer allows it to fully run.

I tried after moving optaplanner-examples-9.xx.x.Final.jar AND optaplanner-examples-9.xx.x.Final-sources.jar on whim after Geoffrey's confirmation it's supposed to work (ie. something else is wrong) and then it picked up my changes to the config file right away. I guess maybe I should have just been moving both of those files but it never broke anything to not do that before.

Thanks!

Rob Attrell
  • 11
  • 1
  • Interesting! I don't understand how the sources jar could fix it though, but it's been a while since I used jars outside maven/gradle. – Geoffrey De Smet Jun 22 '23 at 15:15