4 ms·

Thanks for the kind words. We've working hard to reduce the complexity and will continue to do so. For example: - ConstraintsStreams (instead of DRL) to declar

Thanks for the kind words. We've working hard to reduce the complexity and will continue to do so. For example: - ConstraintsStreams (instead of DRL) to declare incremental constraints easily in plain Java (or another JVM language). No need to learn the Drools Rule Language any more. - Autoconfiguration (no need for solverConfig.xml unless you want to power tweak) thanks to our Quarkus extension or Spring Boot starter. - SolverManager that manages Solver threads for you. Great to avoid HTTP REST timeouts or to solve multiple problems. Coming soon: - Code completion (XSD) when power tweaking the solverConfig.xml - Simplified VRP model

gegtik 6y ago
optaplanner simply rocks - I appreciate your work in the space tremendously. My suggestion is to create a simple way to deploy a to containers so that a primary server can pass out parallel optimization runs to a set of secondary nodes, allowing you to parallelize really easily. a second generation of this would include code to spin up secondary nodes on demand depending on the number of parallel scenarios you want to run.
- ge0ffrey 6y ago
  Yes, our container integration needs to become more streamlined. One of ours first goals is make it very easy to deploy all quickstarts on OpenShift (= Kubernetes) especially the Quarkus ones, by including a docker file and a how-to-deploy in the readme. Today, it should already just be a matter of taking the quickstart(s): https://github.com/kiegroup/optaplanner-quickstarts https://github.com/kiegroup/optaplanner-quickstarts and following the quarkus deploy guide: https://quarkus.io/guides/deploying-to-openshift https://quarkus.io/guides/deploying-to-openshift but we'll streamline it even more. As a second stage goal, this will deal with starting up nodes as needed too.
throwaway189262 6y ago
Constraint streams will be awesome! Writing constraints was the hard part, hard enough that eventually we gave up on a solver and went back to our terrible home rolled algorithm. That's always the case with solvers though. Another hard part was combining chain through time with entities that can be scheduled together vs ones that need gaps. This seems to be a common use case, grouping work where you need a setup/teardown gap between entities. Not sure how to improve this but maybe add some kind of built-in support for "entity coloring" on chained variables where you can configure which run together in a chain vs which ones need setup/teardown gaps between. Overall Optaplanner is an amazing piece of software though, good work!

gegtik 6y ago

optaplanner simply rocks - I appreciate your work in the space tremendously. My suggestion is to create a simple way to deploy a to containers so that a primary server can pass out parallel optimization runs to a set of secondary nodes, allowing you to parallelize really easily. a second generation of this would include code to spin up secondary nodes on demand depending on the number of parallel scenarios you want to run.

ge0ffrey 6y ago
Yes, our container integration needs to become more streamlined. One of ours first goals is make it very easy to deploy all quickstarts on OpenShift (= Kubernetes) especially the Quarkus ones, by including a docker file and a how-to-deploy in the readme. Today, it should already just be a matter of taking the quickstart(s): https://github.com/kiegroup/optaplanner-quickstarts https://github.com/kiegroup/optaplanner-quickstarts and following the quarkus deploy guide: https://quarkus.io/guides/deploying-to-openshift https://quarkus.io/guides/deploying-to-openshift but we'll streamline it even more. As a second stage goal, this will deal with starting up nodes as needed too.

throwaway189262 6y ago

Constraint streams will be awesome! Writing constraints was the hard part, hard enough that eventually we gave up on a solver and went back to our terrible home rolled algorithm. That's always the case with solvers though. Another hard part was combining chain through time with entities that can be scheduled together vs ones that need gaps. This seems to be a common use case, grouping work where you need a setup/teardown gap between entities. Not sure how to improve this but maybe add some kind of built-in support for "entity coloring" on chained variables where you can configure which run together in a chain vs which ones need setup/teardown gaps between. Overall Optaplanner is an amazing piece of software though, good work!