Upgrade to 2.3.1 problems - Object not set to an instance of an object
We recently did an upgrade to version 2.3.1 in our dev environment. Now we are getting random and inconsistent occurances of the Object reference not set to an instance of an object error message when running all sites, including the Charlotte demo site. If I get the error, restart the site, and follow the same workflow I won't get the error in the same place... I can't get any consistency to it... but it is happening a lot. The Geocortex log does not provide much helpful information. There are entries in the event log that indicate a NullReferenceException (often referencing JumpToExtent functionality). There are also Viewstate verification failed entries. Does anuone have any insight as to what might be going on? Thanks! -- Stuart
0
-
I am experiencing a similar problem and was wondering if you have found a solution/cause for this issue? Greetings, Arjan 0 -
Arjan and Stuart, When Essentials throws an error basically complaining that the JumpToExtent control is null ("Object reference not set to an instance of an object") it means that the application pool servicing Essentials has restarted. Essentials uses in-process session state; when the app pool restarts, all sessions are lost. Consequently, any browsers that still have a map in them will faithfully send their session key to the server, which won't have a session to load. The postback code will still run, however - until it tries to initialize the Jump To Extent box, discovers nothing inside, and throws an error. Under normal operations the application pool should not restart (eg. crash). Some activities will trigger a restart of the application pool; making a change to the web.config file is one example. There's also conditions that are configurable within IIS that determine when and why to restart the app pool. For ADF applications we recommend removing these conditions and only performing an app pool recycle during off-peak times. Your server's System and Application logs should have more information why the application pool has restarted (if there was an error condition). If you find nothing and really want to know, then you can enable more verbose output from IIS' internal code that triggers the restarts. -Malcolm 0 -
0
-
The one reason we were getting this so much was because of the session state timeout. We had ours way to high we found 20 minutes in our environment was optimal to prevent the app pools from getting to huge. I cannot wait to migrate away from the adf as this is not a problem with the rich api's
0 -
I actually found that recreating the sites from scratch in 2.3.1 took care of the problem. Not sure why or what was different but it worked for us.
0
Please sign in to leave a comment.
Comments
5 comments