Android Question Http Events Not Releasing and/or Remaining Queued?

[swabygw]

I have an Activity that contains a Panel. When the Activity is loaded, the three Http jobs are executed every two seconds which retrieves data from a database and updates some information on the Panel. It works well until it runs for, say, more three or four minutes, after which, the application is clearly consumed with processing because everything becomes sluggish. For example, after the Http is running for a while, if I click on a button on the Panel, the click doesn't register for a few seconds. And, when the Activity is finished, it produces the following Log entries...over and over again, maybe dozens or hundreds of times, depending on how long it was running.

Object context is paused. Ignoring CallSubDelayed: JobDone
sending message to waiting queue (jobdone)
Ignoring event (too many queued events: jobdone)

Initially, I thought that the Http jobs were not completing or releasing, but I think my code takes care of that. Here's how each Http job is coded:

Sub GetStatistics

  Dim url As String

  Try

    Dim jobHttpGetStatistics As HttpJob
    jobHttpGetStatistics.Initialize("GetStatistics(" & UserID & ")", Me)

    url = Starter.ServerUrl&Starter.ServerPage&"?FunctionName=GetStatistics"
    url = url & "&FunctionParams=" & UserID

    jobHttpGetStatistics.PostString(url & "&cachebuster=" & DateTime.Now, "GetStatistics")
    Wait For (jobHttpGetStatistics) JobDone(j As HttpJob)

    If j.Success Then
      Dim jp As JSONParser
      jp.Initialize(j.GetString)
      Dim rows As List = jp.NextArray
      For Each m As Map In rows
           FieldVariable = m.Get("FieldData")
      SetStatsSection
      Next
    End If

    j.Release

  Catch
    Log(url)
  End Try

End Sub

I've included the j.Release which should release each job as it completes, but I think that something is remaining queued or unreleased because of the messages in the Log and the sluggishness of the application the longer it runs. Any idea what could be causing it?

P.S., is it possible that the server is overloaded from too many requests? I also noticed that, when I start this Activity, Main (which is also running Http jobs) pauses and the following line is in the Log: running waiting messages (21)

Sorry for the add'l edits, but I discovered another clue. On the Panel in this Activity is a custom view which executes the Http jobs. The Panel also has a Button which allows me to remove the custom view and create a new view. I noticed that the problems above appear only after clicking this Button. So, is it possible that the Http jobs have started and, when clicking the Button, the custom view is removed and the Http jobs have not completed and puts these messages out because the original object that created the job is killed? But, I also get the Log message: "Object context is paused. Ignoring CallSubDelayed: JobDone" sometimes without clicking the Button and just finishing the Activity going back to Main.

I have an update: moving the resumable sub into the Starter service, and doing a Wait For...Complete to run it, eliminated all error messages, but the sluggishness is still there after it's running a while. I'm thinking that something is still being kept in queue in the background. Here's how the call looks:

Sub timer_Tick
  Wait For(CallSub2(Starter, "GetStatistics", UserID)) Complete (FieldValue As Int)
  'do something with FieldValue
End Sub

 

[Erel]

How long does it take the server to respond?

I would have removed this timer and implement something like this in the starter service:

Do While True 'or working = True
 If IsPaused(Main) = False Then
  Wait For(CallSub2(Me, "GetStatistics", UserID)) Complete (FieldValue As Int)
  CallSub2(Main, "DataAvailable", FieldValue)
 End If
 Sleep(2000)
Loop

Unlike your code, it will only start the next request 2 seconds after the previous one completed.

 

[swabygw]

That worked. Thanks, because I reused this improved logic throughout other areas of the application and the performance improved big-time. The server is local (localhost, on the same computer) and I tested the SQL repeatedly via SQLServer Mgmt Studio, so I didn't think it was really the server causing the problem...just my darn logic.