Error running report 'Timeout exceeded'
Hi,
I am having trouble running a report.
I am running a report from workflow using "Report" activity using where clause and it is linked to a chart. When I run the report with the chart using 20 features as inpput I am getting result but when i do the same with more than 70 features i am getting below error.
There was a workflow error running activity: Error running report 'Timeout exceeded'
below is the message from logs
Run report operation 'ElevationProfile' completed in 59.8 seconds. Consider changing this report to run asynchronously to avoid request timeout errors.
Is there any way to change the timeout value of reportdesigner.
I want to run the report synchronously because I want the output in png format but large format printing supports only pdf.
Thanks,
Srikanth
0
-
I’m having this error since ages with no solution 
0 -
I resolved my asynchronously warning and errors by going into my arcgis server admin connection and changing my printing tools geoprocessing service properties. Under parameters change the excution mode from synchronous to asynchronous. 0 -
We would appreciate if this issue is resolved in GE 4.7\GVH 2.8. we hope to hear from LG team. 0 -
Hi Jamal,
It sounds like your issue is different from Steffen's, as he was getting a timeout error on a report, whereas yours results from a workflow. Also, it's not clear that your error is resulting from a defect in the product. There will always be a limit on how long your request is allowed to take before either the server or the browser gives up on it. If your workflow is likely to time out, you should consider invoking the workflow asynchronously so it can run in the background, as Ryan's recommended in (https://support.geocortex.com/essentialsGSCForum?sub-nav=forum&main-nav=essentials&#!/feedtype=SINGLE_QUESTION_SEARCH_RESULT&id=90660000000099WAAQ) this thread .0 -
Hi Jordan,
I searched about printing tools in arcgis server and i found that "Asynchronous" option is recommended for long-running services as we have.
Do you think that this option can affect efficiency of our services that integrated with workflow?
Best,
Fatin0 -
Hi Fatin,
There shouldn't be any impact. The only functional difference between running a workflow synchronously or asynchronously is, with an asynchronous workflow, Essentials and the viewer won't stop to wait for a result. For example, if your workflow is doing a query for all parcels belonging to someone named Sally, the query itself will be the same -- and will have the same impact on the service it queries -- whether your workflow is synchronous or asynchronous. The only difference is that the workflow won't time out if you're querying a layer with millions of parcels.
Does that help?0 -
Hi Jordan,
Thank you for replay, I appreciate that.
I just want to mention to complement your opinion, that we actually need to query about 2500 parcels using a workflow.
Is it recommended in our case to use the extension mode “Asynchronous ” that located in utilities” printing tools” section?
Best,
Fatin0 -
Hi Jordan,
We are newly getting the same error when printing with the out-of-the-box geocortex tool. What might be the issue here?
Bowser issue?
Geocortex issue?
ArcGIS Server issue?
Resources issue?
0 -
Fatin, when it makes sense to use asynchronous will vary depending on the performance of the map services, your own infrastructure, and the complexity of your data. For instance, if your parcel data has only a few fields, 2500 features may not bee too bad, but if they have dozens, or even hundreds of fields, 2500 features might represent several MB of data. If there's any doubt as to whether your users will make requests for data that will time out, it's probably prudent to go with an asynchronous workflow (or report, or print job).
Jamal, it's hard to say from the screenshot -- it won't be a browser issue, but it may be an issue with servers that are slow, or with a print job that requires a large number of cached tiles to be stitched together. This will likely be the case if you try to print at a high resolution (say, 300 dpi or more). In any case, I would definitely look at asynchronous printing, if you're experiencing time-outs.0 -
Thank you Jordan for the answr.
We have already tried all recommendations but with no effect on the ground. The issue persists to exist. It appears that no medicine has been provided to this challenge as all what we got is like trial\error approach but not a definite, precise or robust solution.
Our users are shouting when they got this very frustrating message. I have no idea what we can do to fix it.
Browser: firfix, IE, google chrome
ArcGIS Server 10.5
GE 4.6.3\GVH 2.7.2
Server machine: Dell Power Edge R820, 32 cores, 128 GB,
We are taking about around 2,000 hits a day! Not much
0 -
Jamal, I just took a look at the viewer you've shown in the screenshots, and none of its print templates are using asynchronous printing.
If you edit the site in Manager, go to the Print Templates and edit one of the templates.
_img_ alt="Screenshot showing the editing the print templates in Manager." src="https://latitudegeo--c.na53.content.force.com/servlet/rtaImage?eid=90760000000Chxs&feoid=Body&refid=0EM600000001TXq" _/_img_
Click the Edit Print Job Settings button.
_img_ alt="Screenshot showing the "Edit Print Job Settings" location for a particular print template." src="https://latitudegeo--c.na53.content.force.com/servlet/rtaImage?eid=90760000000Chxs&feoid=Body&refid=0EM600000001TXv" _/_img_
In the Print Job Settings dialog, select the Enable Print Jobs checkbox.
_img_ alt="Checkbox to enable asynchronous, or large-format, printing." src="https://latitudegeo--c.na53.content.force.com/servlet/rtaImage?eid=90760000000Chxs&feoid=Body&refid=0EM600000001TY5" _/_img_
There's more information on the configuration of this in the section on Large-Format Printing in the Geocortex Essentials Administrator Guide (section 39.7 in the 4.6 version of the documentation).0 -
Sorry, Srikanth! I lost track of your original question.
There is a way to set a longer timeout via the viewer, but it's not something we recommend, because it can potentially create other problems, like requests that should legitimately time out now taking longer to do so. So, with that caveat...
Edit the viewer's Index.html (typically in C:\inetpub\wwwroot\Html5Viewer). Right at the end of the script element is the call to initialize the viewer:new geocortex.essentialsHtmlViewer.ViewerLoader().loadAndInitialize();Replace this line with this instead:new geocortex.essentialsHtmlViewer.ViewerLoader().loadAndInitialize({ onSiteInitialized: function(app, loader) { geocortex.config.io.timeout = 300 * 1000; // 300 seconds } });As you can see, the timeout variable takes time in milliseconds.
Again, this is not something we encourage, but if you really need to increase the timeout without switching to asynchronous reporting, this will do the trick. Note also that if you increase the timeout to be longer than the server timeout, requests will still time out on the server side.0 -
Thank you for the reply Jordan :)
I tried your solution but unfortunately I am still getting the timeout error.
As a workaround I tried using 'TemplateReport' activity by managing the data input to the activity in the same workflow and it worked. It is taking more than minute to generate the report but it is not throwing the timeout error.0 -
Hi Jordan,
Print job setting is already used as Enable. The issue exists even though this option is activated.
What do you think?
All the Best,
Fatin0 -
Hi Fatin,
I just took a quick look, and the problem is that the print request is asking for a output format of jpeg; in large-format printing, the only supported output format is pdf. If I use Fiddler to change the viewer's print request so that pdf is requested, I'm able to successfully print using your large-format print templates. So if you ensure that you're requesting pdfs, that should work for you.0 -
I think I see where it went wrong for you. It turns out that when you enable large-format printing on a print template, it does not reset the default output format. What I think happened for you is that you originally had a default output format of Jpeg, which is why it's still making that request.
If you edit your print template to not use large format printing again, set the default output format to Pdf, apply and save, and then turn large format printing back on, it should work for you.
For reference, I've filed a bug on this behavior: GVH-14715. But you should be able to work around this by using the steps above.0 -
Thanks Jordan.
Well. We have set the jpg format to be the default to avoid the issue that the pdf is not able to print the Arabic font properly in the legend! either way, we are in trouble!
What do you think?
0 -
Thank you Jordan for your reply.
I agree with Jamal about font issue.
Moreover, The following error is displayed for A0 template.
What do you think?
Thank you in Advance
All the best,
Fatin0 -
Sorry, Jamal. I'd forgotten about the issue with pdfs and printing bidirectional text. That is frustrating. Unfortunately, in this case, there's no easy fix for either of us. Generating PDFs that properly supports bidirectional text will require us to replace a key component within printing and reporting, which will necessitate a complete rewrite of these features. We've been planning an overhaul of these areas, but I couldn't even guess at a timeline; it won't happen in 2017.
It may be possible to make synchronous printing viable for your site, but it will take a great deal of optimization of the data. I know you've been unhappy with the performance of the HTML5 viewer and, while we're continuing to work to make the viewer faster and more efficient -- we've made some modest gains in 2.8* -- there will always be limits to the amount of data that can be handled by a web client. The leaner you can make your data, the faster the application will perform.
Here's a (http://geomolg.ps/L5/Index.html?configBase=http://geomolg.ps/Geocortex/Essentials/REST/sites/A3/viewers/V1/virtualdirectory/Resources/Config/Default) GeoMOLG viewer :
There is so much going on here that you can't even see the basemap in some places.
Here it is again at 1:250,000:
I think you'll find that there's a lot to be gained by optimizing your data in ArcMap before publishing it to ArcGIS Server. Esri's provided some documentation to help with that, such as this one on (http://desktop.arcgis.com/en/arcmap/latest/map/working-with-layers/optimizing-map-content-for-performance.htm) Optimizing map content for performance .
I know this isn't the solution you're looking for, but I hope it's helpful, nonetheless.
*Footnote to my comment about performance gains in the 2.8 viewer: Initial application loading has generally been improved as a result of some of the changes (https://support.geocortex.com/essentialsGSCForum?sub-nav=forum&main-nav=essentials&#!/feedtype=SINGLE_QUESTION_SEARCH_RESULT&id=90660000000Ck1mAAC) Jason talks about in this thread . In addition, the fix for the issue where there are multiple export requests for the same layer (GVH-12107) should make for some significant improvements for your application. For instance, the largest image request that the viewer makes on its initial load of the GeoMOLG application I've shown is (http://geomolg.ps:6080/arcgis/rest/services/ParcelsRegistered_09/MapServer/export?dpi=96&transparent=true&format=png32&layers=show%3A0&bbox=171977.40667470547%2C153472.8233495425%2C173755.41023071256%2C154471.8920143465&bboxSR=28191&imageSR=28191&size=1680%2C944&f=image) this parcels layer and it's over 280 KB. The 2.7 viewer is requesting it five times as it loads. The 2.8 viewer will only request it once. That's a reduction of over 1 MB of data requested from the server for a single layer.
Fatin, please see my previous two posts for an explanation of the invalid output parameter error.0 -
Thank you Jordan for the useful input.
I’m aware that this should be very challenging but this is what we have at the moment!
Optimizing the site in terms of turning on\off layers at particular scales has also disadvantages. For example, if a client needs to export a layer as shp file (a layer 100 polygons that spread across the country), then he\she will not be able to do so if the layer is turned off at large scale! Clients will be shouting again and all what we can do is to introduce more apologies!
I’m happy that a significant improvement for performance is applied in GE 4.7\GVH 2.8. This will free us from some headache. However, we will not be able to upgrade to the new release as an important property has been damaged in GE 4.7\GVH 2.8 which is discussed here
https://support.geocortex.com/betaGSCForum?sub-nav=forum&main-nav=beta&#!/feedtype=SINGLE_QUESTION_SEARCH_RESULT&id=90660000000CkWpAAK0 -
This is again happening when exporting data as csv 
0 -
Thank you Jamal for your comment.
Jordan, please note that the issue still exists for both tools: priniting and export to csv
What do you think?
Best,
Fatin0 -
Hi Jordan,
We noticed that the “time out exceeded” error is unstable behavior, it sometimes appears when trying to print a large-format (A0, A1…), and unfortunately the configuration of Large-Format Printing in the Geocortex Essentials Administrator Guide (section 39.7 in the 4.6 version of the documentation) will not work with us since it is supporting PDF only.
Please note that we are using GE 4.8.2 and GVH 2.9.1.
Any other suggestions?
Best,
Majdoleen0
Please sign in to leave a comment.
Comments
23 comments