Skip to Content
0
Former Member
Jun 04, 2013 at 06:02 PM

Pinpointing the root cause for maximum report processing jobs limit configured...

34 Views

Attn: Ludek Uher...You seem to have the most knowledge in this area

To start off I wanted to mention that I in customer support and not a developer, so some of the responses I might have to filter through my development team. I am looking for a way identify what is causing the the "The maximum report processing jobs limit configured by your system administrator has been reached". There are numerous posts associated with this topic which seem to seek a solution rather than determining the root cause before implementing a solution. This is a different approach and one that would help me troubleshoot future issues with the CR Runtime, so I can provide some guidance on where to focus the development team when implementing the solution.

How I perform my job is to look on the web and database server for clues as to where the problem originates from. This seems to work the best instead of randomly performing Goolged solutions with the hope of correcting the problem. On to the problem...

We are looking at a VB 6/ C+ application that uses the CRVS2010 CRRuntime_64bit_13_0_5 to present the report to the end-users. The web server is Win 08 R2 which we configure the application in IIS. In IIS, we have a seperate application pool configured to operate the reporting solution in 64 bit mode using .NET framework 2.0.5. The core application would refer calls to the .NET CR reporting solution and use the Runtime to present the end-user the actual report they requested.

Some additional things we configure on the web server and in IIS:

  • in the web config file we set the RepExpireTime to 60 minutes as some users need to view the report for a period of time
  • We run the applciation in classic mode instead of integrated
  • We normally recyle the application pool at 4 am
  • Set the idle timeout for the application pool to 60 minutes
  • The application pool uses the applicationpoolidenity
  • The application (site) uses the local user account we create which is simply in the Guest group
  • The application (site) folder has the above local user account assigned with read and execute security rights
  • We change the registry HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Report Application Server\Server\PrintJobLimit to -1 instead of the default 75 value
  • We add the local user (mentioned above) and the Network Service accounts to the folder C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files with modify rights



This setup appears to work fine and with various users we do not have any issues. It appears that with more users (unknown number) the error would appear for the maximum number of print jobs have been reached.

I have looked through the event logs on the web server, but I do not see anything that suggests reports are being queued up. I do not see anything else that would support any of the possible corrections that hundreds of people have suggested. Some are code changes to close out the temporary files after they are used, additional registry values hacks to change the number of reports, and various code changes to manage the reports with slow points, etc.

If I knew how to configure the server or use another tool to pinpoint the area that is causing the issue than I can have my development team focus their efforts in that area. This is not an unreasonable request from my standpoint.

Thoughts...

Roy