Fire Arrow Server 2.1.3
Fire Arrow Server 2.1.3 has been released.
- (feature) Faster subscription activation removes a roughly one-second delay from CarePlan event and materialization requests
Faster Subscription Activation
2.1.0 recommended setting hapi.fhir.subscription.immediately_queued: true for deployments that use CarePlan events, so a subscription becomes active immediately instead of waiting on the default five-second activation poll. With that setting enabled, a smaller but still significant delay remained: each activation took about one second longer than necessary.
When a subscription is activated immediately, the server tries to read the new Subscription back the moment it is created — before the transaction that created it has committed. That first read does not find the resource yet, so the server retries. Before 2.1.3, the wait before that retry was fixed at one second, so every immediate activation paid a full second even though the transaction typically commits within tens of milliseconds. On the synchronous CarePlan/$subscribe-due-events and $renew-due-events paths, and on the asynchronous materialization path, callers waited through that second.
Starting with 2.1.3, this retry wait is configurable and defaults to 100 ms with an exponential multiplier of 2.0, so the retry lands shortly after the commit instead of a fixed second later. Measured locally against a CarePlan that produces roughly 101 Tasks:
| Phase | Before | After | Improvement |
|---|---|---|---|
| Subscription activation | ~1140 ms | ~277 ms | 4.1× |
| Asynchronous materialization, end to end | ~2059 ms | ~1040 ms | 2.0× |
| Synchronous subscribe, end to end | ~1798 ms | ~815 ms | 2.2× |
No configuration change is required to benefit from the faster default. The retry wait can be tuned with the following keys:
| Key | Default | Purpose |
|---|---|---|
fire-arrow.subscription.retry.initial-backoff-ms | 100 | Wait before the first activation retry, in milliseconds |
fire-arrow.subscription.retry.multiplier | 2.0 | Factor applied to each subsequent retry wait |
The exponential multiplier spreads later retries out, so a database that takes longer to commit still activates without wasted attempts, up to HAPI's 60-second activation ceiling. Deployments whose server reaches PostgreSQL over a cross-region connection (round-trip latency above 50 ms) should raise fire-arrow.subscription.retry.initial-backoff-ms to 200 so the first retry does not fire before the commit lands. Same-region deployments (1–3 ms round-trip) need no change.