Question
SunLife
IN
Last activity: 16 Jan 2019 17:00 EST
How Rule Cache and Rules assembly cache works when an activity runs?
This is how I understand Rule cache and Rule assembly cache works when an activity runs -
1) Pega determines the appropriate version to run thorough rule resolution and tries to find that instance in rule cache , if not found then loads it from database. (Is the instance in rules cache equivalent to compiled version? then below points are irrelevant..)
2) Now, an activity runs by executing corresponding java code. So, from the rule instance found from rule cache/loaded from rule table, PEGA assembles the java code to determine the class name and uses the class name to check in rules assembly cache whether compiled code already exists or not. If exists, executes that instance.
3) If not found, then tries to find the compiled class file in hard disk. If found, classloader loads it and execute.
4) If compiled version not found, then code is compiled before being executed.
And how VTable fits in steps 2,3,4??
I have gone through many posts, but no where I found the difference between Rule cache and Rules assembly cache mentioned clearly. So, I have collated here what I understood.
Please confirm if my understandings are correct or not.
***Edited by Moderator Marissa to update platform capability tags****
Pegasystems Inc.
US
Can you please check the below article.
hope it helps.
SunLife
IN
Hi Rachit,
I have already gone through it. The difference between rule cache and rules assembly cache is not clear to me. If possible, kindly add/modify steps provided above if my understanding is not correct.
Thanks,
Saikat
TATA Consultancy Services Ltd
IN
Hi,
Rule cache — Per node. Reduces PegaRULES database traffic, contains copies of rules recently accessed or recently updated by developers. Occupies virtual memory. The PegaRULES agent, during the periodic system pulse, invalidates rules in the rule cache that were recently updated on another node.
Rules Assembly cache — Per node. Tracks rules for which Java generation and compilation is complete. Formerly known as the FUA cache. Located in virtual memory; links to loaded Java classes.
PEG
US
Let's try it this way. The assembled classes consist of the compiled Java code for a rule, said assembly being dependent upon the ruleset map for the relevant access group and Application rule. They live in the database, and are also extracted to a per-node cache on each node. You can have many assembled class entries for a single rule, as the example below will show.
The VTable cache can also have multiple entries for a single rule; each of them points to a particular assembled classes entry. This "connection" is performed by Rule Resolution once. As long as the VTable cache entry remains in place, Rule Resolution is not performed -- it is assumed that the current resolution is current and correct.
From looking at a VTable entry for a rule, you can determine which compilation (assembled class) is the one that will be used.
For a recent SR that I worked, I had occasion to get a direct database dump of all the entries for a single activity in the assembled classes table. I found that this activity had 5 entries, with various compilation dates:
Let's try it this way. The assembled classes consist of the compiled Java code for a rule, said assembly being dependent upon the ruleset map for the relevant access group and Application rule. They live in the database, and are also extracted to a per-node cache on each node. You can have many assembled class entries for a single rule, as the example below will show.
The VTable cache can also have multiple entries for a single rule; each of them points to a particular assembled classes entry. This "connection" is performed by Rule Resolution once. As long as the VTable cache entry remains in place, Rule Resolution is not performed -- it is assumed that the current resolution is current and correct.
From looking at a VTable entry for a rule, you can determine which compilation (assembled class) is the one that will be used.
For a recent SR that I worked, I had occasion to get a direct database dump of all the entries for a single activity in the assembled classes table. I found that this activity had 5 entries, with various compilation dates:
I have a (partial) snapshot of the VTable cache (copied from the pr_sys_rule_impl table) which shows that, for the particular node in question, we had 2 VTable entries for the activity which pointed to 2 of the 5 assembled classes shown above ( match the hash strings), and one which was empty, indicating it had not yet been compiled:
Looking at the output of the VTABLE as provided by the SMA tool for the same snapshot immediately above, you can see how you can proceed from a named rule with a particular pzInsKey to the particular assembled class, with the date of that assembly. Here is a snapshot of that VTable where I draw your attention to the activity rule with pzInsKey ending in ".811". It points to the assembled class with hash "_202"
For our particular case, following the chain allowed us to see that the assembled class had been built on December 10; that is the VTable for the version of the rule with pzInskey ending in ".811" used a compiled class which had been built on December 10, 2018.
Note also that the version of the rule with pzInsKey ending in .345 shows as empty. This version of the rule is probably not being used, hence it has not been compiled.
I'm not sure if this has clarified or confused things for you -- but now you know!