000033177 - Unable to export RSA Archer reports with many records: An error has occurred during the export process. The export file cannot be completed.

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support on Jan 23, 2018
Version 4Show Document
  • View in full screen mode

Article Content

Article Number000033177
Applies ToRSA Product Set: Archer
RSA Product/Service Type: Archer
RSA Version/Condition: 5.2, 5.3, 5.4, 5.5
Platform: Windows
Platform (Other): IIS
O/S Version: Windows
 
Issue
When attempting to export large reports containing thousands or tens of thousands of records, users may receive the following message:

 

An error has occurred during the export process. The export file cannot be completed.

 
User-added image

This issue is seen primarily with exporting data in CSV and XLSformats, however the failures are not exclusive to these formats. 
CauseOne possible cause of this failure can be found in the Application Pool Recycle settings.  If you have the Application Pool configured to recycle based on a memory threshold, this threshold can be easily reached when exporting large reports which causes the Application Pool to reset and the export to fail. 
 
Resolution
To resolve the issue, change the Application Pool Recycle setting to a time based limit rather than a memory based thresholds.  An example of the recommended settings are shown below:
 

User-added image

From experience, it is recommended to set the regular time intervals value setting to 1440, which is 24 hours and also setting specific time(s) to a fixed time when it is anticipated that traffic will be low (e. g., 4:00 AM ET/1:00 AM PT in the US).   Setting the value to a fixed time each day during the lowest traffic times will minimize any impact and also allow you to troubleshoot easier if you run into any issues. If you have multiple application pools, it might be wise to stagger them to avoid overloading the server with recycles.  Also note that IIS overlaps the app pool when recycling, so there usually isn’t any true downtime during a recycle. Existing actions will continue to process until complete and any new actions will be picked up by the newly spawned worker process. However, in-memory information, such as session state, etc., would be lost.
WorkaroundOther than the option of exporting smaller reports, no other workaround is currently known. 
NotesNote the information included below 

Application Pool Recycle times


  Microsoft IIS Server has the application pool recycle time default to 1740 minutes, which is exactly 29 hours.


User-added image



For a situation where you don’t know the environment, 29 hours is probably a good default starting point. However, as an archer administrator you will likely be familiar with your environment, and it may be best to change this after days or weeks of monitoring and analyzing your site traffic. It is recommended to set this to a fixed time (like 4:00 AM ET/1:00 AM PT in the US).  Setting it to a fixed time each day during low traffic times will minimize the impact and also allow you to troubleshoot easier if you run into any issues. If you have multiple application pools, it might be wise to stagger them to avoid overloading the server with recycles.


User-added image


Note that IIS overlaps the app pool when recycling so there usually isn’t any true downtime during a recycle. Existing actions will continue to process until complete and any new actions will be picked up by the newly spawned worker process. However, in-memory information (session state, etc) would be lost.
In theory you don’t really need a daily recycle unless you have a known problem. A daily recycle is just a preventative measure to refresh IIS in case there is a slight memory leak or anything else that may slowly creep into the worker processes. Keep in mind that you can turn it off completely however, it is a recommend setting it to recycle once per day at an off-peak time as a proactive measure.


  
Idle Time-out


While on the topic of app pool defaults, there is one more that you should consider changing with every new server deployment. 
The Idle Time-out should be set to 0 unless you are doing bulk hosting where you want to keep the memory footprint per site as low as possible. 

 


User-added image


If you have a just a few sites on your server and you want them to always load fast, then set this value to zero. Otherwise, when you have 20 minutes without any traffic (unlikely in a busy Archer environment, but still plausible) then the app pool will terminate so that it can start up again on the next visit. The problem (albeit minor) is that with the first visit to the site, an app pool needs to spin up a new w3wp.exe worker process which can be slow because the app pool needs to be created, ASP.NET or another framework needs to be loaded, and then your application needs to be loaded. That can take a few seconds. Therefore, from experience, it is recommended to set that to 0 when possible, unless it’s for a server that hosts a lot of sites that don’t always need to be immediately available. 

Attachments

    Outcomes