A production system shows these symptoms:
- Application response time is poor
- PAL readings show that rules assembly is occurring, even though no new rules are being created, or very few new rules are being created.
- System Console (PRMonitorServlet), Class Loader Status page shows a large number (greater than 10) of invalidated classes
Understanding Rules Assembly
The first time that a particular rule is referenced (for a specific set of rule-resolution characteristics), Process Commander generates, compiles, loads, and executes the Java source code for a unique Java. This process is referred to as rules assembly (RA) or first use assembly (FUA). Subsequent references to the same rule (under the same rule-resolution characteristics) will re-use the same Java class that has been generated and compiled.
In an production system, users execute a stable collection of rules repeatedly, and rule updates or rule additions are rare. As a result, when a production user (or other requestor) needs to execute a rule, the system will find already assembled Java code a very high percentage of the time. When this does not happen, so that rules assembly continues to occur, the application's overall performance can be severely impacted.
Process Commander maintains a global First Use Assembly (FUA) cache for the system, as well as personal FUA caches for each user that has rule checkout enabled in their operator ID. In V4.2SP4, the maximum number of entries that can be held in each of these caches is 3,000. In V4.2SP6 and later, the
pegarules.xml defines a default of 20.000 entries.
When the FUA cache becomes full, i.e. reaches the maximum number of entries, Process Commander will remove the older entries, and in doing so will invalidate the associated Java classes.
If several distinct RuleSet lists are in use and / or users have rule checkout, you effectively get FUA cache duplication. For example, if for one user using the application there are 2000 FUA cache entries for their RuleSet list, then for 8 different users with different rule set lists there will be close to 16000 FUA cache entries. They are the same rules, but they have different FUA cache entries due to the different RuleSet list hash signatures.
In applications in which there are a large number of rules, having many distinct RuleSet lists and / or users with Allow rule check-out? enabled (on the Security tab of the Operator ID form) can result in continuous rules assembly. (This setting provides a personal, private RuleSet to the operator, so even if the operator never checks out any rule, the operator's RuleSet list is distinct from all other operators' RuleSet list, so each rule the operator executes is assembled just for that operator.)
Use the PAL performance tool to take PAL readings. Monitor the rules assembly readings. These should be low, ideally zero.
System Console (PRMonitorServlet)
Monitor the number of invalidated classes on the Class Loader Status page. This should be low, ideally zero.
Eliminate the distinct RuleSet lists that are not required
Review user RuleSet lists, which are derived from on the their organization setup, access group setup, and operator ID configuration. If there are users that have distinct RuleSet lists for no business reason, or if some users have rule checkout that should not, consolidate and remove those privileges as appropriate.
- Minimize the number of distinct access groups that are referenced in Operator ID, organization, and division data instances.
- Clear the Allow rule check box on the on the Security tab of the Operator ID form for all but those operators who truly need this capability in a production system.
Increase the FUA Cache Size
You can adjust the FUA cache configuration, including the maximum number of entries in the cache, in the fua node in the