Search brakes with “Object reference error…..”

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

I got a question from a colleague today telling me that when she presses the search button in the Search skinobject she gets an “Object reference not set……” error

when you look at the Event log of that portal the stack trace looks something like:

to avoid (or solve) this problem, you need to have a page in your portal (usually Search results) which has on it the Search Results module.

After you put that module on such a page you need to hit re-index of the search and everything should work ok.


Filed under: DotNetNuke, Q&A
Written on: 03 Apr 2006 · 1 Comment »

File syncronization timeout

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

Again one of the things I see asked often.

My answer usually:

Restarting the process will not help you.

I have the same problem. The problem is that the syncronization functionality is not optimized for high amounts of files, and when you click synchronize the application takes ALL the files from ALL portals, caches that list (my problem came at around 10 000 files on one host), and for each file extracts that list from the cache, deserializes it and creates a new object (well copy) of the one from cache (also a veeeery expensive operation).

All of this works for a small amount of files, but for a large one (like I had on one host) it lasted for me for about 30-40 minutes each time for the host, and for a portal syncronize (for a portal which had 1200 files) it took about 5-6 minutes.”

which is usually followed by another one:

Well I found it best to do 2 things:

1. Not use the snycronization at all - do everything through file manager (so without FTP)

2. Re-program the syncronization routine - I’ve actually done this, and have cut times on mine 1200 files from 6 minutes to 8-10 seconds of snycronization. The only problem is that it contains one bug to which I haven’t yet had time to give to solve it (some files still remain on the file system and do not end up in the db, I’m not sure that this is my bug, maybe even it’s present in the core syncronization itself) 

hope this helps

I have pasted this here so that:

a) People googling can find it (I know I’ve spent some time searching the internet)
b) So that I can reference it in my answers to the forums


Filed under: DotNetNuke, Q&A
Written on: 01 Apr 2006 · 3 Comments »

DotNetNuke process 100% CPU Usage

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

I see different people asking on DNN forums about CPU being occupied by DNN allot (mostly it spikes to 100%). As I have recently spent some time investigating this I often answer to these questions with something like:

“HI,

We’ve bean also having similar problems (CPU 100%). Mostly it was due to 2 possible reasons (if we can eliminate the server as an issue?!?!)

What is important about these things is that they all still cause problems after improving the performance (well actually execution time) with some standard things (like compression, moving viewstate to the server, improving caching).

So guys you have some real problems:

1. Schedule problems

Poorly programmed scheduled jobs. One good example of this is the FileSyncronization Schedule, if you have allot of files it will very likely spike your server to 100%. I’ve described this problem already on this thread

2. Module problems

Some of the modules are built well, some are not…. also some are configured well, some are not…. to be more concrete, we turned on module caching for DnnBB forum, and with public pages it would just get *stuck* and loop into something until the timeout would brake.

When viewing the application internals with WindowsDebugger at time when the cpu was at 100% I either found only run-away threads with scheduler or DnnBB executing allot of repetitive statements. For DnnBB I got the same result when viewing the SQL database with SQL Profiler.

My immediate cure for the problem was:

1. Turn off file synchronization (it ran every hour, for 40 minutes each time - spiked the server, we had about 10000 files on that host, more info on the mentioned thread above)

2. Turn of module caching for DnnBB (now the forum runs ok)

I’m not sure that these are all of our problems, but with this we solved most of them, and the server is breathing allot easier now!

hope this helps a bit

I have pasted this here so that:

a) People googling can find it (I know I’ve spent some time searching the internet)
b) So that I can reference it in my answers to the forums


Filed under: DotNetNuke, Q&A
Written on: 01 Apr 2006 · No Comments »