Forum Discussion
karthic_n_12765
Nimbostratus
NimbostratusException thrown on a re-connect to BIG-IP
Hello,
I get the following exception (System.Net.WebException with stack trace) the first time my .Net app attempts to re-connect to the iControl web-service after a delay. I.e. app sends command to device for the very first time...this works fine....wait for 3 minutes or so and send another command and I get the following exception....if I retry, it goes thru fine.
As you can see, the text in the exception says "An unexpected error occurred on a receive". Does this offer any hints? Since the communication is all encrypted by SSL, I take it I can't investigate this problem by taking at peek at the actual packet (using a network sniffer) sent by BIG-IP that caused this error.
Any ideas as to how I might go about investigating this problem? Appreciate your help very much.
The .Net app is running on a Windows Server 2003 box with version 1.2 (beta) of the .Net framework.
Thanks,
Karthic.
Exception Contents: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive.
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)
8 Replies
- We haven't seen this behavior before. First you might check to see if you have the PreAuthenticate boolean set. This will enable HTTP keep alives which may be causing your problem upon delayed connections. By setting this boolean to false, a new connection will be established for each method call. This is not optimal for short bursts of method calls, but if you are waiting 3 minutes between polls then a new connection is probably the correct thing to do.
If this isn't the problem, then I'm not sure what to offer. We are using v1.1 of the framework and I haven't seen this behavior before. Let me know if the PreAuthenticate bit fixes the problem or not.
-Joe 
karthic_n_12765Hi Joe,
Thanks for your reply. Appreciate it very much.
I had initially set PreAuthenticate to true. After seeing your post, I changed it to false…however, that didn’t help…I still get the exception. (the .net framework sdk only mentions that setting PreAuthenticate to true will cause the client to voluntarily present credentials….there is no mention of its effect on http keepalives. Are you deducing this information from experience or am I not looking at the right msdn documentation?).
Anyway, I did a packet sniff and found the following to be the cause of the exception:
During the wait, BIG-IP sends a TCP FIN to my windows box for the TCP connection opened prior to the wait. The windows box acknowledges the TCP FIN. However, the windows box does NOT send a TCP FIN or a TCP RST to close its end of the connection. Instead, after the wait, when I re-initiate contact, the windows box sends the data over the same TCP connection. BIG-IP responds to this with a TCP RST. I am pretty sure this TCP RST is what is causing the exception.
I did the packet sniff with and without setting PreAuthenticate. There was no difference with respect to the above behavior. However, there was more number of TCP connections when I set PreAuthenticate to false, which seems to validate your point about its relationship to keepalives. Given that the TCP payload is encrypted with SSL, I am unable to look inside the HTTP header to see if keepalive is enabled. Not that it would matter anyway.
Thanks,
Karthic.- I'm going to have to try to recreate this with the 1.1 version of the framework. Have you verified that this occurs as well in v1.1 or is it just happening with 1.2? Also, my dev box is XP so I'll have to dig up a win2003 server to see if that's the underlying issue.
I'll let you know what I find.
-Joe - karthic_n_12765Joe,
My app uses new features (such as “Generics”) that are available only with v1.2 of the framework. So, I couldn’t try it on v1.1, at least, not without some serious rework. I will, however, try it on XP and report back on what happens.
by the way, on a totally different note, sorry about not responding sooner to your post....I am having to post these messages from home as I get a "invalid session" message when I post from work. I think it is because we go thru proxy server at work. Grant from F5 knows about the problem and is working on it. He knows it because I went thru the trouble of going to the "Feedback" page on your site and sent a message. I wonder how many are just walking away frustrated without bothering to attempt to get over the hump.
--Karthic. - Karthic,
I've just tested this out with v1.1 of the framework on WinXP and cannot recreate the problem. I've tried this with the PreAuthenticate bit on and off. When it's on and I issue consecutive requests, I'm seeing the traffic flowing over the same http session. When I wait 3+ minutes, the keep-alive is disconnected and a new sessino is created. With the PreAuthenticate bit off, a new session is created for each request. Either way, I'm not seing the receive error.
I'll try this on Win2003 server when I get back into the office on Friday. I'm wondering if this is a v1.2 issue... Which build of v1.2 are you using? Is it from a Whidbey build or are you using the beta framework with the released VS.NET?
-Joe - The new features in the frameworks are looking pretty interesting. Let me know what you find on XP and I will do the same.
As for the invalid session error, I'm glad you reported it. This is the first I've heard of it and I'm surprised Grant got the message and I didn't as I'm on the feedback alias as well. We definitely don't want anyone walking away frustrated! I'll get on Grant to get this worked out and thanks for your patience!
-Joe - Karthic, I've just verified that this does not happen on Win2003 Advanced Server with v1.1 of the framework. I've tried various settings with and without keep alives set. We'll be keeping track of v1.2 and will support it when it's released but as of this point I don't believe it is a problem with our server components.
-Joe - karthic_n_12765Joe,
Thanks for your help. I will keep at it and see if I can figure it out. Meanwhile, I ran into couple of different exceptions. I am starting new threads for those just so I don't confuse every one mixing one issue with another.
Thanks,
Karthic.
