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:
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.