Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Capabilities.java to use fhir-cache #2344

Closed
JohnTimm opened this issue May 11, 2021 · 1 comment
Closed

Update Capabilities.java to use fhir-cache #2344

JohnTimm opened this issue May 11, 2021 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@JohnTimm
Copy link
Collaborator

Capabilities.java currently uses a ConcurrentMap to manage a tenant-specific cache for the capabilities statement. This could be updated to use a fhir-cache managed cache with a time-based eviction policy.

@JohnTimm JohnTimm self-assigned this May 11, 2021
JohnTimm added a commit that referenced this issue May 11, 2021
Signed-off-by: John T.E. Timm <johntimm@us.ibm.com>
JohnTimm added a commit that referenced this issue May 11, 2021
Signed-off-by: John T.E. Timm <johntimm@us.ibm.com>
@prb112 prb112 added the enhancement New feature or request label May 12, 2021
@lmsurpre
Copy link
Member

lmsurpre commented May 13, 2021

After setting the fhirServer/core/capabilityStatementCacheTimeout property to 1 (minute), I ran the following two tests.

First:

  1. GET [base]/metadata
  2. get it again right away and confirm that its cached (by noting response time and CapabilityStatement.date)
  3. wait a minute, then try again.

Then:

  1. GET [base]/metadata?mode=terminology
  2. get it again right away and confirm that its cached (by noting response time and TerminologyCapabilities.date)
  3. wait a minute, then try again

In each case, the resource was server cached in step 2 and served fresh on step 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants