To enable caching for an endpoint, edit the configuration file using the JSON object enableCache. For example, line 11 below:

{
    "component"   : "com.nurocor.mdsp.core.ServiceComponent",
    "identifier"  : "org.cdisc.share:mdr.share:get.productgroup.data-analysis",
    "label"       : "Get SHARE Product Group Data Analysis",
    "description" : "This service returns a list of the SHARE data analysis products.",

    "config" : {
        "provider"    : "com.nurocor.mdsp.model.services.ViewResource",
        "request"     : "/mdr/products/DataAnalysis",
        "datasource"  : "org.cdisc.share:datasources:share-mdr",
        "enableCache" : true,
        "representations" : [
            { "mediaType" : "application/json",
              "view"      : "org.cdisc.share:mdr.share:view.productgroup.data-analysis" }
        ]
    }
}


The following is a listing of endpoints by product with caching enabled:

ADaM: product, data structure, varset
CDASH: product, class, domain
CDASHIG: product, class, domain, scenario
SDTM: product, class, dataset
SDTMIG: product, class, dataset
SENDIG: product, class, dataset
CT: package list, package, package codelists, codelist terms

1. The March release is planned to include Elasticsearch, which we use to store the API monitoring information and the cache. This decouples those features from the actual MDSP platform, so that both can be scaled independently. Elasticsearch can be used as a software component on its own or as a AWS managed service. The cache implementation is independent from the cache configuration (done in the API config) and the cache initialization (triggered by first resource request).

 

2a. Cache cannot (should not) be mirrored from QA to PROD server. This is not related to the application architecture, but due to the fact that the QA server is shared by /env/test and /env/qc, whereas the PROD server is published from /env/prod. Mirroring would be logically inconsistent.

 

2b. In memory cache does not survive a server restart, redeploying a new version of MDSP, or restarting an existing version of MDSP. Elasticsearch runs in its own environment, so in this case the cache won't be affected by these operations.

 

3. Correct. Note that publishing can be publishing the API configuration or publishing the triple store. In each case, the cache is flushed in the current 1.1.x release, whereas in 1.2 there will be an option that can be specified for the publishing operation to either flush or not flush the cache. Flushing the cache means that the cache will be emptied.

 

4. Done. I have updated the API config in /env/test/api and /env/qc/api. I republished on the CDISC QA server from /env/qc/api and rebuilt the cache. The response times pre and post cache are similar to the ones I collected last weekend, so I didn't redo the spreadsheet. I have created the cache for the same resources as documented in that spreadsheet, but added a few CT packages that were not part of the previous cache initialization (coact, qrsct, qs-ftct, protocolct). That means that all CT packages should now be cached on QA.

 

5a. Understood that CDISC will create the cache on the PROD server. Before doing that, I assume that CDISC will prepare the /env/prod folder, tag the git commit object, and notify Nurocor, so that Nurocor can publish the API configuration and the triple store on the PROD server.

 

5b. To be clear. Cache initialization is not counted toward allotted bandwidth until the April 1 release. Starting with April 1, cache initialization does count. Nurocor assumes cache initialization until April 1 to be executed within reason.

  • No labels