Skip to Content

XI : The underlying connection was closed: An unexpected error occurred on a send

Scenario: You have exposed an outbound interface as a webservice in your central integration hub as enterprise webservice. A .NET application is using the webservice. Every works great during unit/integration testing. But out of the blue you are told that the webservice call to XI is failing with the following error message/stacktrace captured at the client(.NET Application)  System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request) at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at …  Solution : To begin with it not a XI Issue it is a common myth that any error generated during calling a webservice provided by XI is associated to XI. Especially when the error messages generated are so arcane!! .The exception shown above can be resolved by altering the proxy class generated by .NET from wsdl provided for the interface.  The exception can be attributed to the KeepAlive property which determines how long before the instance is garbage collected by CLR. By default is not set to false. As a result calls to the webservice results in many active instances and eventually the webservice throws the exception.  Resolution In the Solution Explorer window(VS.NET), navigate to: Web References  Open the Reference.cs(or .vb) file and add following code in the webservice proxy class: imageprotected override System.Net.WebRequest GetWebRequest(Uri uri) {  System.Net.HttpWebRequest webRequest =    (System.Net.HttpWebRequest) base.GetWebRequest(uri);    webRequest.KeepAlive = false;  return webRequest; } Compile you code…. This should fix the exception…
You must be Logged on to comment or reply to a post.
  • Would this issue cause the tread pool in XI to be exhausted?
    For example about every 8 days we have to restart the XI dispacher because all the XI adpaters RFC, Soap etc will stop accepting connections.  Our main service is proxied using a .NET web service without the above addition.

    Right before XI stops accepting connections the .NET webservice reports the above error in your posting.


    • Hello James,

      Underlying connection closed error can be caused by many reasons. Most common reason is due to the bug in .NET that has been fixed in ASP2.0

      Coming to your problem of restarting xi, we ran into the same issue. The problem is due to lack of resources. That if you have too many interfaces that take too mcuh of time to finish, this will first freeze up Adapter framwork. if you did not allocate the threads properly , everything will freeze up starting from Visual Admin, mapping and later all the components of XI.


      • Thanks for the response. I was just hopeing for a quick fix. We have been working with SAP for 3 months now for a fix. Our workaround is to redirect our proxy to a differnt XI server and restart the dispatcher and point it back.
        SAP has had us try several different J2EE versions to fix the issue with no luck. Our interfaces are sync but only last about 10sec max. For some reason when the messages have completed the Dispatcher doesn’t always release the thread.

        Our scenario: .net proxy service<->soapAdapter<->mapping<->RFC adapter->SAP (4.6C)

        Approximately 4,000 messages a day
        average duration <2 seconds to process. Around day 6-8 thread pool becomes exhausted and locks up just like in your post. Threads are allocated per SAP instructions and have been tweaked as instructed.

        Anyway sorry for getting your post off-topic.

        • Hi,

          We are getting around 20000 synchrounous calls in our production system. Most of our scenarios are like urs.

          did u increase the max thread count to 600 in visual admin??