Thank you for your replay!
I think I can explain briefly its practical usage. This collections, I
mentioned before, are providers who offer different "goods" with
configurable parameters (our planning variables). Clients can order "goods"
with specific parameters (parameters specified by client, can be range of
values for example: from 1 to 10; or array of values: 1,2,3), we check if
any of our providers are able to create what our client ordered, and pick
the best solution (based on price, and parameters).
If our project will open its source I might talk about it in more detail
later, and link it here.
I will try approach A, currently I'm using custom move factory, but I always
thought that every single planning variable must have its own move
factory... my bad. Also this approach looks fairly easy to implement, and
maybe I will switch to version 6.0.0.Beta1. I will give you an update next
week if I had any luck with it.
ge0ffrey wrote
> and the solver never stops (despite the fact that
> the timeout was set for 120sec).
That sounds like a bug. Older versions had this problem, but recent ones
don't (I don't recall for which version it was fixed).
Enable trace logging and see what the logging says.
Actually it was enabled, but there was no errors, solver just kept on
moving, and in logs all I could find was "move score (...) for move: (...)"
and the logs from rules I made...
On the other hand when I removed my rule which checked if variables was from
the same provider, solver as expected timeout after 120sec and returned
actual best solution. This rule had a lot of compare operations etc, so that
might have been the cause in someway.
ge0ffrey wrote
> I was thinking about using multiple @PlanningEntities, but as far
as I
> know
> it is not supported, so I have resigned from this idea.
I don't see how multiple @PlanningEntities would fix it.
Support for multiple @PlanningEntities is getting better since
6.0.0.Beta1, but not perfect yet.
I thought that multiple @PlanningEntities might have help, if I would use
one of the @PlanningEntities to find best offered "Good" from each of the
providers, then other @PlanningEntity would pick the best "good" from the
"goods" found earlier. But it was just one of the ideas I was thinking
about.
Thank you for your advices again,
Mateusz
--
View this message in context:
http://drools.46999.n3.nabble.com/Planner-Planning-problem-looking-for-ti...
Sent from the Drools: User forum mailing list archive at
Nabble.com.