Shane
Posts:28
| | 08/01/2007 2:21 PM |
| I am getting some odd behavior from the Snapsis menu in my DNN installation. I can't determine a cause or a predictable frequency, but on occasion the menu will sometimes only display the first top-level menu item and it's subpages. All other top level menu items will not display and none of the links on the site will work correctly. All links will instead re-direct to the home page. The only thing that will fix this problem is to restart the application or run an AppPool recycle in iis. We have noticed that this seems to happen when the AppPool automatically recycles based on the AppPool settings. In summary, the AppPool recycles and sometimes the problem appears and can only be fixed by another recycle. We saw more of these errors in the beginning, but we still see them occasionally now.
Our environment is running on a web farm using load balanced servers and DFS and all of our other issues have been resolved except for this one. Do you have any idea what could be causing this or have a starting point for investigating this kind of problem?
Thanks,
Shane | | | |
|
|
|
John Mitchell
Posts:3478
| | 08/01/2007 2:31 PM |
| Hi Shane,
I'm just guessing, but it could be a problem with caching in the Menu not being invalidated properly across the web farm. You can try putting CacheTabs="False" in your menu declaration in the skin and see if that makes it work better. | | | |
|
Shane
Posts:28
| | 08/02/2007 8:21 AM |
| | Thank you for the suggestion. I still saw the error this morning unfortunately. I think it does have something to do with the cacheing, but I'm not sure where the problem is coming from. Do you think the new stability patch could help? | | | |
|
John Mitchell
Posts:3478
| | 08/02/2007 9:21 AM |
| What new stability patch? The latest release of DNN? It's possible that it will help, but I don't think they fixed in any caching bugs in the latest release. I have also seen reports of simular problems from people upgrading to this latest release (their host menu disappears until restart).
Do you have more than one worker process assigned in your app pool? | | | |
|
Shane
Posts:28
| | 08/02/2007 9:30 AM |
| | I was referring to the latest release of DNN, yes. I only have one worker process, but I do have two applications running in the pool. Could this possibly have some effect? | | | |
|
John Mitchell
Posts:3478
| | 08/02/2007 9:38 AM |
| As long as they are not pointing at the same DNN instance then you can have multiple applications in the same app pool without problems in DNN.
The next time it happens, try just restarting the DNN application by modifying the web.config. That'll point to a caching problem in DNN. | | | |
|
Shane
Posts:28
| | 08/02/2007 3:33 PM |
| I forgot to mention that this error only occurs on one server at a time. When you mentioned to change the web.config file, I'm not sure how this will show if the problem is a caching problem. Will changing the web.config not fix the problem if the problem is caching?
Thanks, sorry I'm a little thick on this one :) | | | |
|
John Mitchell
Posts:3478
| | 08/02/2007 3:38 PM |
| | Right, changing the web.config will recycle the app and clear the cache for the application, which would still point to caching in the application if it works. But it will eliminate anything outside of that like application pool and IIS settings. | | | |
|
Shane
Posts:28
| | 08/02/2007 5:04 PM |
| | Ah ok, I will try that tomorrow, thank you. | | | |
|
GabeOnSnapsis
Posts:5
| | 08/08/2007 7:50 AM |
| I concur the problem could be in caching because it appears that if we turn site caching off, the problem goes away. Then again the site become unusablily slow so it could be related to a lower load on the app. Could this be related to what is being replicated across the DFS?
Are there any folders in DNN that should not be replicated? Because of the problem, we have changed the apppool to recycle every hour in case our temp fix of recycling the apppool when we detect the problem automically does not kick in. Since we have made that change, I have noticed that the problem happens more often. It seems that when the apppool recycles is when this problem happens and is not corrected until it it recycled again. Thanks for your help on this problem, Gabriel | | | |
|
John Mitchell
Posts:3478
| | 08/08/2007 11:51 AM |
| It's really sounding like you have more than one process pointing at the same physical DNN instance. Check the App Pool settings to make sure it is only set for one worker process. Also, the cache folder under /portals/_default/cache should not be replicated.
DotNetNuke recommends that they be shared between the web servers, but I think it will work better if each web server uses it's own cache folder. If each server is using it's own, then you may notice a delay from server to server when a page is removed or updated, but you will not have the problem of one server thinking it has the item cached when it really is not. | | | |
|
GabeOnSnapsis
Posts:5
| | 08/08/2007 1:09 PM |
| John,
Thanks for the reply.
I confirmed that there is only one worker thread in the web garden.
I added a replication exclusion to the DFS for \portals\\cache\. Only time will tell if that is the solution. I noticed that in the cache folders for both default and the portal that there are no new files in there as if it is not being used. That does not raise my confidence, but at this point I am willing to try anything.
We should know if this works within a day. I will keep you posted. Thanks again,
Gabriel | | | |
|
John Mitchell
Posts:3478
| | 08/08/2007 1:41 PM |
| | If those folders do not have cache files, then you may not have EnableCachePersistence and/or EnableWebFarmSupport set to true in the web.config. | | | |
|
GabeOnSnapsis
Posts:5
| | 08/08/2007 2:01 PM |
| If we change the caching mode to file, then it seems files are added to these folders. We currently have caching set to memory. We have tried it both ways and the problem would appear either way.
Here are the settings you mentioned from our config:
add key="EnableWebFarmSupport" value="true" /
add key="EnableCachePersistence" value="false" /
Thanks,
Gabriel | | | |
|
John Mitchell
Posts:3478
| | 08/08/2007 2:08 PM |
| Ok, I would leave the module caching mode on memory. That is the one that puts files in the portals/xx/cache folder if it is set to disk.
With EnableWebFarmSupport set to true you should be getting stub dependency files in the /portals/_default/cache folder though. Those are the files that will invalidate the cache when they are deleted. Maybe you are using the BroadcastPollingCachingProvider instead of the FileBasedCachingProvider, in that case then it would be normal not to have the cache dependency files.
| | | |
|
GabeOnSnapsis
Posts:5
| | 08/08/2007 2:49 PM |
| Exactly. We are using the BroadcastPollingCachingProvider as the default caching provider. I beleive that change was made based on some instructions we found for setting up DNN on a web farm. Do you think that could be the problem? If the problem continues, then I am willing to try changing it as we are not replicating the cache folder, it "should" not cause a worse problem.
OT: Also, you seem to know your stuff. Can you recommend any books for admin'ing a DNN server. Something a network admin type as opposed to a .NET developer type would understand? Also, something that covers DNN in a web farm would be great. I have not found a lot of info on this specific subject.
Thanks,
Gabriel | | | |
|
John Mitchell
Posts:3478
| | 08/15/2007 3:24 PM |
| Hi Gabriel,
Sorry, I missed this reply. I personally think using the broadcast polling is better, and I don't think the problem is directly related to that. I have seen a few more reports of menus not showing in DNN 4.5.3+, so it may be an internal caching problem.
Were you able to isolate the problem? I don't know of any books that are better than the delivered documentation, but feel free to ask questions in my DotNetNuke Support Forum | | | |
|
GabeOnSnapsis
Posts:5
| | 08/16/2007 4:17 AM |
| John,
We are still having the same issue.
>>With EnableWebFarmSupport set to true you should be getting stub dependency files in the /portals/_default/cache folder though<<
This is not happening.
I guess I need to get into the DNN source ocde and dig in there for a while as I am not sure where to look next.
Let me know if you have any other ideas. Thanks.
Gabriel | | | |
|