Can extract marker be cleared via SMA?
Our production filesystem access has greater restrictions to it than our restart control.
Sometimes (regrettably) it's necessary to go nuclear and clear the PegaRULES_Extract_Marker.txt file.
Is that possible through SMA? I thought there was at one point, but I can't find it.
Pegasystems Inc.
US
Hi Jon,
SMA has an option to recompile libraries if that is sufficient to address the issue. It is the Rule Utility Library Extractor in the Administration section of SMA. You can recompile certain libraries or all of them.
BNY Mellon
US
But it's not sufficient. As we know, ExtractMarker clears PRGenJava. I believe it also wipes the AssembledClasses table (though the latest v7.1.7 still refers to the pre-v6 "PRGenClass directories").
Unfortunately, the most common solution is to clear the ExtractMarker. We want to stop doing that.
Pegasystems Inc.
US
Agreed completely, this would be a good future enhancement. The justification can also be maintenance related - imagine 50 nodes - besides restriction on file access.
Pegasystems Inc.
CA
Let's see if my summoning Product Owners works as well this time:
James Henson - I believe you own System Management
Pegasystems Inc.
US
Clearing the marker file does not clear the assembled classes in PRPC 6.1 or higher. It does clear cached static content, lookup lists, libraries, and miscellaneous other temp files.
BNY Mellon
US
Indeed.
The question is, what impact does clearing the generated Java have?
When the server restarts, it will generally re-load the rules assembly cache from the database. Does deleting the Java have any impact on the rule cache? If the cache is invalidated, and a rule needs to be regenerated, reassembled & loaded, does the presence of Java tell the engine to skip regeneration? (and thus, the absence of it, would force the regeneration, which supposes that there was an error in generation.
The context here is that deleting the extract marker is often given as a necessary elixir to be undertaken for installs big & small, both from Pega GCS, and echoed in folklore as well ("we did this all the time at the place I last worked"). Sometimes it works for clearing a rule cache problem; sometimes it's not a cache problem at all, but our production support team wants to make sure they've done "everything" (everything simple that is).
This all begs the question/idea I asked in March -- it would help just about all of us to have the UX of opening up a rule and checking all representations of it (generated Java / assembled class / loaded in ClassLoader / cache entries)
Indeed.
The question is, what impact does clearing the generated Java have?
When the server restarts, it will generally re-load the rules assembly cache from the database. Does deleting the Java have any impact on the rule cache? If the cache is invalidated, and a rule needs to be regenerated, reassembled & loaded, does the presence of Java tell the engine to skip regeneration? (and thus, the absence of it, would force the regeneration, which supposes that there was an error in generation.
The context here is that deleting the extract marker is often given as a necessary elixir to be undertaken for installs big & small, both from Pega GCS, and echoed in folklore as well ("we did this all the time at the place I last worked"). Sometimes it works for clearing a rule cache problem; sometimes it's not a cache problem at all, but our production support team wants to make sure they've done "everything" (everything simple that is).
This all begs the question/idea I asked in March -- it would help just about all of us to have the UX of opening up a rule and checking all representations of it (generated Java / assembled class / loaded in ClassLoader / cache entries)
BNY Mellon
US
Better question - can it be cleared programmatically?
Why yes, it's as easy as this:
PRFile ExtractMarker = new PRFile("PegaRULES_Extract_Marker.txt");
ExtractMarker.delete();
So, to expose this to sysadmin, we can wrap a service rule around it (so that we could clear these across a cluster, if needed)
It would be nice to easily hook this into SMA in the future.