Archived Forum Post

Index of archived forum posts

Question:

HTTP blocking despite running in BG

Nov 26 '12 at 19:02

Hello,

I downloaded the trial of the HTTP component(VB6 ActiveX.) I noticed if I use back to back requests, specifically PostUrlEncoded, in my case, that the interface locks up momentarily at the back end of the requests. The length of time varies, but it's definitely noticeable and a problem for me.

I use two timers within my connection object I created to simulate a timeout and a checking loop. I'm thinking it is locking up when I call BgTaskAbort.

Here is my current code for said timers:

Private Sub tmrCheck_Timer()

If http.BgTaskFinished = False Then

    Exit Sub

End If

RequestCompleted = True

' Request has been completed.

tmrCheck.Enabled = False

Set response = http.BgResponseObject

If (response Is Nothing) Then
    RaiseEvent Error("NO_DATA")
    Exit Sub
End If

RaiseEvent DataReceived(response.bodyStr)

End Sub

Private Sub tmrTimeout_Timer()

tmrTimeout.Enabled = False

tmrCheck.Enabled = False

If RequestCompleted = False Then

    Debug.Print "Connection timed out."

    http.BgTaskAbort

    RaiseEvent Timeout

End If

End Sub

When the Timeout event is raised, the program makes another connection immediately. It traverses through a list of given links.

I was connecting to my server that requires HTTPS, so my requests where POST requests to https://mydomain.com/input.ext.

Am I not stopping things correctly, or what? I put a delay between the connections(3 to 5 seconds), even, and that did not stop the problem.

Your product would be an ideal solution for me, but as it is, I cannot use it unless I can resolve this issue. The interface of the program is important, and I cannot have it being blocked -- even momentarily.

Thanks,

Jared

---

Answer

I reviewed the internal code for BgTaskAbort, and I think it's very unlikely that the method is causing a delay -- meaning that the method call takes a significant amount of time before it returns control to your application code. The reason is that the BgTaskAbort, internally, simply sets an internal flag variable and returns. (The background thread will notice that the "abort" flag was set and it will then abort whatever operation is in progress.)

The best approach is to identify which Chilkat method call is not returning quickly, and then examine the contents of the LastErrorText after the method call.

---

Answer

Hi, I believe you are correct. It appears to hang on PostUrlEncoded

Here is my code:

Public Function Connect(Optional httpURL As String = "")

http.KeepEventLog = True

http.VerboseLogging = True

http.DebugLogFilePath = "C:\childebug.txt"

Debug.Print "CONNECT"

Dim sp() As String

RequestCompleted = False

If httpURL = "" Then httpURL = URL

tmrTimeout.Interval = Timeout

tmrTimeout.Enabled = True

If Proxy <> "" Then

    sp = Split(Proxy, ":")

    http.ProxyDomain = sp(0)

    http.ProxyPort = CLng(sp(1))

End If

Debug.Print "CONNECT 1"

If rqType = rqPOST Then

    ' Parse request variables...

    setPostVariables

    http.FollowRedirects = False

    Debug.Print "CONNECT 2"

    http.PostUrlEncoded httpURL, request

    Debug.Print http.LastErrorText

    Debug.Print "CONNECT 3"

    tmrCheck.Enabled = True

End If

End Function

When the program freezes, I see in the Immediate window that "CONNECT" is printed, but not "CONNECT 1." I'm unsure if this is because of a previous connection.

I enabled verbose logging, and in the log file, there is no helpful information. This block is repeated throughout the file, without any change(Also in the Immediate window where I print it):

PostUrlEncoded:
DllDate: Aug  5 2012
UnlockPrefix: Anything for 30-day trial
Username: Box:User
Architecture: Little Endian; 32-bit
Language: ActiveX
VerboseLogging: 1
Task started in background thread.
(leaveContext)
VerboseLogging: 1

Other than this hanging, I really do like the simplicity of your product. It will expedite my web related projects greatly.

Thanks,

Jared

NOTE: I was using an https address. Thinking it may be the secure handshake or encryption, I switched to standard http, and no change.

---

Answer

Here's a new build that will log (in LastErrorText) the number of milliseconds it takes to start the background thread that will do the PostUrlEncoded:

http://www.chilkatsoft.com/preRelease/ChilkatHttp.zip

I reviewed the internal code, and starting the background thread is the only thing that could possibly take any amount of time. If the problematic time delay is truly in this method, then I don't see a "fix" because there's nothing that can be changed -- it's simply a call to the MS Platform SDK "CreateThread" function. (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682453%28v=vs.85%29.aspx)