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

Abierto
  • ¿Algo no está bien?
#2,805 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@rsynek ya está trabajando en esto.

Desde el 5/11/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.

Lenguaje dominante
Java
Estrellas
1.8k
Forks
243
Merge medio
2 d 4 h
PR fusionados (30 d)
46

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de TimefoldAI/timefold-solver

Todos los issues de TimefoldAI/timefold-solver

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.