Unable to reload app.config

SDKs
1

Hi,
I’m trying to update my app.config file (using app.config.sample), but everytime I update it, then restart the container, the container then wants to reload all of the graph and elevation data. I’ve verified that the docker-compose.yml file is correct.

version: ‘2.4’
services:
ors-app:
container_name: ors-app
ports:
- 8080:8080
- 9001:9001
image: openrouteservice/openrouteservice:latest
#build:
#context: …/
# args:
# APP_CONFIG: ./openrouteservice/src/main/resources/app.config.sample
#OSM_FILE: ./openrouteservice/src/main/files/KS_NE_OK_TX.pbf
#OSM_FILE: ./openrouteservice/src/main/files/heidelberg.osm.gz
volumes:
- ./graphs:/ors-core/data/graphs
- ./elevation_cache:/ors-core/data/elevation_cache
- ./logs/ors:/var/log/ors
- ./logs/tomcat:/usr/local/tomcat/logs
- ./conf:/ors-conf
#- ./your_osm.pbf:/ors-core/data/osm_file.pbf
environment:
- BUILD_GRAPHS=False # Forces the container to rebuild the graphs, e.g. when PBF is changed
- “JAVA_OPTS=-Djava.awt.headless=true -server -XX:TargetSurvivorRatio=75 -XX:SurvivorRatio=64 -XX:MaxTenuringThreshold=3 -XX:+UseG1GC -XX:+ScavengeBeforeFullGC -XX:ParallelGCThreads=4 -Xms1g -Xmx2g”
- “CATALINA_OPTS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9001 -Dcom.sun.management.jmxremote.rmi.port=9001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=localhost”

Any ideas?

2

When you start openrouteservice, it will always try to build graphs unless the graphs folder is empty. If there are graphs in the folder then it will try to load them using the configuration that it is currently running with. So if you change your config in a place that affects graph building, if you dont clear the graphs before restarting openrouteservice then it will likely result in errors.

As normal though, the logs from the container will provide more information about if there is an error.

3

Do you mean “it will always try to build graphs if the graphs folder is empty” instead of “it will always try to build graphs unless the graphs folder is empty”?

Using the .yml file I first posted, it always rebuilds everything, regardless if it is run from the command line or from the docker-desktop app, even if nothing has changed. With my inexperience with this, I would think that simply running the container would use everything and not rebuild it each time.

Am I wrong?

The run will actually delete all files in the graphs folder, then take 3 hours to rebuild them. Here’s my directory tree, and you can see all the graphs and elevation files present.

> .
> ├── CHANGELOG.md
> ├── CONTRIBUTE.md
> ├── Dockerfile
> ├── ISSUE_TEMPLATE.md
> ├── LICENSE
> ├── LICENSE.LESSER
> ├── NOTICE.md
> ├── PULL_REQUEST_TEMPLATE.md
> ├── README.md
> ├── docker
> │   ├── README.md
> │   ├── conf
> │   │   └── app.config
> │   ├── data
> │   │   └── elevation_cache
> │   │       └── srtm_38_03.zip
> │   ├── docker-compose.yml
> │   ├── elevation_cache
> │   │   ├── srtm_16_04.gh
> │   │   ├── srtm_16_04.zip
> │   │   ├── srtm_16_05.gh
> │   │   ├── srtm_16_05.zip
> │   │   ├── srtm_16_06.gh
> │   │   ├── srtm_16_06.zip
> │   │   ├── srtm_17_04.gh
> │   │   ├── srtm_17_04.zip
> │   │   ├── srtm_17_05.gh
> │   │   ├── srtm_17_05.zip
> │   │   ├── srtm_17_06.gh
> │   │   ├── srtm_17_06.zip
> │   │   ├── srtm_18_04.gh
> │   │   ├── srtm_18_04.zip
> │   │   ├── srtm_18_05.gh
> │   │   ├── srtm_18_05.zip
> │   │   ├── srtm_18_06.gh
> │   │   └── srtm_18_06.zip
> │   ├── graphs
> │   │   └── car
> │   │       ├── edges
> │   │       ├── ext_hgv
> │   │       ├── ext_road_access_restrictions
> │   │       ├── ext_waycategory
> │   │       ├── ext_waysurface
> │   │       ├── geometry
> │   │       ├── landmarks_core_fastest_car-ors_allow_all
> │   │       ├── landmarks_core_fastest_car-ors_highways
> │   │       ├── landmarks_core_shortest_car-ors_allow_all
> │   │       ├── landmarks_core_shortest_car-ors_highways
> │   │       ├── location_index
> │   │       ├── names
> │   │       ├── nodes
> │   │       ├── nodes_ch_fastest_car-ors_node
> │   │       ├── nodes_core_fastest_car-ors_node
> │   │       ├── nodes_core_shortest_car-ors_node
> │   │       ├── properties
> │   │       ├── shortcuts_ch_fastest_car-ors_node
> │   │       ├── shortcuts_core_fastest_car-ors_node
> │   │       ├── shortcuts_core_shortest_car-ors_node
> │   │       ├── stamp.txt
> │   │       ├── subnetwork_landmarks_core_fastest_car-ors_allow_all
> │   │       ├── subnetwork_landmarks_core_fastest_car-ors_highways
> │   │       ├── subnetwork_landmarks_core_shortest_car-ors_allow_all
> │   │       ├── subnetwork_landmarks_core_shortest_car-ors_highways
> │   │       └── turn_costs
> │   └── logs
> │       ├── ors
> │       │   ├── ors.2020-08-08.log.gz
> │       │   └── ors.log
> │       └── tomcat
> │           ├── catalina.2020-08-08.log
> │           ├── catalina.2020-08-09.log
> │           ├── host-manager.2020-08-08.log
> │           ├── host-manager.2020-08-09.log
> │           ├── localhost.2020-08-08.log
> │           ├── localhost.2020-08-09.log
> │           ├── localhost_access_log.2020-08-08.txt
> │           ├── localhost_access_log.2020-08-09.txt
> │           ├── manager.2020-08-08.log
> │           └── manager.2020-08-09.log
> ├── docker-entrypoint.sh
> ├── openrouteservice
> │   ├── WebContent
> │   │   ├── META-INF
> │   │   │   └── MANIFEST.MF
> │   │   └── WEB-INF
> │   │       └── web.xml
> │   ├── docs
> │   │   └── services
> │   │       ├── accessibility
> │   │       │   └── accessibility_post_request.json
> │   │       ├── error_codes.md
> │   │       ├── isochrones
> │   │       │   ├── eurostat
> │   │       │   │   ├── age_groups_mappings.txt
> │   │       │   │   └── example_query.sql
> │   │       │   └── isochrones_post_request.json
> │   │       └── routing
> │   │           └── BikeSpeedCalculations.xlsx
> │   ├── pom.xml
> │   └── src
>     ......
> 207 directories, 700 files
4

