Waypoints GET refetches every route after each best solution, one at a time, under one lock

Đang mở
  • Có gì không ổn?
#2,805 0 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@rsynek đang làm issue này rồi.

Từ ngày 5/11/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

component/service

Describe the bug
GET /v1/route-plans/{id}/waypoints is slow while a run solves, and the map in the visualization waits for it.

WaypointsServiceImpl on main has three causes:

  1. onBestSolution (WaypointsServiceImpl.java:116) replaces the whole route map of the run. The next GET fetches every route from the map service again, also the routes whose stops did not change.
  2. getWaypoints (WaypointsServiceImpl.java:61) is synchronized on the bean, so one lock serves all runs. It calls the map service one route at a time, and it holds the lock through the retry delays.
  3. runIdsToWaypoints (WaypointsServiceImpl.java:49) never removes a run. It is also the only source of waypoints for a finished run, so memory grows with each run until a restart.

Think of a courier who throws away every drawn route after each new order. Then the courier redraws each route, also the unchanged ones, with the one pen that all couriers share.

Expected behavior
A GET after a best solution fetches only the routes whose stops changed, fetches them in parallel, and does not block the other runs. The service removes a finished run from memory, and a later GET reads the stored waypoints of that run.

Actual behavior
Measured with a fake map service at 150 ms per call, 50 vehicles, and a best solution that changes 5 routes:

Time Map service calls
GET after a best solution 7,829 ms 50
First GET 7,877 ms 50

Field Service Routing 2.7.0 in dev mode with a local OSRM (Open Source Routing Machine) server, 45 vehicles with about 175 vehicle shifts (one route for each shift): a GET after a best solution takes 1.13 s to 2.26 s.

To Reproduce

  1. Start a routing model with a map service, for example Field Service Routing with a local OSRM server.
  2. Solve a dataset with 45 vehicles or more.
  3. Call GET /v1/route-plans/{id}/waypoints every 2 seconds while the run solves, and log the time of each call.

Each GET after a best solution takes more than a second, and the map service log shows one call per route.

Environment

Timefold Solver Version or Git ref: 2.8.0 (main at 6741d1043)

Output of java -version: not relevant

Output of uname -a or ver: not relevant

Additional information

PR #2723 holds a solution for this bug. I closed it and opened this issue, so the owner of the service module can take over the change. Its approach:

  • Keep a route while its stops are equal, and fetch only the changed routes.
  • Fetch the missing routes in parallel on a dedicated pool (timefold.platform.map-service.waypoints-parallelism, default 8), without the global lock. Requests at the same time for the same route share one fetch.
  • For a viewed run, fetch the changed routes in the background after a best solution, at most one batch at a time for each run.
  • Release a run after SaveWaypointsPostProcessor stores its waypoints, or when the run fails. A later GET reads the waypoints from storage. A bounded list of released run ids stops a late event from adding a released run again.
  • Send FAILED with the run id when the run metadata cannot be read. Without this, a failed run is not released: SolverWorker.notifyOnFailure throws a NullPointerException when getMetadata returns null.

With the change of PR #2723, the same measurement with the fake map service gives 160 ms and 5 calls for a GET after a best solution. The Field Service Routing measurement gives 20 ms to 60 ms.

Ngôn ngữ chính
Java
Star
1.8k
Fork
243
Merge trung bình
2 ngày 4 giờ
Pull request đã merge (30 ngày)
46

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của TimefoldAI/timefold-solver

Tất cả issue của TimefoldAI/timefold-solver

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.