nonodes.aspx redirect and empty Link to Document field on all nodes
I have a site that I recently updated from 4.0.x to 4.5.2--had a few hiccups during the process related to umbsearch2 and it requiring an older version of Lucene.Net (had overwritten it with a newer one during the update process) but once I got the upgrade bugs ironed out everything seemed fine for a few days. Today suddenly the site redirects to the nonodes.aspx page and shows the stack trace. I can still login to the backend and the content is all there, but all nodes have "#" for their Link to Document field.
Does anybody know what causes this? I managed to fix it (although it's not clear to me exactly which one of my frantic steps did the actual fixing), but I'd like to figure out why this happened and how to avoid it in the future. Thanks ahead of time for any help you can give me.
FYI here are the steps I took to fix the problem. Again, note that I do not suggest any/all of these steps seeing as how I was frantically trying to resuscitate a live site that had gone dead, and I don't know which step(s) actually fixed the problem:
Renamed data/_systemUmbracoIndexDontDelete in preparation for next step...
We use umbsearch2, so I ran its reindexsite.aspx
At this point only 1 node showed up on the site, and it was one we republished while the site was down. It became the root node (it wasn't the root before).
Deleted data/umbraco.config because it only contained the 1 node.
Went into the backend, clicked on something other than Content, then clicked on Content, and all nodes were showing Link to Document values again. Browsed the site and it was fine.
Check out these posts from Darren Ferguson, it might be the same issue. Something to do with the DB not being available when the app pool re/starts. He posted a workaround also.
That sounds very promising. I didn't find anything in umbracoLog that I could point to as the culprit, so right now I'm leaning toward the IIS vs. SQL Server race condition theory. If I understand it correctly all I have to do to test that theory is recycle the app pool and see what happens? I'd have to do that after hours, but it's definitely an easy way to test.
In the meantime, if anybody else has possible causes/solutions please post them. Thanks again.
nonodes.aspx redirect and empty Link to Document field on all nodes
I have a site that I recently updated from 4.0.x to 4.5.2--had a few hiccups during the process related to umbsearch2 and it requiring an older version of Lucene.Net (had overwritten it with a newer one during the update process) but once I got the upgrade bugs ironed out everything seemed fine for a few days. Today suddenly the site redirects to the nonodes.aspx page and shows the stack trace. I can still login to the backend and the content is all there, but all nodes have "#" for their Link to Document field.
Does anybody know what causes this? I managed to fix it (although it's not clear to me exactly which one of my frantic steps did the actual fixing), but I'd like to figure out why this happened and how to avoid it in the future. Thanks ahead of time for any help you can give me.
FYI here are the steps I took to fix the problem. Again, note that I do not suggest any/all of these steps seeing as how I was frantically trying to resuscitate a live site that had gone dead, and I don't know which step(s) actually fixed the problem:
Hi,
Check out these posts from Darren Ferguson, it might be the same issue. Something to do with the DB not being available when the app pool re/starts. He posted a workaround also.
http://www.darren-ferguson.com/2010/11/2/working-around-the-%27no-nodes%27-issue-with-umbraco-45x
http://our.umbraco.org/forum/ourumb-dev-forum/bugs/13649-Site-repeatedly-reverting-to-no-nodes-splash-page?p=0
Tom,
That sounds very promising. I didn't find anything in umbracoLog that I could point to as the culprit, so right now I'm leaning toward the IIS vs. SQL Server race condition theory. If I understand it correctly all I have to do to test that theory is recycle the app pool and see what happens? I'd have to do that after hours, but it's definitely an easy way to test.
In the meantime, if anybody else has possible causes/solutions please post them. Thanks again.
is working on a reply...