function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Keith987Keith987 

Governor limit counting problem for managed package and additional code

Documentation like Understanding Execution Governors and Limits says that a managed package has a set of governor limits that are separate from the governor limits applied to the non-packaged source code in an org. This is the behavior we see in developer edition orgs: numbers are reported for the managed package(cve namespace) and non-packaged source code (default namespace) separately and no limits are exceeded and our tests all pass.

 

But after an upgrade of an org that we setup for a customer starting from a Trialforce snapshot, the counting appears to be combined and reported only under the non-packaged source code (default namespace) so that limits are exceeded and some of our tests fail.

 

Can anyne offer any insight into this problem? Below are fragments of debug log output that illustrate the problem. (There is mention of the cve managed package in both logs, just not in this fragment for the problem org.)

 

Thanks,

Keith

 

 

From the working (developer edition org):

 

 

02:22:24.379|CUMULATIVE_LIMIT_USAGE
02:22:24.379|LIMIT_USAGE_FOR_NS|(default)|
Number of SOQL queries: 0 out of 100
Number of query rows: 0 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 5 out of 150
Number of DML rows: 5 out of 10000
Number of script statements: 189 out of 200000
Maximum heap size: 0 out of 3000000
Number of callouts: 0 out of 10
Number of Email Invocations: 0 out of 10
Number of fields describes: 0 out of 100
Number of record type describes: 0 out of 100
Number of child relationships describes: 0 out of 100
Number of picklist describes: 0 out of 100
Number of future calls: 0 out of 10

02:22:24.379|LIMIT_USAGE_FOR_NS|cve|
Number of SOQL queries: 6 out of 100
Number of query rows: 6 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 1 out of 150
Number of DML rows: 1 out of 10000
Number of script statements: 442 out of 200000
Maximum heap size: 0 out of 3000000
Number of callouts: 0 out of 10
Number of Email Invocations: 0 out of 10
Number of fields describes: 0 out of 100
Number of record type describes: 0 out of 100
Number of child relationships describes: 0 out of 100
Number of picklist describes: 0 out of 100
Number of future calls: 0 out of 10

02:22:24.379|TOTAL_EMAIL_RECIPIENTS_QUEUED|0
02:22:24.379|STATIC_VARIABLE_LIST|
BusinessLogicBase:MONTHS:126
PaymentSpecificationPopulatorTest:BASE:4
PaymentSpecificationPopulatorTest:LUMP_SUM:8
PaymentSpecificationPopulatorTest:MONTHLY:7
PaymentSpecificationPopulatorTest:SCALE:4
PaymentSpecificationPopulatorTest:TODAY:4

02:22:24.379|CUMULATIVE_LIMIT_USAGE_END

 

 

From the failing (customer org:

 

 

01:35:40.307|CUMULATIVE_LIMIT_USAGE
01:35:40.307|LIMIT_USAGE_FOR_NS|(default)|
Number of SOQL queries: 6 out of 100
Number of query rows: 6 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 6 out of 150
Number of DML rows: 6 out of 10000
Number of script statements: 631 out of 200000
Maximum heap size: 0 out of 3000000
Number of callouts: 0 out of 10
Number of Email Invocations: 0 out of 10
Number of fields describes: 0 out of 100
Number of record type describes: 0 out of 100
Number of child relationships describes: 0 out of 100
Number of picklist describes: 0 out of 100
Number of future calls: 0 out of 10

01:35:40.307|TOTAL_EMAIL_RECIPIENTS_QUEUED|0
01:35:40.307|STATIC_VARIABLE_LIST|
BusinessLogicBase:MONTHS:130
PaymentSpecificationPopulatorTest:BASE:8
PaymentSpecificationPopulatorTest:LUMP_SUM:8
PaymentSpecificationPopulatorTest:MONTHLY:7
PaymentSpecificationPopulatorTest:SCALE:4
PaymentSpecificationPopulatorTest:TODAY:8

01:35:40.307|CUMULATIVE_LIMIT_USAGE_END

 

 

Best Answer chosen by Admin (Salesforce Developers) 
CyberGroup Inc.CyberGroup Inc.

I am curious to know if your app is an "Aloha" app?, if salesforce has marked you app as an aloha app it will not be counted against any governor limit of your client's org.

All Answers

CyberGroup Inc.CyberGroup Inc.

I am curious to know if your app is an "Aloha" app?, if salesforce has marked you app as an aloha app it will not be counted against any governor limit of your client's org.

This was selected as the best answer
Keith987Keith987

The app is not an Aloha app and AFAIK governor limit behavior isn't different just "Aloha Apps don’t count against your system limits for apps, tabs, and objects".

 

Keith

sham_1sham_1

I agree, with Keith987, as per the docs, managed package code limits should not be counted against the running org limits.

Aloha or not

Probably after the upgrade, the trialforce has lost the "managed" status.

Can you see your code in customer org ?

Seems like could be an SFDC issue

Keith987Keith987

The managed package is present and works correctly in the org. The only immediate problem we are seeing is the failing tests, but the same behavior (no separate governor limits) is being applied to the product code (according to the debug log) so having developed and tested with separate governor limit sets we are now running with only one.

 

Keith

Keith987Keith987

It turns out that Sankalp's comment a few replies ago was correct.

 

In response to me creating a case on this problem, the salesforce engineer "turned on the ALOHA perm for this package" and after a new package installation the governor limits are now being separately counted. Apparently this will apply for any new versons of the package we create too.

 

So in summary, my experiencee has been that the package always had its governor limits separately counted in free developer edition orgs but to get the same behavior in a Trialforce org a case was required to get the ALOHA permission set on the package and it appears that the salesforce documentation is not as complete as it might be on this.

 

Keith