Describe the issue
In HAPI FHIR v6.10.0 there was a change where subscriptions are processed asynchronously. This is causing a delay that is based on the configured schedule time of the scheduled job. The default is 5s so if you hit the window just right you can wait the whole 5s before your subscription is activated and also to receive any messages on the subscription. I can confirm this by creating a simple code that:
Creates subscription in state Requested.
Wait for the subscription to get in state Active.
Bind the subscription (web socket in my case).
Submit resources relevant to the subscription.
Wait to receive ping from the web socket.
With the default delay it can take up to 10s to get the whole round trip. 5s to get the subscription to state active, 5s to receive notification on the web socket.
Environment:
HAPI FHIR Version v6.10.0 and above
OS: Docker (gcr.io/distroless/java17-debian12:nonroot) run on MacBook Air M1
Browser N/A
Additional context
I am testing this using the hapi-fhir-jpaserver-starter.
I still have limited understanding of the whole code base but so far I came to two possible solutions.
Both of them improved the performance from 10s to around 2-3s.
Override the bean in the server-starter and configure the delay to be lower (5s -> 1s).
Pro: Simple to do and already supported.
Con: Increased load on DB.
Try to submit the processed messaged synchronously if it fails store it to the DB and let the job take over.
Pro: No extra load on DB generated.
Con: Due to my lack of overall understanding of code base may have unforeseen side effects.
I created a PR #6395 for the point 2. and would like to hear some feedback if it would be possible to submit the message sooner.
Also if there are any solutions that I am missing at the moment, everything is wellcome.
Describe the issue In HAPI FHIR v6.10.0 there was a change where subscriptions are processed asynchronously. This is causing a delay that is based on the configured schedule time of the scheduled job. The default is 5s so if you hit the window just right you can wait the whole 5s before your subscription is activated and also to receive any messages on the subscription. I can confirm this by creating a simple code that:
With the default delay it can take up to 10s to get the whole round trip. 5s to get the subscription to state active, 5s to receive notification on the web socket.
Environment:
Additional context
I am testing this using the hapi-fhir-jpaserver-starter. I still have limited understanding of the whole code base but so far I came to two possible solutions. Both of them improved the performance from 10s to around 2-3s.
Override the bean in the server-starter and configure the delay to be lower (5s -> 1s). Pro: Simple to do and already supported. Con: Increased load on DB.
Try to submit the processed messaged synchronously if it fails store it to the DB and let the job take over. Pro: No extra load on DB generated. Con: Due to my lack of overall understanding of code base may have unforeseen side effects.
I created a PR #6395 for the point 2. and would like to hear some feedback if it would be possible to submit the message sooner. Also if there are any solutions that I am missing at the moment, everything is wellcome.