tracker issue : CF-4118903

select a category, or use search below
(searches all categories and all time range)

[ANeff] Bug for: Security Analyzer extremely high CPU usage

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Aaron Neff / Aaron Neff (Aaron Neff)

Created: 02/17/2016

Components: Security Analyzer

Versions: 2016

Failure Type: Performance Issue

Found In Build/Fixed In Build: CF2016_Final /

Priority/Frequency: Critical / Some users will encounter

Locale/System: English / Platforms All

Vote Count: 1

Listed in the version 2016.0.01.298513 Issues Fixed doc
Verification notes: verified_fixed on September 29, 2019 using build 2016.0.01.298513
Security Analyzer extremely high CPU usage

Repro 1:

From 2+ machines, I ran Security Analyzer on projects using the same CF2016 server.

Repro 2:

1) Ran Security Analyzer against a project
2) Got "read timeout" error
3) Increased RDS timeout from 30sec to 60sec
4) Ran Security Analyzer against same project
5) Got "read timeout" error
6) "Adobe ColdFusion Launcher Application" CPU usage jumped from ~1% to 94% and remained there (see attached screenshot)
7) Closed ColdFusion Builder
8) "Adobe ColdFusion Launcher Application" CPU usage remained around 94%
9) Attempted to restart CF2016 via the Windows Services applet
10) CF2016 failed to restart. It eventually stopped. But I had to then start it manually.

I can easily bring my machine to 100% CPU usage by doing this:

1) Run Security Analyzer
2) See timeout error thrown
3) Increase RDS timeout
4) repeat 1-3 a few times

So.. imagine multiple developers simultaneously trying to analyze their code against the same CF server. I can bring mine to 100% CPU w/ just 2-3 requests.

This isn't good b/c Security Analyzer isn't supported against the Developer Edition. Since an Enterprise license allows the key to be installed on a single development server, there will be multiple developers analyzing their code against the same CF server.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4118903

External Customer Info:
External Company:  
External Customer Name: Aaron Neff
External Customer Email:


  1. February 18, 2016 00:00:00: 1_20160217_Bug_4118903.jpg


Related thread:
Comment by External U.
4677 | February 17, 2016 06:43:42 PM GMT
Uday, can you break down the bug in two parts. CFB and server
Comment by Awdhesh K.
4678 | March 01, 2016 06:06:36 AM GMT
Hi Awdhesh, Do you mean close this ticket and create 2 new tickets (in public tracker I hope)? I would still like to track this. Thanks!, -Aaron
Comment by External U.
4679 | March 11, 2016 02:20:42 PM GMT
Sorry Aaron, that comment was meant for internal purpose. Actaully there are two different areas where the code changes are required, one is at server level and another in CFB thats the client for SA service. As these two are being handled by two different teams. So I Asked them to break in two parts one each for individual team.
Comment by Awdhesh K.
4680 | March 15, 2016 11:42:50 PM GMT
In the old design multiple scans were getting triggered even if they were not intentional. For example in the current bug user ended up running SA multiple times after changing the RDS timeout each time. This resulted in multiple scans on server side. As each scan is resource intensive we should avoid such situations. So we have done following changes in the current design : 1. Old implementation was synchronous , now it will be asynchronous. So RDS timeout issue will not come in the picture 2. Builder will constantly poll for current status of the scan from the server and show a progress bar at the bottom 3. Once a scan is triggered, Run SA option will be disabled till scan is over. So we can trigger only one scan at a time from the same builder 4. User will have an option to cancel the current scan and start a new one 5. Users can now also choose multiple files/folders to run a scan. So if only 2 files need to be scanned, user can choose them instead of choosing the parent folder 6. At server side we spawn multiple threads to scan the files. Number of threads will be equal to number of cores of the server. 7. Currently we have also exposed THREADCOUNT to client for testing purpose. Testing team can use this parameter to arrive at best possible thread count for running these scans. It will removed later on As I have said SA scans are CPU intensive as expected. Apart from few optimizations on serverside related to thread count we have minimized the scenarios in which users can trigger false and unintentional scans
Comment by Uday O.
4681 | March 16, 2016 01:19:46 AM GMT
We have also added a server side thread to clean the scan results from the cache at regular intervals so as to avoid memory leakage.
Comment by Uday O.
4682 | March 16, 2016 01:22:02 AM GMT
I also have experienced this bug. Same error message.
Vote by External U.
4683 | March 16, 2016 06:09:52 AM GMT
Hi Adobe, I've verified this is fixed in CF2016 Update 1 (build 2016.0.01.298513). Thanks!, -Aaron
Comment by Aaron N.
31455 | September 29, 2019 06:31:37 AM GMT