Повторяющиеся объекты планирования в решении

Question

Я новичок в Optaplanner и пытаюсь решить довольно простую задачу (сейчас я добавлю больше ограничений).Моя модель следующая: у меня есть задачи (MarkerNesting), которые должны запускаться по одной на VirtualMachine;цель состоит в том, чтобы назначить список MarkerNesting с VirtualMachine с, используя все используемые машины (мы можем считать, что у нас больше задач, чем машин в первом приближении).В результате я ожидаю, что у каждой задачи будет дата начала и окончания (в качестве теневых переменных - еще не реализовано).

Я думаю, что я должен использовать цепочечную переменную, а VirtualMachine будет якорем (скованный во времени) - я прав?

Итак, я написал программу , вдохновленную некоторыми примерами (tsp, coach и shuttle) с 4 машинами и 4 заданиями, и я ожидаю каждую машинуимея одну задачу, когда она решена.Однако при его запуске я получаю некоторые странные результаты: не все машины используются, но хуже всего то, что у меня есть дубликаты MarkerNesting экземпляров (пример вывода):

[VM 1/56861999]~~~>[Nesting(155/2143571436)/[Marker m4/60s]]~~~>[Nesting(816/767511741)/[Marker m2/300s]]~~~>[Nesting(816/418304857)/[Marker m2/300s]]~~~>[Nesting(980/1292472219)/[Marker m1/300s]]~~~>[Nesting(980/1926764753)/[Marker m1/300s]]
[VM 2/1376400422]~~~>[Nesting(155/1815546035)/[Marker m4/60s]]
[VM 3/1619356001]
[VM 4/802771878]~~~>[Nesting(111/548795052)/[Marker m3/180s]]

Эти экземпляры различны (дляПрочитайте журнал: [Nesting(id/hashcode)]), но они имеют одинаковый идентификатор, поэтому в конце они являются одной и той же сущностью.Если я хорошо понимаю, Optaplanner клонирует решение всякий раз, когда находит лучшее, но я не знаю, почему он смешивает подобные экземпляры.

Что-то не так в моем коде?Это нормальное поведение?

Заранее спасибо!

Answer 1

Как и ожидалось, я делал что-то не так: в Schedule (PlanningSolution) у меня был геттер для коллекции VirtualMachine, которая вычисляется из другого поля (pools: каждое Pool содержит VirtualMachine s). В результате, там, где нет установщика, и клонер решения, вероятно, не смог клонировать решение должным образом (возможно, потому что pools не аннотирован как факт проблемы или объект планирования?).

Чтобы устранить проблему, я удалил класс Pool (не очень нужен), оставив коллекцию VirtualMachine s в Schedule.

Подводя итог, никогда не вводите слишком много классов, прежде чем они понадобятся ^ _ ^ '

Я отправил правильную версию своего кода на github.

Answer 2

Duplicate MarkerNesting экземпляры, которые вы не создали, имеют одинаковое содержимое, но разные адреса памяти, поэтому != друг от друга: это означает что-то неправильное в клонере решения по умолчанию, который основан на отражении. Прошло много времени с тех пор, как кто-то столкнулся с проблемой там. Смотрите раздел документации "Планирование клонирования". Сложная модель связанных переменных (которая будет улучшена ) здесь совершенно не помогает.

Иногда исправное @DeepPlanningClone исправляет это, но в этом случае это также может быть связано с тем, что @InverseRelationShadowVariable не выбран.

В любом случае, те system.out в методе сеттера вводят в заблуждение - они могут происходить как клонером решения, так и ходами, поэтому без хеша решения (= адрес памяти) они ничего не сообщают. Попробуйте сделать аналогичный system.out либо в событиях изменения вашего лучшего решения, либо в вызове BestSolutionRecaller для cloneWorkingSolution() как для оригинала, так и для клона.