Hello we’re performing Get and Post web requests using HTTPSecureSocket. When there is Internet it works perfectly. When we turn off Wi-Fi, for example, the entire app freezes for about 30 seconds. It was our understanding that the calls are made asynchronously when not specifying a timeout. We even tried creating a separate thread in which to make the web requests calls but the issue persists. Why would the Xojo app lock up in the event of an asynchronous web request call when there is no Internet connection?
I forgot to mention this happens on MacOS High Sierra with both debug and non-debug mode.
I have come across this same problem, Xojo will lock up as it is single threaded.
During the start up of my app i test the internet is connected doing a shell command to ping ns1.google.com.
I also have a backup of getting some http headers to test.
Other option is to push this out to a helper app so that can lock up and your main app keeps on running.
This is my shell test, forces a timeout after 2 seconds.
dim s as new Shell()
s.mode = 0
s.TimeOut = 2000 //two seconds
#if TargetWin32 then
s.Execute("ping ns1.google.com -n 1 -w 2000")
#else
s.Execute("ping -c 1 -t 2 ns1.google.com")
#endif
pIsOnline = (s.ErrorCode = 0)Are you making this call Synchronously or Asynchronously?
Wow. Ok we’ll have our helper app do all of the web requests. Kind of a serious limitation. There’s no way to always be certain whether Internet is available and risking an app lock up isn’t exactly the best UX.
Why don’t you post the code for your socket and we’ll help you determine if you’re doing it synchronously or asynchronously. Asynchronous sockets should not lock up the app. Synchronous ones absolutely do.
Shot in the dark: does it hang if you use an IP address instead of a domain name?
Or, if you don’t want to (or can’t) share the code, use a Xojo.Net.HTTPSocket instead. You can’t do those synchronously. It will also handle all the SSL / security stuff for you.
There is something not working correctly with processing of Name Resolution Errors in synchronous HTTPSecureSockets. Maybe this is related here. See : <https://xojo.com/issue/46993>
I tried with a regular HTTPSocket and the same issue occurs. As soon as the Post executes, the app locks up for a long time. My code for HTTPSecureSocket is below.
Dim secureSocket As HTTPSecureSocket
secureSocket = New HTTPSecureSocket
secureSocket.Secure = True
secureSocket.SetRequestContent(jsonItem.ToString(), “application/json”)
AddHandler secureSocket.PageReceived, AddressOf Tracking.ProcessResult
secureSocket.Post(Endpoint + Type)
Using an HTTPSocket, when I replace the URL with an IP address the issue goes away. So it is a DNS issue but with HTTPSocket not just HTTPSecureSocket. Is there a workaround for this?
Unless I’m mistaken, the code above should perform an async web request call. If so, then why is the app locking up?
It should, but secureSocket should also go immediately out of scope and it shouldn’t work at all.
If using an IP address works, I would think it’s this.
Have you tried Xojo.Net.HTTPSocket to see if it suffers from the same issue?
[quote=368586:@Tim Parnell]It should, but
Have you tried [code]Xojo.Net.HTTPSocket to see if it suffers from the same issue?[/quote]
Xojo.Net.HTTPSocket doesn’t have this issue.
App frozen (?) before Connected event is raised.
No freezing with Xojo.Net.HTTPSocket. Whew! It works as expected. Thanks all.
[quote=368586:@Tim Parnell]If using an IP address works, I would think it’s this.
Have you tried Xojo.Net.HTTPSocket to see if it suffers from the same issue?[/quote]
Thanks Tim, but I’m not looking for a workaround or alternatives (which I have already implemented), I was just highlighting an existing bug in the hope such misbehaviour could be resolved in the framework before it gets deprecated.
FWIW, this behavior seems to have existed since the classic framework http sockets were created.
@Tobias Bussmann I was trying to point out to the OP of this thread that you were most likely to have found the root of his issue. I was merely trying to credit you by quoting your post. I’m sorry you’re having such troubles 
I see, thanks. It seems I did misunderstood your post, sorry. Knowing the troubles is the first step to deal with them 