Yes sorry, I meant that it will always try to build the graphs unless there is something in the graphs folder. Based on the configuration there is no reason why it should be rebuilding the graphs each time - I just tried myself and after the initial building it didn’t try to do them again. The only thing I can think of is that for some reason Docker on your system is itself deleting the graphs folder, or clearing it when the container goes down.

5

Thanks. Docker isn’t deleting or clearing it when the container exits, but rather when it is restarted. Just tried a restart using a different method.

I did a quick verify to make sure that docker knows the container is there, and it is showing as present, but exited.

docker start $(docker ps -a -q --filter “status=exited”)

gives me the container ID, 582f27c95afe, I only have 1 container on my system.

I then verified that the files in graphs and elevation_cache are still present, then ran this command to restart it from the command line.

docker start -i $(docker ps -q -l)

It immediately deleted the contents of the graphs/car folder, and created 2 files in that folder.

gh.lock location_index

then started rebuilding the graphs folder.

I did get a clean copy of the log up to this point, but I’m not experienced enough with the system to determine if there is any help in it or not.

Could it be something in the ORS-APP causing this?

2020-08-11 20:58:11,182 INFO [ors.Application] - Starting Application v6.2.0 on 582f27c95afe with PID 8 (/usr/local/tomcat/webapps/ors/WEB-INF/classes started by root in /ors-core)
2020-08-11 20:58:11,185 DEBUG [ors.Application] - Running with Spring Boot v2.0.4.RELEASE, Spring v5.0.8.RELEASE
2020-08-11 20:58:11,187 INFO [ors.Application] - No active profile set, falling back to default profiles: default
2020-08-11 20:58:16,080 INFO [ors.Application] - Started Application in 6.452 seconds (JVM running for 19.042)
2020-08-11 20:58:16,300 INFO [routing.RoutingProfileManager] - Total - 1024 MB, Free - 838.68 MB, Max: 2 GB, Used - 185.32 MB
2020-08-11 20:58:16,302 INFO [routing.RoutingProfileManager] -
2020-08-11 20:58:16,341 INFO [routing.RoutingProfileManager] - ====> Initializing profiles from ‘data/osm_file.pbf’ (1 threads) …
2020-08-11 20:58:16,343 INFO [routing.RoutingProfileManager] -
2020-08-11 20:58:16,359 INFO [routing.RoutingProfileManager] -
2020-08-11 20:58:16,398 INFO [routing.RoutingProfile] - [1] Profiles: ‘driving-car’, location: ‘data/graphs/car’.
2020-08-11 21:03:08,856 INFO [core.PrepareCore] - 0, updates:0, nodes: 1 703 799, shortcuts:0, dijkstras:8 385 928, t(dijk):2.7, t(period):0.0, t(lazy):0.0, t(neighbor):0.0, meanDegree:1, algo:26MB, totalMB:1742, usedMB:1172
2020-08-11 21:04:23,663 INFO [core.PrepareCore] - 340 760, updates:2, nodes: 1 363 039, shortcuts:6 491, dijkstras:23 663 875, t(dijk):69.4, t(period):66.86, t(lazy):0.0, t(neighbor):6.02, meanDegree:1, algo:26MB, totalMB:1742, usedMB:1021
2020-08-11 21:05:32,368 INFO [core.PrepareCore] - 681 520, updates:4, nodes: 1 022 279, shortcuts:136 650, dijkstras:36 556 217, t(dijk):130.44, t(period):119.22, t(lazy):0.0, t(neighbor):18.65, meanDegree:2, algo:26MB, totalMB:1742, usedMB:1228
2020-08-11 21:06:41,819 INFO [core.PrepareCore] - 1 022 280, updates:6, nodes: 681 519, shortcuts:432 831, dijkstras:48 175 184, t(dijk):192.19, t(period):160.75, t(lazy):0.0, t(neighbor):40.9, meanDegree:2, algo:26MB, totalMB:1742, usedMB:1189
2020-08-11 21:08:00,492 INFO [core.PrepareCore] - 1 363 040, updates:8, nodes: 340 759, shortcuts:813 866, dijkstras:59 195 868, t(dijk):262.66, t(period):191.11, t(lazy):0.0, t(neighbor):79.44, meanDegree:2, algo:26MB, totalMB:1742, usedMB:1413