locked
WCF service is not returning any data if it has to return large data from database. RRS feed

  • Question

  • Hi,

    We are using WCF service to retrieve search results from Sql server db. The search results data can be in thousand’s or 100 thousands. We are using Silver light as front end to hit WCF service.
    If the search results are less than WCF servicing returning the data, if the results are more say for example >10,000, WCF service not returning any results. It is showing “An exception occurred during the operation, making the result invalid.  Check InnerException for exception details.” exception. We provided the maximum size for
    maxBufferSize="2147483647" and maxReceivedMessageSize="2147483647", but still no use.

    WCF service returning System.Collections.Generic.List, list collection type.

     

    If any one of you come across this scenario please share your experience.

    Your help will be appreciated.

     

    Thanks,

    Sapelly Srikanth



    Thursday, August 18, 2011 7:55 AM

Answers

  • Hello,

    Use the following setting it will work:

     

    <dataContractSerializer maxItemsInObjectGraph=2147483647>

     


    • Proposed as answer by DPS Bali Friday, August 19, 2011 11:48 AM
    • Marked as answer by Yi-Lun Luo Wednesday, August 24, 2011 9:26 AM
    Thursday, August 18, 2011 3:38 PM

All replies

  • If possible, I would cut the response. Pull certain number of records and then retrieve the rest like paging.
    Thursday, August 18, 2011 9:35 AM
  • I have other functionality as well in the silver light page that is export to excel the entire data, so i can't do that. I am able to retrieve 8000 records, if the stored procedure is returning 9000 records, it is throwing exception.

     

    "This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details"

     

    Thanks,

    Sapelly Srikanth

     

    Thursday, August 18, 2011 10:51 AM
  • Hi Shree,

    I can understand u can't use paging due to ur export functionality. But u need to understand that u cannot transfer data more than ur MaximumReceived/Buffer size specified.

    I am also having same requirement at my end and guess what I resolved the issue using paging only.

    I only transferred limited record from server to client. Rest of the records I have cached at my server which would be invalidated based on caching policy.

    While exporting data I make call to server and get the chunks of records one by one and exported it to excel or other format.

    This might effect the performance a bit but will not be a catastrophic downfall.

    Hope it helps!.

    Please mark it as an asnwer if it helps.

    Thanks,

    Parth Shah

    • Proposed as answer by parth.shah Thursday, August 18, 2011 3:06 PM
    Thursday, August 18, 2011 3:06 PM
  • Hello,

    Use the following setting it will work:

     

    <dataContractSerializer maxItemsInObjectGraph=2147483647>

     


    • Proposed as answer by DPS Bali Friday, August 19, 2011 11:48 AM
    • Marked as answer by Yi-Lun Luo Wednesday, August 24, 2011 9:26 AM
    Thursday, August 18, 2011 3:38 PM
  • All these suggestions might get your service to work, but you're better off solving the actual issue: Your messages are too large!

    If you need to transfer very large amounts or objects over the wire, consider implementing Paging or Continuation Tickets in your web service interface. That way you can get your data using a couple of smaller requests.

    Paging includes a start index and a number of results to fetch, a continuation ticket approach returns a unique id which you can use to fetch the next set of data. As long as you keep returning a continuation ticket, there is more data available.

    This should make your services a lot more scalable and prevents you from having to change the default buffer sizes, object graphs and other properties that govern the datacontract shape (if you change the settings, you need to change them on both sides, service and client):

    <bindings>
     
    <webHttpBinding>
       
    <binding name="LargeWeb"
                 
    maxBufferPoolSize="1500000"
                 
    maxReceivedMessageSize="1500000"
                 
    maxBufferSize="1500000">
         
    <readerQuotas
               
    maxArrayLength="656000"
               
    maxBytesPerRead="656000"
               
    maxDepth="32"
               
    maxNameTableCharCount="656000"
               
    maxStringContentLength="656000"
               
    />
       
    </binding>
     
    </webHttpBinding>
    </bindings>
    http://stackoverflow.com/questions/1188731/setting-max-message-and-buffer-size-for-wcf-webhttp

    Thursday, August 18, 2011 7:31 PM
  • Thanks Parth for your help.

    So there is no other alternative to get all the data(large data more than 8000 records) without using paging?

    We are sure that our data is returning far less than 2 GB data(2147483647), when we have 8000 records the approximate size of data is 64kb, when we have 9,000 recrods it is not handling the size, and still it is far behind the actual max limit.

     

    your help is appreciated.

    Thanks,
    Shreecanth


    Friday, August 19, 2011 9:35 AM
  • Hi,

    Adding following entry at the service web.config file resolved the issue.

    <dataContractSerializer maxItemsInObjectGraph=2147483647>

    Thanks very much.

    Thanks,
    Shreecanth



    • Marked as answer by Yi-Lun Luo Wednesday, August 24, 2011 9:25 AM
    • Unmarked as answer by Yi-Lun Luo Wednesday, August 24, 2011 9:26 AM
    Friday, August 19, 2011 10:09 AM
  • Hi there, i have a similar problem with service and client. i can retreive only up to a certain number of records to the client.

    can you please explain how to implement the MaxItemsInObjectGraph for both the service and the client. i dont have an app config file for the service as the service is started through a winform


    james
    Thursday, November 17, 2011 3:29 PM