Subscription error:Maximum request length exceeded

  • I have a saved subscription and when I edit it I get the following error:

    Maximum request length exceeded.

    I'm not sure what the problem is as I have never seen this error. If I delete the subscription and re-create it with the changes I want it works fine.

    Any help is greatly appreciated.

    Thanks,

    Marc

  • Hey

    check out the post below.

    http://support.softartisans.com/kbview_825.aspx

  • Seems to be a bug in Reporting Services.

    I came across the same error when trying to alter one of the Subscriptions which was on a Shared Schedule in Reporting Services i.e thru website(http://Servername/Reports/Pages/Folder.aspx)

    Deleted the Subscription & tried to recreate it so it could use a Custom Schedule & write the file to Windows Fileshare but it gave me the same error. However, was then able to create the subscription from the Management Studio after connecting to Reporting Services.

    Try Browsing thru to that Report under Home--> Reports Folder--> Report Name--> Subscriptions.

    You should be able to create/modify/delete subscriptions from here i.e even set schedules,parameters etc.

    Regards,

    Neeraj

  • It's a limit in system.web - http://weblogs.asp.net/hosamkamel/archive/2007/09/18/resolving-maximum-request-length-exceeded-exception.aspx

    I changed the web.config under the reports and reportserver virtual directories to this to resolve the error:

    It turns out that there is another limit at 64MB so any value larger than 65536 won't matter, but I haven't been able to determine where that limit is being set.

  • Hello :

    I am having a same issue.

    SSRS 2012 upgraded from SSRS 2005 few years ago.

    <httpRuntime maxRequestLength="1048576" executiontimeout="10800" />

    I checked the web.config file and it is set to 1048576. much beyond the 655267 value mentioned by someone. ( 64 MB hard limit)

    I get this error when I try to create a new or edit an existing subscription .

    Maximum request length exceeded.

    I am seeing this error only now.

    Existing subscriptions seem to be running fine.

    Any help is appreciated.

  • Did you use the code that was listed at the link I posted to determine the request size? Solving this when it's just over the 64MB hard limit will likely be very different than if the request is way over the limit. As a test for at least a more immediate workaround, what about copying an existing subscription and modifying it to fit your need for one of the new subscriptions? Perhaps you could also take a look at the rows in the report server database to se if the requests are significantly different between the new and old. I would not be surprised to se the new requests somehow adding overhead that could likely be removed by changing some report server options.

  • Thank you for the response.

    There is something funky about this particular report. The report was auto upgraded when SQL 2005 was migrated to sql 2012 instance. It was never touched after that.

    In the subscription results in Reportserver DB execution log , I see some 22,000 rows but when i execute the same report manually I see one row.

    When I open the report in ReportBuilder and resave it , the file size increased to 147 KB from under 95 KB. Behaves same way .

    I copied the Report to some other folder and tried running.

    Modifying an existing subscription also does not work.

    New subscription does not go through .

    Short of abandoning the Report and rebuild anew , I don't know what else to do.

    How do I check if the Report backend xml is malformed somehow?

    Any help or hint is appreciated to guide my thinking . and understanding .

  • I would think the best way to see what is going on is to do some tracing, the query in SQL Server, the network traffic using Wireshark or similar, and the HTTP stream using fiddler or similar. The SQL trace will show you if there are any strange results being returned by the query versus the manual execution, the network trace will show you the amount of traffic and any issues with TDS from SQL to the report service, the XML to the web server, and the web server rendering to the client. The HTTP trace will show any large objects from the HTTP pipeline and may help pinpoint which subsystem is the cause of the issue. Keep in mind that the error is pointing to the HTTP request length, so I would actually start by looking at the request from the client to the web server, and then check the request from the web server to SSRS first. Perhaps something in the report RDL is causing a rather large HTTP request to be sent.

  • Hi All ,

    Just wanted to update the issue with this resolution :

    The settings were missing in the web.config in the ReportManager folder.

    After we made the change and restarting the SSRS Service , I were able to make edits to the Subscriptions .

    However , I am not sure as to why the number of rows column would be different form what we see in the report or the output of backend query. Where as the extended info shows correct number of rows.

    RowCount = 23894 in ReportServer DB

    where as teh AdditionalInfo xml is this :

    <AdditionalInfo>

    <ProcessingEngine>2</ProcessingEngine>

    <ScalabilityTime>

    <Pagination>0</Pagination>

    <Rendering>0</Rendering>

    <Processing>0</Processing>

    </ScalabilityTime>

    <EstimatedMemoryUsageKB>

    <Pagination>3</Pagination>

    <Rendering>11</Rendering>

    <Processing>2</Processing>

    </EstimatedMemoryUsageKB>

    <DataExtension>

    <ORACLE>16</ORACLE>

    </DataExtension>

    <Connections>

    <Connection>

    <ConnectionOpenTime>1</ConnectionOpenTime>

    <DataSets>

    <DataSet>

    <Name>backenddata</Name>

    <RowsRead>1</RowsRead>

    <TotalTimeDataRetrieval>8</TotalTimeDataRetrieval>

    <ExecuteReaderTime>8</ExecuteReaderTime>

    </DataSet>

    </DataSets>

    </Connection>

    </Connections>

    </AdditionalInfo>

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply