Add application warmup feature to run routing queries during startup#7509
Draft
vpaturet wants to merge 1 commit intoopentripplanner:dev-2.xfrom
Draft
Add application warmup feature to run routing queries during startup#7509vpaturet wants to merge 1 commit intoopentripplanner:dev-2.xfrom
vpaturet wants to merge 1 commit intoopentripplanner:dev-2.xfrom
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #7509 +/- ##
=============================================
- Coverage 71.29% 71.19% -0.11%
- Complexity 21217 21222 +5
=============================================
Files 2365 2369 +4
Lines 87770 87954 +184
Branches 8686 8698 +12
=============================================
+ Hits 62574 62615 +41
- Misses 22183 22327 +144
+ Partials 3013 3012 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Contributor
Author
|
@flaktack have you put in place a similar feature for your OTP deployments? |
074225a to
a0004e8
Compare
9f29324 to
cfe420d
Compare
Add a configurable warmup feature that runs transit routing queries in a background thread during OTP startup, warming up JIT compilation, GraphQL schema caches, routing data structures, and other lazily initialized components before production traffic arrives. When the `warmup` section is present in router-config.json, a daemon thread sends sequential GraphQL trip queries through the configured API (TransModel or GTFS). Queries start after Raptor transit data is created and stop when all updaters are primed or after a maximum of 20 queries.
cfe420d to
c989cf2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add a configurable application warmup feature that runs transit routing queries in a background
thread during OTP startup. This warms up the application — JIT compilation, GraphQL schema caches,
routing data structures, and other lazily initialized components — before production traffic arrives.
How it works
When the
warmupsection is present inrouter-config.json, a daemon thread sends sequentialGraphQL trip queries through the configured API (TransModel or GTFS), exercising the full request
stack: GraphQL parsing, data fetchers, Raptor + A* routing, itinerary filtering, and response
serialization. The thread starts after Raptor transit data is created and stops when all updaters
are primed (health endpoint returns UP) or after a maximum of 20 queries.
Queries alternate between depart-at/arrive-by and cycle through access/egress mode combinations
(walk, car-to-park). Query parameters are passed as GraphQL variables rather than string
interpolation, matching how production clients call the API.
Configuration example
Design
WarmupConfig— config parsing (final class,Apienum implementsDocumentedEnum, versionV2_10)WarmupWorker— background thread that orchestrates warmup queries with max query limit, completion summary (count, failures, elapsed time), and top-levelThrowablecatchWarmupQueryExecutor— strategy interface returning success/failure booleanTransmodelWarmupQueryExecutor/GtfsWarmupQueryExecutor— cache schema, context, and (for GTFS) theGraphQLinstance at construction time; use GraphQL variables for query parameters; both use immutableMap.of/Map.ofEntriesfor variablesstandalone.configure.warmup(startup lifecycle, not HTTP infrastructure)Safety
@NullableGraphQL schema (warns if API feature is disabled)catch (Throwable)ensures the warmup thread never dies silentlyUnit tests
WarmupConfigTest— tests config parsing (absent section, coordinate parsing, API enum parsing)WarmupQueryValidationTest— validates both static query constants against the actual GraphQL schemas at build timeDocumentation
RouterConfiguration.mdregenerated with the newwarmupsectionpackage.mddocuments the warmup subpackage lifecycle and design