Caching Behavior

  • Updated

irServer Rule Execution Service RuleApp Cache Characteristics and Significance

When a rule application is submitted for first time execution, the rule application is compiled and then cached in the AppDomain. Subsequent requests for the rule application will pull from the AppDomain, providing faster access to the rule application. To compile the rule application and enable caching it should be requested appropriately. The compile and caching process is sometimes referred to as the cold start. See Cold Start Mitigation for techniques to avoid end users experiencing time lags due to this behavior.

The FileSystemRuleApp, RepositoryRuleApp and InMemoryRuleApp all leverage caching.

Each rule application type will check to see if there have been changes made to the rule application (or if there is a new revision of the rule application in the case of the RepositoryRuleApp) and will recompile and cache the rule application if there are changes.

By default, 5 rule applications will be stored in the cache. To modify the cache limit, see Managing the RuleApp Cache.

Any time the AppDomain shuts down (e.g. IISReset or AppPool settings such as Recycling or Performance settings), the cache is cleared.

Catalog Specific Caching Behavior

When a rule application is pulled from the Catalog, it is cached on the Rule Execution Service side, not the Catalog Service.

If the RuleApp is in cache, and within the specified cache timeout, the cached RuleApp is used. The default cache timeout is 30 seconds. The timeout can be overridden by passing the desired timeout value into the RepositoryRuleApp constructor.

If the cache has expired, a lightweight check is performed to see if a newer revision of the RuleApp exists using GetRuleApplicationDef(). If a new revision does not exist, the cached RuleApp is used.

If the RuleApp is not in the cache, it is pulled from the Catalog.

Requesting irServer Rule Execution Service to use the specific revision of the rule application from catalog can be performed using the following RepositoryRuleAppRevisionSpec class:

   var spec = new RepositoryRuleAppRevisionSpec { RuleApplicationName = "IrSoaTest", Label = "",
Revision = 1 };
   ruleApp.RepositoryRuleAppRevisionSpec = spec;

InMemory Specific Caching Behavior

To enable caching behavior for InMemoryRuleApp, the following steps are required:

Submitting a request to obtain the caching key will retrieve the key which uniquely identifies ruleapp on the irServer Rule Execution Service:

   var ruleApp = new InMemoryRuleApp();
   ruleApp.RuleApplicationDef = File.ReadAllText(ruleAppFilename);
   var request = new RuleApplicationInfoRequest();
   request.RuleApp = ruleApp;
   var proxy = new RuleEngineServiceClient();
   var ruleAppInfo  = proxy.GetRuleApplicationInfo(request);
   ruleAppInfo.RuleApplicationTrackingKey contains the caching key, which is used for the subsequent requests.

Submitting a request to execute a rule application using a cached rule application key retrieved in the prior step will use the cached revision:

   var ruleApp = new InMemoryRuleApp();
   ruleApp.CacheAndRevisionKey = ruleAppInfo.RuleApplicationTrackingKey;
   var request = new ApplyRulesRequest();
   request.RuleApp = ruleApp;

Note: complete ruleapplication xml in each subsequent request is not required for InMemoryRuleApp as provided caching key directing irServer Rule Execution Service to lookup the cache for the specific revision.

FileSystem Caching Specific Behavior

When a rule application is pulled from the File System, it is cached on the server. For each request, file on the disk is checked if it was updated and reloaded if so.

Path to the rule application can be specified using the FilePath property of the FileSystemRuleApp class:

   var ruleApp = new FileSystemRuleApp();
   ruleApp.FilePath = “filepath”;

Was this article helpful?

0 out of 0 found this helpful



Please sign in to leave a comment.