System.Net.WebException when calling a webservice

Discussion in 'ASP .Net Web Services' started by atip, Jun 10, 2004.

  1. atip

    atip Guest

    I am calling a web service that takes a long time to process.
    In Windows 2003 Server I get a System.Net.WebException error
    The underlying connection was closed: An unexpected error occurred on a receive

    If I turn off the keep alive check box in the web site properties, it runs with no problems.
    I have tried to set the KeepAlive to False and the protocol to HTTP 1.0 for the WebRequest, leaving the general site KeepAlive option active, but with no success.

    Thanks for any help, workarounds or suggestions for other implementations.
     
    atip, Jun 10, 2004
    #1
    1. Advertising

  2. atip

    [MSFT] Guest

    Hello,

    A web service excuting has some timeout settings as follows:

    1.<httpRuntime executionTimeout = "???"> in Machine.Config This one is
    concerned with the ASP.NET web application's runtime timeout property, and
    in dotnet, the machine config always provide a default setting for all the
    application. So you can override them in the applicaiont's config file. For
    example as the ASP.NET web application or web service, you can override it
    by modifying the "httpRuntime" element's "Timeout" attribute .

    2. <sessionState timeout = "???"> in Web.ConfigThis "timeout" is set for
    the asp.net web application's session state, not
    the limit for the serverside's executing time

    3. <httpRuntime executionTimeout = "???"> in Web.Config The same as in the
    machine.config but can override the value in
    machine.config

    4. responseDeadLockInterval attribute of the <processModel> tag

    You may change this value to see if it will help.

    Additionally, on client side, the web service proxy client also has a time
    out property. The default proxy timeout value for the client is 100
    seconds. You can modify the proxy timeout value by using the timeout
    property of the proxy as follows:

    webserver.Service1 ws = new webserver.Service1();
    ws.Timeout = System.Threading.Timeout.Infinite;

    Hope this help,

    Luke
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)
     
    [MSFT], Jun 11, 2004
    #2
    1. Advertising

  3. atip

    atip Guest

    Hi Luke,

    I have set all the settings way high and I'm still getting the error.
    Enabling the processModel and setting the responseDeadlockInterval, gives me an error in the async call to the web service.

    BTW the ws works fine on Windows 2000, and it also works if I set the KeepAlive Timeout for the site to a higher value in Windows 2003 server. If instead of doing this, I uncheck the keepalive option for the site, the app raises the exception too (this was an error in my initial post, sorry!).

    I am using VS.NET 2003, .NET FWK 1.1, and Windows 2003 Server.

    Thanks,

    Antonio Iglesias.
     
    atip, Jun 11, 2004
    #3
  4. atip

    [MSFT] Guest

    [MSFT], Jun 14, 2004
    #4
  5. atip

    atip Guest

    Hi Luke,

    Yes, setting the timeout high is a workaround.

    I had already tried this. I found it surfing the net prior to posting the question, but
    it did no solve my problem. Actually, when I set the KeepAlive=False on site's configuration I keep getting the error. It only works when I set the timeout high and KeepAlive=True.

    Do you have any other idea?

    Regards,

    Antonio.
     
    atip, Jun 14, 2004
    #5
  6. atip

    [MSFT] Guest

    [MSFT], Jun 15, 2004
    #6
  7. atip

    atip Guest

    Hi Luke,

    I was already calling the web service with an asynchronous call, since it takes so long to complete.

    Do you believe that if I do a synchronous call the behaviour of IIS may be different?

    Regards,

    Antonio.
     
    atip, Jun 15, 2004
    #7
  8. atip

    [MSFT] Guest

    Hi Antonio,

    I don't think synchronous call will help on this issue. It look to me that
    we can only set keep-alives to true for the issue.

    Luke
     
    [MSFT], Jun 16, 2004
    #8
  9. Hi Antonio,

    I think the main concern here is that the method in the web service takes too long time. So there is no way for any client to improve the response
    time. Synchronous and ASynchrionous won't help to improve the response time under this situation.

    Thanks.

    Best regards,
    Yanhong Huang
    Microsoft Community Support

    Get Secure! ¨C www.microsoft.com/security
    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Yan-Hong Huang[MSFT], Jun 18, 2004
    #9
  10. atip

    atip Guest

    Hi,

    The web service is a heavy financial calculation. If I split the single call into several small calls the overall time will be increased tremendously and the system will have to control session state between calls. The calculation is being perform today in a Excel spreadsheet, and the objective is running the same calculation in a multithreaded app running on a server. Performance is the main objective. Compiling and splitting the calculation on several threads has done the trick (the calc time has gone down to 1/10 of the time with the same hardware).

    I am happy with the time it takes to compute now. My concern is that the connection breaks while performing the calculation, thus not being able to return the results to the client. This calculation may take from 1' to 20' in the worst case.

    I feel setting the keep alive timeout to a higher value for the whole site may impact other applications that may run on the server. That's why I do not like that workaround.

    I know that sync vs async won't help making the call faster, it only helps with responsiveness of the UI. What I was asking was whether or not making a synchronous call would help keeping the connection alive. I believe not, but that was my question for Luke.

    Thanks for your reply.

    Antonio.
     
    atip, Jun 18, 2004
    #10
  11. Hi Antonio,

    Thanks for your quick update. Based on my experience, you may consider "Asynchronous XML Web Service Methods". Please refer to
    http://msdn.microsoft.com/library/d...onCreatingAsynchronousXMLWebServiceMethod.asp for
    how to do it.

    Regardless of whether or not an XML Web service method is implemented asynchronously, clients can communicate with it asynchronously.
    Asynchronous communication is exposed to .NET clients within the proxy class generated by the Web Services Description Language
    (WSDL.EXE) tool, even if an XML Web service method is implemented synchronously. However, implementing an asynchronous XML Web
    service method has no impact on the HTTP connection between the client and the server hosting the XML Web service. The HTTP
    connection is neither closed nor pooled.

    Also, I recommend one good article for you:
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenet.asp
    Please refer to the following two part:
    Asynchronous Invocation
    Timeouts

    This article also introduct many other tips in web service programming. They may not be directly helpful for this issue. But I hope it could
    benefit you in the future. :)

    Best regards,
    Yanhong Huang
    Microsoft Community Support

    Get Secure! ¨C www.microsoft.com/security
    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Yan-Hong Huang[MSFT], Jun 18, 2004
    #11
  12. atip

    atip Guest

    Hi,

    so is there any other way to keep the connection alive?
    Should I forget about webservices for this solution and look at other implementations? Or should I trade some of the performance gains because IIS breaks the communication?

    Thanks for the pointer to the article about performance. I will definately read it.

    Regards,

    Antonio.
     
    atip, Jun 18, 2004
    #12
  13. atip

    [MSFT] Guest

    Hi Antonio,

    If it was a internal application, you may consider .NET remoting instead of
    web service. If iy was a application on internet, web service may be the
    only choice. We have to give up some performance to gain reliability.

    Luke
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)
     
    [MSFT], Jun 21, 2004
    #13
  14. Hi Antonio,

    KeepAlive=True and enlonging time out value is the correct way to keep connections alive.

    For others, I think Luke has answered it.

    Thanks very much.

    Best regards,
    Yanhong Huang
    Microsoft Community Support

    Get Secure! ¨C www.microsoft.com/security
    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Yan-Hong Huang[MSFT], Jun 23, 2004
    #14
  15. atip

    atip Guest

    Yan-Hong,

    if that is the way to go that's what I'll do.

    Thanks.

    Antonio.
     
    atip, Jun 24, 2004
    #15
  16. You are welcome. :)

    If there is any more questions, please feel free to post in the group.

    Have a good day.

    Best regards,
    Yanhong Huang
    Microsoft Community Support

    Get Secure! ¨C www.microsoft.com/security
    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Yan-Hong Huang[MSFT], Jun 24, 2004
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    2,818
    Kevin Spencer
    Sep 30, 2005
  2. Sean Erwin
    Replies:
    1
    Views:
    3,461
    Feroze [MSFT]
    Jan 2, 2004
  3. Steven Cheng[MSFT]
    Replies:
    4
    Views:
    1,659
    Steven Cheng[MSFT]
    Apr 8, 2004
  4. Lisa Ngo
    Replies:
    3
    Views:
    460
    Jan Tielens
    Jan 18, 2004
  5. Greg

    WebException when accessing webservice via proxy

    Greg, Mar 15, 2006, in forum: ASP .Net Web Services
    Replies:
    4
    Views:
    156
Loading...

Share This Page