All our workflows and the print tool stop working suddenly,
All our workflows and the print tool stop working suddenly, 
From time to time, we get errors in all the workflow tools and the print tool in all our sites (Attached an example), and we figure out that if we restart the World Wide Web Publishing Service (wwps) (attached), the issue disappears and all the workflows return to work normally.
then why all this story is happening from time to time? why the solution is in restarting the wwps? What is the major effect of this issue? Any suggestion may help.
Thank you in advance.
Best,
Majdoleen
0
-
We have also seen this problem which was resolved by recycling the App Pools in IIS. 0 -
Thank you Dan,
Do I need to recycle all the App pools or just the one selected in the attacched, One more question, any side effect for recycling?
Really appreciate,
Thank you in advance
Best,
Majdoleen0 -
Thank you Dan for sharing your experience regarding this very frustrating issue. I would also love if geocortex developers\experts can comment on this.
Could you please Dan indicate if this issue has never appeared again after playing with the App Pools in IIS?0 -
This has been an issue for some time. We have found that we need to schedule the recycling of Geocortex app pools four times per day. For some unknown reason this is also necessary if you find that Geocortex manager is not working properly. Yes I would like to see Geocortex comment on this issue as well.
Majdoleen, we recycle all the Geocortex app pools - My guess is that ExxentialsAppPool4 is the pool that caused your print issue. The AdmisistrativeAppPool should be related to Geocortex Manager issues.
Geocortex - Do you have any recommendations for recycling app pools and can you explain why this is an issue?0 -
Thank you very much Dan.
I would appreciate if geocortex users who have experienced this issue can provide their feedback.0 -
Thank you Dan, really appreciate your input regarding this issue.
best,
Majdoleen0 -
Hello All,
There is a new setting being introduced in Essentials 4.7 that will help with this issue. The root of the issue is Windows running out of available handles. Until 4.7 is released we recommend that if you experience this issue that you set the App Pools to recycle more frequently, the default IIS setting is every 29 hours. Every 12 hours may be more effective and convenient, for example 6am and 6pm. Also, if you have multiple instances on one server we also recommend creating unique App Pools for each instance.
I hope this helps.
Wayne Richard
Latitude Geographics Group Ltd.
Head Office: 300 – 1117 Wharf Street Victoria, BC Canada V8W 1T7
Tel: (250) 381-8130 | Fax: (250) 381-8132 | wrichard@latitudegeo.com
Developers of Geocortex web-based mapping software | www.geocortex.com
An Esri Platinum Business Partner0 -
Thank you very much Wayne for confirming that this issue will be resolved in the next releases. Imagine the situation where our users are working with workflow tool and suddenly it is crashed.
We would love if all such issues are reported in the forum so that the community got informed. We have been reporting this issue since ages with no luck to find root solution.0 -
when the proble occurs we got this sort of stuff 
0 -
Hi Wayne,
Could you please check if this solved in GE 4.7?0 -
Hi Jamal,
The error message is too generic, we would need a Fiddler capture to look for more details in the error that is being thrown. Upon initial viewing, it appears you have two separate issues, one based on printing and one from a workflow.
Can you install the beta version and try it in your environment?
Regards,
Wayne0 -
Hi Wayne,
This has been reported since ages with no solution. We can’t deploy the beta release in the production machine. However, we will be upgrading to GE4.7\GVH 2.8 and see if the issue persists to exist.0 -
We are experiencing the same issue here. I have to manually recycle the Application pool, or re-run the Geocortex post-install. .. every day.
I have updated the Idle Time out (shorter than 1440 minutes)
We are running Geocortex 4.7 with HTML5 Viewer 2.8, I will upgrade soon and see how the new version behaves under load. I will post one here to keep everyone in the loop
0 -
If you look into your server's event viewer, you will typically see errors such as:
Faulting application name: w3wp.exe, version: 8.5.9600.16384, time stamp: 0x5215df96 Faulting module name: KERNELBASE.dll, version: 6.3.9600.18666, time stamp: 0x58f33794 Exception code: 0xe0434352
0 -
We are running 4.7 and viewer 2.8 and we are still experiencing the issue (more and more often).
I have increased the amount of recycle Application pool (every 12h) but I still get issues.0 -
We are on the same cycle Frederic, hope that this issue will be resolved ASAP.
Best,
Majdoleen0 -
We are on 4.8 and have had this issue for. The app pools are scheduled to recycle three times per day, but I still have to manually recycle sometimes when the site fails to intitialize. I have worked with tech support in past but issue was never resolved. It hate to admit this, but I am relieved to hear that others are having same issue. It would be REALLY nice to resolve this! 0 -
I’m sure that Wayne will be strongly highlighting this very frustrating issue to Geocortex developers to get it resolved. We are happy that Geocortex experts have fresh eyes on issues we report on the forum and take care of it.0 -
Hi everyone,
Essentials 4.7 included two new .NET app settings (gcx.dispatcherCleanupForceGC, and gcx.dispatcherCleanupInterval) to help address this issue. Both app settings configure how Essentials will manage dispatcher objects, which .NET uses to manage memory and resources across threads. gcx.dispatcherCleanupForceGC does need to be added manually; gcx.dispatcherCleanupInterval is enabled by default with a value of 15 and can be changed if you add it manually.-
gcx.dispatcherCleanupInterval sets the interval at which dispatchers are cleaned up from the application pool. Dispatcher maintains a prioritized queue of work items for a specific thread. If the thread terminates unexpectedly, the dispatcher can become abandoned, and remains until the app pool is recycled, or the dispatchers are cleaned up. This setting sets the interval at which that cleanup occurs. It accepts a value in minutes.
<add key="gcx.dispatcherCleanupInterval" value="10" /> -
gcx.dispatcherCleanupForceGC forces garbage collection in the app pool, which can help clean up any WPF objects which are no longer in use. Garbage collection happens on its own over time, but it only happens when the server is low on physical memory. This setting forces garbage collection to run at the same time that the dispatchers are cleaned up. This setting accepts a true or false value.
<add key="gcx.dispatcherCleanupForceGC" value="True" />
For those that are also looking into Workflow 5, it does not use WPF and shouldn't have this issue. If anyone would like assitance applying these settings, please contact support and we (or your local reseller) will be happy to help.
Thanks!
-Amanda0 -
gcx.dispatcherCleanupInterval sets the interval at which dispatchers are cleaned up from the application pool. Dispatcher maintains a prioritized queue of work items for a specific thread. If the thread terminates unexpectedly, the dispatcher can become abandoned, and remains until the app pool is recycled, or the dispatchers are cleaned up. This setting sets the interval at which that cleanup occurs. It accepts a value in minutes.
-
Thank you Amanda, May you please send me a screen shoot showing where to add these codes in the web.config file? 
Thanks
Best,
MAjdoleen0 -
Hi Majdoleen,
The two key settings can be added in <appSettings> tag.
0 -
Dear Amanda and (https://support.geocortex.com/GSCProfile?communityId=09a6000000008Qu&userId=005600000054stj&showHeader=false) Longguang Fan ,
Unfortunately, your solution does not work with us, the workflow and print tools error returned to appear. I will return back to schedule the recycling of Geocortex app pools every 60 mins.
What do you think??
Best,
Majdoleen0 -
Hi Majdoleen,
Recycling the app pools regularly is the best workaround we have to avoid issues with printing and workflow such what you've described.
If you wish to investigate further, please contact your local reseller for assistance.
Regards,
-Malcolm0 -
Hi Amanda / Longguang, and others,
Thanks for the questions and the suggestion, we had the same issue since about two years ago, even we now use GE4.9.1 the same issue still happened occasionally. (I did have a post about this directly pointed to the w3wp EssentialAppPool4 but wasn't got many replies). We have been recycling EssentialAppPool4 every 6 hours, however the issue still happens occasionally during busy days. I’ll try your suggestion, my question is, how that work with the scheduled recycles set on the EssentialAppPool4 in IIS, for example, if I have already set recycle on EssentialAppPool4 four time a day, and then apply gcx.dispatcherCleanupInterval every 4 hours, does that mean EssentialAppPool4 will be recycled 10 times a day?
For others want to try the settings in web.config, please remember restart IIS or restart EssentialAppPool4 after changing the file0 -
Hi Malcolm,
We had contacted our reseller but with no root solution for this frustrating issue. It continues to happen and we are hearing the shouts of our users.
Any other advice on this?0 -
Thank you Malcolm, I do agree with you, the only workaround solution is by Recycling the app pools regularly, but I hope that Geocortex Latitude developer can solve this issue at the level of Ge without the need to set the recycling the app Pools settings manually.
Best,
Majdoleen0 -
This is a very frustrating issue, but I am glad I am not the only one experiencing this. I have our app pool set to recycle every 1.5 hours between 630am and 630pm. This does not completely fix the issue as we occasionally get an error message when attempting to print and still have to manually recycle the application pool.
Does anyone know what kind of issues arise from recycling the application pool regarding the end users?
Thank you,
Tony0 -
Recycling the app pool shouldn't affect your end users in a noticable way. 0 -
Recycling the App pool can cause Printing, Exporting, and long running Workflows to crash if they are being executed as the recycle event occurs.
Recycling every 1.5 hours is pretty frequent. I would try to roll back to less frequent recycles. My assumption is that you have a bunch of Workflows? I would look at migrating as many as possible to Workflow 5 which is unaffected by this handler bug.0 -
^^ I stand corrected. Aparently the existing instance of the app pool gets a configurable amount of time called the "Startup time limit" to finish up what its doing while the next instance begins handling new requests. By default, this is 90 seconds. Any process running at the end of that time will be forced to terminate. 0
Please sign in to leave a comment.
Comments
34 comments