Skip to main content

Async Workflow Timeout Error

Comments

10 comments

  • Permanently deleted user

    Hi Harold, 

     

    The workflow is programmed to time out after a minute if it does not receive a response back from either the server or client. You may be able to avoid getting the timeout error if you add in other activities that will run in parallel with your geocoding service so that the viewer knows the workflow is still running. For example, add in a parallel activity and set one side to the geoprocessing service and set the other side to one or several "Configure Workflow Container" activitie(s) to keep the workflow running. 

     

    I hope this helps.

     

    Regards, 

     

    Carmen
    0
  • Permanently deleted user
    Hi Carmen,

     

    Thanks for your response. I tried to put the configure workflow container task in a parallel activity along with the geoprocessing task within my asynchronous workflow. However, I still get the timeout error.

     

    I've also tried to put it in a while loop so that while the boolean variable "completed" is false the configure workflow container activity will run. This didn't work either.

     

    Lastly, I've tried to put the activity right before my geoprocessing task and while it seems to run and no error shows up, the routes are never generated and I never get an email notification (which I should receive whether the geoprocessing task is successful or not).

     

    I've looked at the logs in ArcGIS Server and for Geocortex and I don't see anything related to my workflow.

     

     
    0
  • Zack Robison
    Have either of you come up with a solution to this issue? I have tried tricks left, right, and sideways to avoid parent workflow timeout during an invoked or referenced workflow child activity to no avail.
    0
  • Permanently deleted user
    The approach of placing your Invoke Workflow in one sequence and a Keep Alive in a second sequence in a parallel activity will only work if you use activities that inherit from AsyncCodeActivity class in both sequences.

     

    Parallel activity really only runs activities in parallel if you are using asynchronous activities due to the way threading works in Workflow Foundation. You can test this out by adding two sequences to a parallel activity like this.

     

    _img_ alt="User-added image" src="https://latitudegeo--c.na53.content.force.com/servlet/rtaImage?eid=907600000004GXD&feoid=Body&refid=0EM600000004YEL" _/_img_

     

    If you run this in the simulator, you can see the outputs are linear - the first sequence runs to completion before the second sequence starts and then the second sequence runs to completion.  This is not processing anything asynchronously. 

     

    Now if you amend the workflow to include an activity that inherits AsyncCodeActivity in both sequences (I am using the Create File as an example here) and run it again.

     

    _img_ alt="User-added image" src="https://latitudegeo--c.na53.content.force.com/servlet/rtaImage?eid=907600000004GXD&feoid=Body&refid=0EM600000004YEQ" _/_img_

     

    This time you will see that both sequences execute in parallel; each time the Create File activity runs it allows the workflow to go into an idle state that frees up the worker thread to execute the other sequence.  It is only at the point where the AsyncCodeActivity releases the worker thread that the parallel can switch sequences.

     

    The contextual help for activites provides inheritance tree info so you can find which activities inherit AsyncCodeActivity.  Neither Geoprocessing task or Configure Workflow Container run asynchronously so your parallel is probably not executing in the way you are expecting it to.  Invoke Workflow inherits AsyncCodeActivity but Reference Workflow doesn't.

     

    Another common mistake to avoid is to use the Delay activity in your keep-alive sequence to manage the time calls to the client.  The Delay activity pauses the workflows worker thread for the timespan you specify.  This stops the entire workflow executing for that amount of time not just the code in the keep-alive sequence.

     

    The best approach I've found is to have a loop in the invoked workflow that contains an AsyncCodeActivity based activity so that the workflow is repeatedly entering the idle state. My keep-alive sequence only contains a while activity (that runs until a boolean property is set to true) with an External Log activity followed by another AsyncCodeActivity based activity.  This set-up typically results in the client being called each time the AsyncCodeActivity in the invoked workflow is processed.  When the Invoke workflow completes execution I set the boolean value to true to allow both sequences in the parallel to complete and the workflow to continue as soon as the long-running task is completed.
    0
  • Chris Dunlop
    I'm running into the same timeout problem with the Invoke Async activity.  I'm confused by the documentation - it clearly states that the async workflow runs as a background process and doesn't block execution of the current workflow.  The example it gives is exacatly what I'm trying to do - first, collect input from a user (in my case, a geometry and an email address), and second, run a long-running report that will be emailed to the user when complete.  My question is, why is the calling workflow waiting for a response from the called async workflow at all???  I just want the calling worflow to kick off the async activity and then end.  There shouldn't be any need to have a keep-alive sequence or anything like that....  Am I missing something?

     

     
    0
  • Kevin Penner
    I ran into this nuance recently. My solution was to put a delay activity (Common Server section) into the start of the workflow with a Duration value of TimeSpan.FromMilliseconds(1). This will ensure that the workflow is run in an Async fashion and the client will continue and not wait for completion.

     

    The reason it is not running Async currently is likly because the compiler detects that there is no need to run it so. The Delay activity circumvents this.

     

     

     
    0
  • Chris Dunlop
    Thanks Kevin, that worked.  Maybe the documentation could be upgraded to include that necessary step.

     

     
    0
  • Permanently deleted user
    Run into the same problem and read the above posts. Unfortunately after a lot of trials we still did not manage to get this working.. In short what we are trying to do: we have a DownloadString that takes too long to run and results in a TimeOut. We tried to solve this with the parallel sequences and Delay, but still get the same error. Can somebody please sent a working example of a workflow? We think that we're probably doing something wrong in the placement of the activities (in particular the DownloadString activity). Hope that someone can help. Many thanks in advance.
    0
  • Permanently deleted user
    Hi Janna,

     

    In the Viewer for HTML5, any web request is given 60 seconds to respond.  If it doesn't, then the request is canceled.  This will cause problems if your workflow's taking too long!

     

    We have created a Code Gallery example that shows one way of using the Invoke Workflow Async activity to do a long running task without timing out.  It is here:

     

    https://support.geocortex.com/essentialsGSCCodeGallery?sub-nav=codegall&id=kA46000000007o2CAA

     

    Regards,

     

    -Malcolm
    0
  • Permanently deleted user
    I have tried Kevin's way (put a server-side delay before the Async Geoprocessing), GE4.10 HTML5.12. unfortunately it didn't work for me. For some reason, the workflow never passed the delay. The only option works for me at the moment is as Malcolm suggested.
    0

Please sign in to leave a comment.