Many times (not always) my application calls HttpWebRequest.GetRequestStream() (please note: getRequest, not getResponse!) but the call doesn’t return.
The program “freeze” on that line. If I pause it in VS I can see that it’s waiting for the return from the call.
How is this possible? Where is the problem ?
This is the code
Using request As System.Net.HttpWebRequest = DirectCast(System.Net.HttpWebRequest.Create(cApiUrl), System.Net.HttpWebRequest)
request.AllowWriteStreamBuffering = False
request.Method = "POST"
request.KeepAlive = False
request.ContentLength = postBytes.Length
request.ContentType = "application/json; charset=utf-8"
request.Accept = "application/json;"
request.Timeout = 60000
Using postDataStream As System.IO.Stream = request.GetRequestStream()
@ baz - What error is being returned? Have you updated the network configuration with FEZ Config?
Nothing! The program remains waiting for that row completing without to return! No errors, now exception, no timeout, nothing!
This makes me crazy…
Net config is ok: the code before make a dns resolution and NTP sync without problem.
Have you tried to hit start in VS again?
I mean: hit pause, than start.
It might run again.
I have this problem often lately.
If this happens to you as well, and your code is short and simple, please provide it to GHI so they can investigate this problem. My project is quite to complex to send it over.
Still the same
Pause, play (re-pause, re-play…): nothing
When I pause, the reported stack is this, maybe can be useful?
System.Http.dll!System.Net.HttpWebRequest.SubmitRequest() Line 1472 + 0x20 bytes C#
System.Http.dll!System.Net.HttpWebRequest.GetRequestStream() Line 1772 + 0x9 bytes C#
Device.Main.exe!Device.Main.Services.ObservationsUploader.UploadObservation(Device.Main.Contracts.Observation item) Line 230 + 0x81 bytes Basic
If they can help me I can send privately all the code, this project is really an hell.
Are you sure the server is responding correctly? When using the HttpWebRequest class it opens up a socket. When the socket tries to connect to an endpoint it does so by a blocking call. If the socket can’t establish a connection it will hang due to a bug no matter what timeout you have set. This is also true for when the server response takes too long.
I solved this by only using socket communication and implementing a custom timeout for the socket.connect method.
You’re right! :dance:
A windows firewall blocked the non standard port on the development server, so no connection was possible.
I didn’t test this because I didn’t know the socket is opened before the GetResponse().
However this behavior is really dangerous: a board in production can be blocked and freezed just because a tcp connection can’t be estabilished!