Increase Timeout for running workflows?
Hi All,
I have a workflow that can be asked to process anywhere from 1 – 500 polygons (it copies attribute data from each record and inserts it into a new flat sql table).
However due to the large amount of processing, I keep getting the Alert: “There was a workflow error running activity: Timeout exceeded” whenever I select more than say 30 polygons at a time.
I updated the web.config, at c:\Program Files (x86)\Latitude Geographics\Geocortex Essentials\Default\REST Elements\REST, with the following and it didn’t make any difference:
<httpRuntime maxRequestLength="2097151" requestValidationMode="2.0" enableVersionHeader="false" />
Any help on how to extend the Timeout (session) for a running workflow would be really appreciated.
Thank You!
Laura
-
Hi Laura,
Could this ExecutionTimeout be the solution? http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.executiontimeout(v=vs.110).aspx
Let me know if that works for you!
-Kevin
0 -
Hi Kevin, thanks for the reply. I'm not sure how to implement the ExecutionTimeout you listed below, or where to add it. Sorry i'm still a novice at programming so any help would be really appreciated. Thanks -Laura
0 -
Hi Laura,
In REST web.config:
<httpRuntime maxRequestLength="20480" requestValidationMode="2.0" enableVersionHeader="false" executionTimeout="60" />
executionTimeout is a value in seconds.
Cheers,
Kevin
0 -
Hi Kevin, We were running into similar timeout problems with a workflow that calls another workflow which then buffers points. In our scenario we use the first workflow to give instant feedback to the user that something is running, which then uses a reference workflow activity to call the second, longer workflow. When run 'standalone' the buffer workflow runs fine, but when called from the reference workflow activity, we get timeouts as the number of features processed increases. Our production guys are unwilling to increase the timeout much past 3 mins, which will allow us to process up to around 150 points only. Any thoughts on why we're getting timeouts only with the reference activity? I'll open a separate thread to find out if this is the most appropriate method of giving instant user feedback when workflows take time to load... Thanks for your help.. 0 -
Hi James,
If the workflow runs only on the server without pinging the client for too long it will timeout. You mentioned that when you are using the reference workflow activity you are using larger sets of data. What you could possibly do is run an activity to update the client every 50 processed points or so to update the workflow container with a status like "300 of 560 records processed". This way the client maintains connection with the server throughout processing and wont time out. Where you have to get crafty is trying to limit the amount of data which is in scope at the time of the ping back to the client. Maybe call the reference activity multiple times passing in subsets of the data each time?
It would also be possible to run the workflow async and have it email the user upon completion. I'm not sure if the viewer needs to know when the processing is done or not in order to show items on the map. If it doesn't need to then this might work.
Cheers,
Kevin
0 -
I am also getting a timeout error when running a workflow using a datalink. I have tried to use Kevin's suggestion:
In REST web.config:
<httpRuntime maxRequestLength="20480" requestValidationMode="2.0" enableVersionHeader="false" executionTimeout="120"/>
But no matter what value I put in the executionTimeout, I get a timeout error after 60 seconds. Any other suggestions?
Thanks, Barbara
0 -
Hi Barbara
In IIS, you should recycle the EssentialsAppPool4 application pool. This may be why it's not registering the new timeout value you're putting in the web.config.
Mark
0 -
I'm having the same problem. Regardless of what value I put for the timeout in the REST web.config, it still times out after 60 seconds.
executionTimeout="300"
I've tried recycling the application pool, as I suggested to Barbara, but this doesn't help.
Is there a way to extend the timeout?
Thanks
Mark
0 -
Hello,
Adding the executionTimeout value and restarting the Web Site in IIS should be all that is needed.
You could also try increasing the idle timeout value for the EssentialsAppPool4 to see if it is a limiting factor, but that is just a guess.
If you are using Invoke Workflow, or Invoke Workflow Async, there's also a timeout parameter that can be used in GE 4.2+.
Thanks, Stefan.
0 -
Hi Stefan
Thanks for your help with this. Restarting the website in IIS has fixed the problem when running the workflow in the Silverlight Viewer, but when running it in the HTML5 Viewer it's still timing out after 1 minute. It's hence some client-side browser setting that needs to be adjusted. I'll check the settings for Internet Explorer.
Mark
0 -
My browser settings don't appear to have any timeout settings in them. Can anyone tell me how we avoid this timeout error for the HTML5 Viewer? Is it actually an issue with the HTML5 Viewer itself?
0 -
Hi,
Can anyone tell the path of the Web.config file that needs to be changed, because there are a lot of web.Config files.
also Recycle in the sense delete the EssentialsAppPool4 folder in inetpub >temp>IIS Temporary Compressed Files path??
0 -
The location of the web.config for Essentials is C:\Program Files (x86)\Latitude Geographics\Geocortex Essentials\<Instance>\REST Elements\REST\web.config
The default <Instance> folder name is 'Default'.
0 -
Srikanth
To recycle the application pool, in IIS select your default website, then select 'Application Pools', then right-click 'EssentialsAppPool4' and select 'Recycle...'.
0 -
I'm not seeing this entry in my Web.configs. executionTimeout="120" Is it okay to add it? (I am exeperiencing occasional aborted requests that show up in my event viewer as shown below. Nothing short of an IIS refresh fixes the resulting errors.
Any other suggestions appreciated. This just started happening when we switched over from a SL to HTML Viewer.
Thanks.
Event code: 3001
Event message: The request has been aborted.
Event time: 10/6/2015 2:55:40 PM
Event time (UTC): 10/6/2015 7:55:40 PM
Event ID: e12ab95fa97c409da0f59df9d5ed0c1b
Event sequence: 43777
Event occurrence: 14
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/1/ROOT/Geocortex/Essentials/REST-1-130886056922734007
Trust level: Full
Application Virtual Path: /Geocortex/Essentials/REST
Application Path: C:\Program Files (x86)\Latitude Geographics\Geocortex Essentials\Default\REST Elements\REST\
Machine name: ARCGISWEB
Process information:
Process ID: 11424
Process name: w3wp.exe
Account name: ARCGISWEB\Essentials
Exception information:
Exception type: HttpException
Exception message: Request timed out.
Request information:
Request URL: http://arcgisweb.waukeshacounty.gov/Geocortex/Essentials/REST/sites/GIS_External/workflows/Search_Parcels_By_TaxKey/run
Request path: /Geocortex/Essentials/REST/sites/GIS_External/workflows/Search_Parcels_By_TaxKey/run
User host address: 98.100.148.3
User: Guest
Is authenticated: False
Authentication Type:
Thread account name: ARCGISWEB\Essentials
Thread information:
Thread ID: 534
Thread account name: ARCGISWEB\Essentials
Is impersonating: False
Stack trace:
Custom event details:0 -
The web.config setting only controls how long the server is willing to allow a request to last. The web browser has its own internal timeout that determines how long it is willing to wait for a request to complete. It is almost certainly the browser limit you are encountering. There isn't a way to increase the browser's timeout. Or if there is... it is browser specific and not recommended.
If you have a workflow that does a very long operation you should look at using Invoke Workflow Async so that the long operation gets initiated as a background job and the web browser doesn't need to wait for long requests. This definitely makes a workflow more complicated, but it can solve the long running problem.
--Ryan0 -
Ryan, I'm experiencing workflow timeouts when simply picking a photo from my iPad using the FilePicker in my DisplayForm. I guess the workflow is loading the bytes into memory and due to slow cell collection hits that browser 60s timeout before it can complete. Is there any way around this such as offloading the client activity to the server?
--Geoff0 -
Hello,
We are having the same issue uploading shapes.
By sniffing the network, I found the browser sent out a TCP RST which cause the disconnect, and then the veiwer popup timeout.
James0 -
Sorry havn't finished my post above.
According to observation above, does there a way to set the timeout at viewer side?
I would suspect somewhere the viewer side javascript not set the timeout properly
James0 -
Here is the solution to extend the timeout.
Find the file Essentials.js in the viewer and looking for string looks like "postLength:2E3,timeout:6E4", that piece of code aims to build the variable c.config.io.
The part "6E4" is the default timeout value at least for uploading files. (Many places refers to this value but the code base is big...).
6E4 means 6 * 10^4 = 60000 msec. change it to the number make sense to your solution.
Don't forgot to update your IIS timeout altogether.
James0 -
Where is the Essentials.js file "in the viewer"? Did this actually resolve the workflow/browser timeout issue in conjunction with updating the IIS timeout setting? 0 -
Hi Sean,
The Essentials.js file is located here: C:\inetpub\wwwroot\{ViewerName}\Resources\Compiled\ssentials.bundle.js
We usually do not advise users to update this file as it is not best practice and is only recommended as a last resort. Depending on your workflow, there may be some other techniques/best practices we can change to speed up the processining time. Please feel free to open up a support ticket so one of our Analysts can take a look at your workflow.Thanks,
Ali
0 -
Hi All,
I tried the suggestion from this article (https://support.geocortex.com/essentialsGSCkba?sub-nav=kba&main-nav=essentials&#!/feedtype=SINGLE_ARTICLE_DETAIL&criteria=BESTANSWERS&id=kA360000000XbYWCA0) , but the same alert was achieved. I’m not sure if this really can help.
Sean and Ali,
Does the change in Essentials.js file affect or extend the timeout for your workflows?
I will be thankful if someone could suggest another solution for this issue to prevent the "timeout error" from appearing.
Thanks,
Fatin0 -
Hi Fatin,
As mentioned above, we usually do not advise users to update this file as it is not best practice and is only recommended as a last resort. You are likely hitting the browser timeout and not the server timeout. I am not sure if changing the Essentials.js file helped Sean or not.
Have you tried looking at using Invoke Workflow Async? This will initiate the long operation as a background job and the web browser doesn't need to wait for long requests.
Please feel free to open up a support ticket so one of our Analysts can take a look at your workflow.Thanks,
Ali
0 -
Thank you Ali for your comment , I will try your suggestions. 0 -
Hi all
Despite implementing all of the above suggestions, I was still experiencing timeout error (502) with a workflow that queried complex polygon layers present at a user generated point in the map viewer and subsequently displayed them, before generating a map-based report containing the identified layer content. An async workflow was deemed impractical due to the mix of client and server activities. In the end the problem appeared to be solely a browser rendering issue, because if the map was zoomed in close to the user generated point then the report worked every time!0
Please sign in to leave a comment.
Comments
26 comments