Hello,
I’m working on getting openrouteservice running for a production install. I don’t want to build the graph each time a container starts, so I’m setting up an option to build the graphs that builds and then copies the built graph to a location the API container can read from. I’ve set ors.engine.preparation_mode
to true
. Even if the build fails, the entrypoint/java always returns an exit code of 0 (with preparation_mode
set to false
this would return 1)
What is a good test for confirming that the graph was completely built? Is checking for the stamp.txt
in the profiles a reasonable check?
(I’m running v8.0.0)
Hi @ddunlop ,
you could check against the /ors/v2/health
endpoint which should be ready
once graphs are built. and not ready
otherwise.
Best regards
I’m running the build phase in preparation mode, so the process ends when the graph is built. So I don’t have a chance to check the status endpoint.
Ah right.
Normally it should be a case that once the instance shuts down with exit code 0, that the graphs are built.
It seems, the code for the preparation_mode
check, doesn’t care if the RoutingProfileManagerStatus has failed.
I’ve made a PR that fixes this:
GIScience:main
← GIScience:fix/preparation-mode-not-failing
opened 10:15AM - 03 Apr 24 UTC
### Pull Request Checklist
<!--- Please make sure you have completed the follow… ing items BEFORE submitting a pull request (put an x in each box
when you have checked you have done them): -->
- [x] 1. I have [**rebased**][rebase] the latest version of the main branch into my feature branch and all conflicts
have been resolved.
- [x] 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the
[Unreleased] heading.
- [ ] 3. I have documented my code using JDocs tags.
- [ ] 4. I have removed unnecessary commented out code, imports and System.out.println statements.
- [ ] 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
- [ ] 6. I have created API tests for any new functionality exposed to the API.
- [ ] 7. If changes/additions are made to the ors-config.json file, I have added these to the [ors config documentation][config]
along with a short description of what it is for, and documented this in the Pull Request (below).
- [x] 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
- [ ] 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
- [ ] 10. For new features or changes involving building of graphs, I have tested on a larger dataset
(at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
- [ ] 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the
importer etc.), I have generated longer distance routes for the affected profiles with different options
(avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end
points generated from the current live ORS.
If there are differences then the reasoning for these **MUST** be documented in the pull request.
- [x] 12. I have written in the Pull Request information about the changes made including their intended usage
and why the change was needed.
- [ ] 13. For changes touching the API documentation, I have tested that the API playground [renders correctly][api].
Fixes # .
### Information about the changes
- Key functionality added: fixes preparation mode exiting with code 0 in case of RoutingProfileManager fails
- Reason for change: https://ask.openrouteservice.org/t/verifying-successful-graph-preparation/5925
### Examples and reasons for differences between live ORS routes, and those generated from this pull request
-
### Required changes to ors config (if applicable)
-
[config]: https://GIScience.github.io/openrouteservice/run-instance/configuration/
[api]: https://gitlab.gistools.geog.uni-heidelberg.de/giscience/openrouteservice-infrastructure/ors-docs-api#test-new-ors-documentation
[rebase]: https://github.com/GIScience/openrouteservice/blob/main/CONTRIBUTE.md#pull-request-guidelines
once this is merged, you can use the main branch as base (if you use docker, you need to build a local image until the next release)
Best regards