4

I am not sure if anyone ran into this issue before:

We have an in house built tool to deploy code from the build server to specified destinations. Mongo reports/Custom Analytics is not working whenever we deploy code to the server and every time this happens IISReset fixes the issue.

Notes: When we deploy the code we do not deploy Sitecore/App_Config or any Sitecore specific files but we do deploy application/project related files(layouts, sub layouts, .dlls) and also web config, global.asax.

Is there any way to fix this issue other than resetting IIS?

Analytics Console Log

Improve this question
10
  • Anything relevant in the log files? Do you know if Mongo is still logging data during this period and its just the reports that are broken?
    – Chris Auer
    Commented Nov 8, 2016 at 16:30
  • other than log files errors/warnings, does this web.config file you are deploying have any analytics entries defined on it that could be overriding the analytics.enabled for example?
    – Diego
    Commented Nov 8, 2016 at 16:33
  • Most of the mongo related activities are performed through agents that have to subscribe to the Heartbeat event. Based on what you're saying, it sounds like enough of the app-pool is being changed (DLL's) to cause the app pool to send a SIGHUP to the application without fully restarting the app pool. When this happens, the Heartbeat is turned off, resulting in hooks and scheduled agents to stop running. Restarting/recycling the app pool in IIS fixes the issue. Check your logs after a deployment to see if you get the "Hosting environment shutdown" message, but no actual recycle.
    – Pete Navarra
    Commented Nov 8, 2016 at 16:55
  • If the above helps, I'll turn it into an answer.
    – Pete Navarra
    Commented Nov 8, 2016 at 16:56
  • @Diego - Nope the config files that I deploy are related to project. No Sitecore Analytics Entries.
    – Vamshi
    Commented Nov 8, 2016 at 18:42

1 Answer 1

Reset to default
2

When it comes to deployment practices, most of the time when deploying code, the worker process is going to recycle itself in order to pick up the changes that it detected. In some cases, this recycle can cause problems. With that in mind, it is generally a best practice manually recycle the app pool as part of the deployment process.

Most of the MongoDB related activities are performed through agents that have to subscribe to the Heartbeat event. Based on what you're saying, it sounds like enough of the app-pool is being changed (DLL's) to cause the app pool to send a SIGHUP to the application without fully restarting the app pool.

When this happens, the Heartbeat is turned off, resulting in hooks and scheduled agents to stop running.

Restarting/recycling the app pool in IIS fixes the issue. Check your logs after a deployment to see if you get the "Hosting environment shutdown" message, but no actual recycle.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.