com.pega.pegarules.priv.generator.LibrarySupport::resolveAndInvokeFunctionViaReflectionWithException
We are implementing retention program and while we are load testing in pre-production, we found a function that is being invoked while invoking the decision flow in Pega. The function resolveAndInvokeFunctionViaReflectionWithException is getting executed which takes around 1.2 sec at an average. Does anyone know what this function does and why its getting invoked. We did not see this in development.
Our development environment are in AWS and Preprod in on premise - Solaris Sparc system. Please see the attached wily report herewith as well.
What is this function and why its getting executed? Any clue will he helpful.
***Edited by Moderator Marissa to update SR Details***
Accepted Solution
Pegasystems Inc.
US
Upon reviewing your Support Request, SA-56245 The 'use fast processing' mode does not work in Service-REST was generated as a resolution. If you have the same question, please refer to this SA.
Pegasystems Inc.
US
Hello & thanks for the inquiry!
That method is part of the Core Engine APIs for running all Rule Utility Functions. What release are you using?
I assume you're running 7.2.2 or higher.
That method will show up in your call tracing under these conditions
1) when one Rule Utility Function is directly calling another Rule Utility Function
2) when a Java step in Activities are calling Rule Utility Functions
The time you see represented from Wily report will include the time it takes to actually execute the RUFs. Therefore, that accumulated value of 1.2 seconds is dominated by the time it takes to run the business logic inside all the RUFs, plus a some small overhead for the reflective call to execute RUF.
Hope that helps explain it
Pegasystems Inc.
US
Is there a way to optimize this? Our SLA is that the request and response should be under 1 sec and in this case this function alone takes 1.2 sec and overall response time is 2.3sec which throws off the SLA. What are these RUF? Why it is needed to run when we try to invoke the decision strategy in Pega 7.3.1? What are our options to suppress it?
A quick response is highly appreciated.
Pegasystems Inc.
US
Hello kadua
Thanks for the response & context. This internal engine API is used to run whatever RUFs the decision strategy needs. Let's pull in some Decisioning experts to look at how the RUFs are used in there. Sorry, I'm not familiar with Wily tools. Can we trace into the classes that resolveAndInvoke is calling?
That can identify the list of RUFs & RULs being used in this use case. They'll be assemble Library & Function classes in the com.pegarules.generated package.
Pegasystems Inc.
US
Hello again Arun
is it possible for you to share some deeper profiling information on what you see in resolveAndInvokeFunctionViaReflectionWithException()?
For example a Yourkit snapshot would help us look at what is being called from that api.
In the 7.3.1 release, calls to RUF are done in 2 ways and only 1 of those paths goes to LibrarySupport. resolveAndInvokeFunctionViaReflectionWithException()
- When assembling rules, the Expression parser does NOT generate code that calls LibrarySupport. Expression parser generates code like this
pega.<java.lang.Boolean>resolveMethodCall("hasMessages--(Page)", "hasMessages", null, null, new Object[] { myStepPage })
These always calls directly to Executable and do not go to Library Support. Therefore, your tracing data does not include RUF calls coming from expression parser generated code.
- The other way RUFs can be called is directly in assembled code that is like this example
com.pegarules.generated.pega_rules_default.hasMessages(myStepPage) ;
Calls like that can come from
Hello again Arun
is it possible for you to share some deeper profiling information on what you see in resolveAndInvokeFunctionViaReflectionWithException()?
For example a Yourkit snapshot would help us look at what is being called from that api.
In the 7.3.1 release, calls to RUF are done in 2 ways and only 1 of those paths goes to LibrarySupport. resolveAndInvokeFunctionViaReflectionWithException()
- When assembling rules, the Expression parser does NOT generate code that calls LibrarySupport. Expression parser generates code like this
pega.<java.lang.Boolean>resolveMethodCall("hasMessages--(Page)", "hasMessages", null, null, new Object[] { myStepPage })
These always calls directly to Executable and do not go to Library Support. Therefore, your tracing data does not include RUF calls coming from expression parser generated code.
- The other way RUFs can be called is directly in assembled code that is like this example
com.pegarules.generated.pega_rules_default.hasMessages(myStepPage) ;
Calls like that can come from
- Hand coded java in some other RUF
- Hand coded java from activity Java Step
These types of hardcoded calls are detected at class load time… and we use the Java 7 Invoke Dynamic feature to bytecode rewrite those hard coded calls. the rewriting changes those calls to deletgate to LibrarySupport. resolveAndInvokeFunctionViaReflectionWithException()
Both LibrarySupport and the Executable.resolveMethod call end up delegating down to other code that actually uses reflection to call the RUF.
That's why I want to look inside what resolveAndInvokeFunctionViaReflectionWithException() is doing. It will tell us which hard coded RUFs your app/use case is calling. That will allow us & you to focus on those specific Rule Utility Functions
Thanks
Todd
Pegasystems Inc.
US
Hello again Arun, how are you?
It would be best to have some profiling tool (yourkit, wily, whatever) that can drill in and show us where all the time is being spent inside the resolveAndInvokeViaReflection....
That method calls the actual RUFs. and I assume the majority of the time in resolveAndInvokeViaReflection is spent in the java inside the RUF itself. For example if some RUF named myfunct(), has code that does a
Thread.sleep(2000) ;
Then resolveAndInvokeViaReflection would show a time spent of 2 s
Pegasystems Inc.
US
can you get any sort of profiling for the classes and methods called by resolveAndInvokeViaReflection ()?
That would point us to which RUFs in the rule base are taking so long and you/we could begin to optimize those.
resolveAndInvokeViaReflection will have a tiny amount of overhead due to java reflection. But that time will be far out-washed by the time spent in the actual RUFs
Pegasystems Inc.
US
Hello again Arun,
Thanks for the response. Right, that is the same screen shot from before. it shows us the time, but does not drill down to what is happening in each of these methods.
What I'm asking for is a profile that drills inside resolveAndInvoke. please see the example screen shot above. That shot is taken from a Yourkit snapshot. Please note it's sampling mode, so the times will not add up perfectly. From it, we can see that the vast majority of time in the resolveAndInvoke is actually inside the various RUFs that get dispatched to.
Is it possible for Wily to provide us that level of detail --- and show us what resolveAndInvoke calls?
Thanks
Accepted Solution
Pegasystems Inc.
US
Upon reviewing your Support Request, SA-56245 The 'use fast processing' mode does not work in Service-REST was generated as a resolution. If you have the same question, please refer to this SA.