We have spent a large amount of time trying to understand and fix this issue but it has proven to be very difficult to solve.
The error log entry for when the application pool restarts was added specifically for this issue. That's this one that you are seeing:
Application Stopping. Reason: A change was made to the application level
There are many reasons that an application pool can be restarted so this is just one of around fifteen different log entries that you may see. For example, if you copy a file to the bin directory the reason will state that a change has been made to the bin folder. Of course, it appears to always be the same for this issue.
We are writing that out based on what .Net gives us as the reason for why the Application_End event is called. Unfortunately there is no additional information given. We started a ticket with Microsoft hoping they could help us zero in on the exact cause, but they did not prove to be very helpful. Ultimately they decided the issue was due to writing, updating and deleting a lot of files in the app_data directory. We have always done that though and we could not reproduce the issue according to this theory. We created an app that does nothing but write, update and delete files in a specified directory and pointed that app to the app_data\logs, app_data\temp and mailprocessing folders for hours without a single application pool restart. We did hundreds of thousands of file creations, updates and deletions to each of those folders during our test.
From previous tickets for this issue it appeared that it started happening after releasing version 12.2. We had those customers revert to 12.1 where the issue did not happen. After upgrading to a later version the issue occurred again.
The initial post by Scott Hendrickson for this thread said "We started with SM Pro 7.x about 3 years ago. We just updated to SM Pro 13.2 a couple of months ago and we're having the exact same problem.". I am interpreting that to mean that the issue was also happening with version 7? Is that correct?
Jason Cross mentioned that it seemed the issue occured in 15 minute spacings on some days which could be due to background tasks operating on certain intervals. We do have various timed background tasks in webmail, so we added web service functions that can enable or disable those. These functions are specifically for troubleshooting this issue as you would generally want all of the background tasks running.
We released version 13.4 earlier today that includes these web service functions. Here is an explanation of where they are and how to call them:
You will need to be logged directly into your SmarterMail server. From there open a browser and go to your webmail login page. Change the url by appending "/services/svcServerAdmin.asmx" to the root webmail url. So for mail.smartertools.com I would go to mail.smartertools.com/services/svcServerAdmin.asmx.
Once there you should see links for each web service function. The new ones are EnableOrDisableBackgroundTask and GetBackgroundTasksStatus. The EnableOrDisableBackgroundTask function is what lets you enable or disable the various background tasks. Click on that and you will see fields for the auth username and password which need to be your system administrator credentials. The rest of the fields take either "true" or "false" as the values which enables or disables the associated background function.
The GetBackgroundTasksStatus function returns the status of each of the functions so you can verify which are running and which aren't.
Here is an explanation of what each of these functions do:
StrayFileDeletion: Cleans up any stray files it finds in the web sites App_Data\Logs, App_Data\Temp, MailProcessing and Temp folders.
RSS: Retrieves RSS feed information.
WebStats: Pushes logged in webmail user counts to the service.
Events: Retrieves reminders from the service.
ToastNotifications: Retrieves toast notificaitons from the service.
WeatherUpdater: Retrieves weather information shown on calendar page.
UploadTokenCleaner: Enforces the expiration date for files in file storage that have been made available for public download for a limited duration.
Ping: Handles pushing new items to Exchange ActiveSync connections.
You should be able to disable any of these for reasonable stretches of time without too much disruption. Can anyone that is having this issue with SmarterMail 13 install the new version and see if disabling any of these background functions will resolve the issue? Hopefully we will be able to pinpoint the issue to a specific background task. If not we will at least have eliminated those as a cause and we can look into other possibilities.