I have a windows app connecting to a webservice. In some situation(s) (haven't narrowed it down enough), I get the following exception:
The underlying connection was closed: The connection was closed unexpectedly.
When this exception is thrown, it is calling a method of a web reference.
Now the situation that we experience this is on a laptop in the field that is using a WWAN connection in at least one location. It works fine in the lab at the office. Anyone have any ideas what could be causing this
Exception: "The underlying connection was closed: The connection was closed unexpectedly." (sometimes)
Michael Mockus
How do you manually force the web reference to create a new connection
What is the default HTTP ExecutionTimeout (ExecutionTimeout is the one I should be concerned with, right Not sure what App domain is.)
Ngangom
First the good news. That the problem stated in thread is solved.
As I mentioned earlier that "Server Disconnects" i still stand with my word. What i mean to say i that the server disconnects the Port on which it was connected to client.
And this is rather the architecture of any WEB server.
1. Connect 2. Get Request 3. Send response 4. Close
If you click for any request to web browser every request is considered diffrently.
Thanks and regards
Sachin Chavan.
zorleo
I have been thinking that with the "General Case" of wanting to try and create a new connection on failure that there should be a generalized way to write that code one time and make adding that to the calls to the web service as simple and painless as possible.
I wonder if other folks are out there writing this code and we are all "re-inventing the wheel" right now.
I have not spent much time hacking the code that calls the web service.....
it would be usefull to have some example of how to tell the local proxy that makes the calls to use/create/generate a connection.
like can we make a call:
WSproxy.ReConnect();
do we need to create a http/webrequest objects and somehow plug them into the proxy
how does the first call start a connection
how does the proxy class "track" it's state (Connected, not connected)
Prabu.
IMHO this is the most common error and the one I have not seen any clear info on how to stop it.
*I THINK* based on my reading that it has some what to do with http 1.1 and keep-alives. it may also have to do with the client proxy code generated by the "add web ref" in Visual studio.
*I THINK* that what happens is that the .net client app thinks a connection is open and tries to use it and gets a connection closed error. I think we might want some logic that catches that and tries to create a new connection and if that new connection works go on and just use it. if it fails then do a Throw .....
but this is just my best guesses based on what I have seen so far.
now if we could get someone from Microsoft who knows what the logic is for the whole round-trip they might be able to give more insight on this.
Tim Tidwell
I think I figured out what the problem is, but I haven't found a good solution for it.
In my code:
webservice.MyWS ws1 = new webservice.MyWS();
try
{
ws1.Get();
}
catch(Exception ex)
{
System.Diagnostics.Debug.Writeline(ex.Message);
}
It seems that an exception is thrown when the web service isn't ready. So by retrying the webmethod, it eventually works.
webservice.MyWS ws1 = new webservice.MyWS();
int i = 0;
Retry:
try
{
ws1.Get();
}
catch(Exception ex)
{
System.Diagnostics.Debug.Writeline(ex.Message);
if (i < 3)
{
i++;
goto Retry;
}
}
Is there a way to check to see whether the webservice is ready And or wait for it to initialize
Bit_Flipper
The analysis above is pretty much right. The .NET HTTP implementation tries to keep the connection alive as long as possible in order to avoid the overhead of creating a new conneciton. If the server decides to close the connection without notifying the client you may see this error. In general, you need to catch these exceptions in your application and create a new connections as necessary. The client proxy code is not really related other than by the fact that it uses the .NET HTTP implementation.
There is a server side connection timeout in ASP.NET that you can configure, and it may be causing this problem. See:
http://msdn.microsoft.com/library/default.asp url=/library/en-us/cpgenref/html/gngrfhttpruntimesection.asp
Daniel Roth
Pete2
If you are transfering large messages or the operation on the service side is taking very long you may enter into a timeout situation that you can change in ASP.NET configuration.
Please describe the frameowrk that you are using: SoapToolkit, WSE, ASMX
Hope this helps,
Diego Gonzalez, [C#, MVP]
Lagash Systems SA
Corin
Harry Cu
a follow on question:
when is the first connection created
is it when the first service call is made
or is it when the client proxy class is created with wsfoo = new wsfoo()
right now I have some code that I am re-working and was thinking:
perhaps in place of creating a global level object on start up perhaps I should be doing that later and new / dispose the object locally
that would cause my app to create a new object just before it goes to call the method so the connection and timeout would start then and be less prone to reaching a timeout.... ( I hope)
also I am still looking for what code to use to make a new connection
looks like I have to cast the local client proxy down to a lower level web request class and then do a webconnection create thing
as far as I have seen the top level class built by add-web-ref does not expose properties like:
bool IsConnected
or methods like:
Service.Connect( URL );
or .Open() .Close() like on a file or stream
keiop
This is the right idea. To recover from loss of the connection you need to catch the exception and retry the request as appropriate for your application. The original request may have partially complete so it really is up to your application to decide if retrying the request is appropriate.
I don't have a well crafted example for how you should write the code to retry the request. I'm going to move this thread to the networking web forum where they might be able to supply this code.
I agree that it might be an interesting feature to be able to turn on automatically retrying the request if you know that it will always be safe to do so for your application.
Thanks.
Daniel Roth
Jayender
The server isn't supposed to close the connection by design. No HTTP status code has any implications for connection management. This is actually a completely separate topic. 100 means:
The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code.
You can disable Expectations by setting System.Net.ServicePontManager.Expect100Continue to false.
trc_pdx
Webservice is ASMX in .NET 2.0. Originally .NET 1.1 with same problem. Client app is .NET 2.0. Both written in C#.
The timeout on the client app should be the default 100,000ms. Is there also a timeout setting on the webservice side Note that the exception is thrown within a second of invoking the web method.
SeaBreeze
The above problem is because of following
While sending soap request to server .Net is sending following through TCPIP socket first
POST http://Someserver.com/Somefile.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.42)
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://nettime.centralservers6.com/cs/NetTimeServices/Punch"
Host: nettime.centralservers6.com
Content-Length: 922
Expect: 100-continue
Proxy-Connection: Keep-Alive
Then sends the actual Soap xml after a fraction of delay.
< xml version="1.0" encoding="utf-8" >
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<SomeXML/>
</soap:Body>
</soap:Envelope>
As you can notice in above it is sending Expect 100:Continues to the server so server send back the continue 100 and closes the connection socket (This is default beheviour of any web server check : Html 10 Status Code Definitions )
As server closes the connection .Net displays The connection was closed unexpectedly. But according to the design of server its expected for server to send continue and close the connection once it received "Expect 100:continue"
So i feel this is a bug.
For above I had developed a Net Sniffer in VB.6.0 and made the .Net proxy to connect to my NetSniffer and my netsniffer was connected to internet. By this way I was able to know what headers it was sending to the webserver
Following link might take you further to the solution.
http://support.microsoft.com/default.aspx scid=kb;en-us;327885
ftts
just one thing: goto
I'd do a while loop like this:
TryCount =0;
Ready=False;
While ( ! Ready && TryCount < 5){
bool flag=false;
try {
ws.get()
}
catch{
flag=true;
}
TryCount++;
if (flag){
// stuff here
}
else{
Ready=True;
}
}
if ( !Ready && TryCount>4){
// throw something
}
a bit more logic there but I think that gives a clear flow of
"If at first you don't sucseed Try Try Again"
and a final Throw for total failure cases.