On a recent DNN/2sxc installation, the DNN index functions fail with a GeneralException: "The given key was not present in the dictionary."
The stack error is:
Message:Search: Error while indexing module 458 on tab 50, portal 1
StackTrace:
at
ToSic.SexyContent.Environment.Dnn7.DnnBusinessController.GetModifiedSearchDocuments(ModuleInfo
moduleInfo, DateTime beginDate) in
C:\Projects\2sxc-dnn742\Website\DesktopModules\ToSIC_SexyContent\2sxc
Dnn\Environment\Dnn7\DnnBusinessController.cs:line 89 at
DotNetNuke.Services.Search.ModuleIndexer.IndexSearchDocuments(Int32
portalId, ScheduleHistoryItem schedule, DateTime startDateLocal,
Action`1 indexer)
InnerMessage:The given key was not present in the
dictionary.
InnerStackTrace:
at System.ThrowHelper.ThrowKeyNotFoundException() at
System.Collections.Generic.Dictionary'2.get_Item(TKey key) at
ToSic.SexyContent.ContentGroup.get_Template() in
C:\Projects\2sxc-dnn742\Website\DesktopModules\ToSIC_SexyContent\ToSic.Sxc\SexyContent\ContentGroup.cs:line
70 at
ToSic.SexyContent.ContentBlocks.ModuleContentBlock..ctor(IInstanceInfo
instanceInfo, Log parentLog, ITenant tenant, IEnumerable`1
overrideParams) in
C:\Projects\2sxc-dnn742\Website\DesktopModules\ToSIC_SexyContent\ToSic.Sxc\SexyContent\ContentBlocks\ModuleContentBlock.cs:line
82 at
ToSic.SexyContent.Environment.Dnn7.Search.SearchController.GetModifiedSearchDocuments(IInstanceInfo
instance, DateTime beginDate) in
C:\Projects\2sxc-dnn742\Website\DesktopModules\ToSIC_SexyContent\2sxc
Dnn\Search\SearchController.cs:line 55 at
ToSic.SexyContent.Environment.Dnn7.DnnBusinessController.GetModifiedSearchDocuments(ModuleInfo
moduleInfo, DateTime beginDate) in
C:\Projects\2sxc-dnn742\Website\DesktopModules\ToSIC_SexyContent\2sxc
Dnn\Environment\Dnn7\DnnBusinessController.cs:line 85
Source:ToSic.Sxc.Dnn
Recycling the application pool revives the application but the problem will occur again and again.
I found these solutions:
Delete the DNN index files and reindex
Remove and give back rights to the application pool to the index files
Convert the site in English then set it back in French
but nothing works. The problem only occurs with 2sxc modules (basic contents) and not with other modules (HTML for exemple).
Any idea to solve that?
Environment: DNN 9.1.1 2SXC 9.23
Just fyi: this really seems to be an issue - we're working on it, check out I'm guessing this is related to https://github.com/2sic/2sxc/issues/1564 and https://github.com/2sic/2sxc/issues/1561
Note that this is fixed in 9.31, and we'll release 9.32 with some more fixes.
The good news is that I don't have the problem anymore...
The bad news is that I don't know why...
As a really bas scientist, I did several actions at the same time and one of them (or in conjonction) solved the problem. What I did :
upgrade to 2sxc version 9.30
set the recycling time of the application pool to 10080 minutes (7 days)
unchecked both static and dynamic cache in IIS
installed the Windows Server updates (and rebooted the server)
Also, I'm connecting to the server using RDP. When I start my connection, I now uncheck the use of the local printers, the clipboard, and the local drives (in fact, I don't bind any local resources to the distant server). I realized that there were errors because the driver of my local printer was not installed on the remote server. Not sure it has to do with it but as I don't need these bindings anymore, I deactivated them.
Next step is to try to set back the cache and set a shorter time for recycling the application pool.
If I find something, I'll update this post.
I imagine this has to do with the reference to a path that does not exist on the server. We have been experiencing this every night after our nightly backup runs. Cycling the AppPool brings it back (as you have indicated), but we plan to upgrade to 9.30 (which was just released today - https://github.com/2sic/2sxc/releases). May the 4th be with you!
By the way, we noticed 9.23 was marked as a "Pre-Release", so this may have not been so smart to use this version? :)
Related
One of our client has a DNN Site. There was some issue happened in the server and the drive that host the site is crashed. Luckily the database was in other drive. So we have database of the site. I have a back up of the site in my local system too. Now I need to restore the site. So My question is what steps should I perform exactly?
Below are some twists that I came to know recently:
There were other sites too and they were in different DNN version. Can we know from database which version of DNN was the sites running?
I tried to put my files on server and provide connection string of database. When I start the site, it complete the installation process, but shows me default DNN Page. Please see attached image for the same.
When I checked the Log file, it is throwing below error
Unhandled error loading module. ---> System.Web.HttpException: The
file '/Portals/_default/Containers/Xcillion/NoTitle.ascx' does not
exist
DotNetNuke.Services.Exceptions.Exceptions -
DotNetNuke.Services.Exceptions.ModuleLoadException: Unhandled error
loading module. ---> System.Web.HttpException: The file
'/Portals/_default/Containers/Gravity/Title_h2.ascx' does not exist.
DotNetNuke.Services.Exceptions.Exceptions -
System.NullReferenceException: Object reference not set to an instance
of an object.
DotNetNuke.Services.Exceptions.Exceptions -
DotNetNuke.Services.Exceptions.ModuleLoadException: Unhandled Error
Adding Module to ContentPane ---> System.NullReferenceException:
Object reference not set to an instance of an object.
Then I thought the site may use the inbuilt database (I am not remembering exactly what kind of database I set up). So I copied the site code in separate folder and tried to map this folder with IIS. And that is giving me below error:
DotNetNuke.Common.Initialize - The connection to the database has failed, however, the application is already completely installed, a 500 error page will be shown to visitors"
Can anyone tell me how can I recover this site?
Thanks in Advance.
Ouch!
Having the database (or databases) is a good start.
Look in the Versions table and the last row is the last DNN Version installed. Look in the Portals table to see which portals were created in that install.
The errors that refer to Containers refer to files that are missing from the site's file system. Your IIS configuration for the site points to the root of the file system.
The module load exception probably refers to a module's files that should be in /DesktopFiles/ModuleName.
So, if you have the database AND you have a copy of the files that correspond to the database, then put them all back, make sure that the connection strings are pointed correctly in web.config ... and cross your fingers.
If you have the DNN version and the correct database, you might try doing a clean install of the DNN, install the modules that you had installed on the one that crashed, and THEN swap the clean version's database with the one that you have -- actually a copy.
Make sure that you are keeping copies, and you may be able to reconstruct lots of things.
And, it goes without saying that you should take a blood oath about making good and regular backups, and storing them on a different disk.
Running WSo2 EMM 1.1.0, everything has been working just fine except for one big issue.
From the moment I first click on an app in the App Management tab, the WSO2EMM_DB.h2.db file starts to steadily grow as long as the server is running, even with absolutely no changes. Eventually, it gets so big that clicking an app on that tab takes a ridiculously long time to load the list of devices using the app. We're talking 5+ minutes, it becomes completely unusable. I have checked the error logs and found no errors at all, every time.
Restarting the server does nothing to correct the issue. Even if I click an app on the App Management tab once, and never again, the database file will continue to grow. Even restarting the server and not logging into the EMM page, it will continue to grow.
The only thing I've found so far that can possibly help is keeping backup copies of the database file and overwriting the current file when it gets too big. Obviously that's not a solution, as I'd need to create a new backup file every time there's a change on the server, and eventually the database file would grow too big from that too.
It's not an issue with the H2 database either. Not only have I tried starting over fresh several times and have had the same behavior, but here is the only info I could find regarding this issue, and they were having the issue regardless of whether or not it was on H2 or MySQL.
I've been trying to find a solution for this for over a month with no success. Any help would be appreciated!
EDIT: It looks like this might be the subject of EMM-826. Unfortunately there seems to be no response to that bug report so far.
EDIT 2: EMM-826 was closed with a message saying the following:
This issue is fixed in the EMM 1.1.0 GA latest pack. Please get all the patches for the product/build the product from the latest source [ https://github.com/wso2/product-emm ] and try again.
Unfortunately, that did not work for me. I'm not sure what exactly I'm doing wrong, so I'll list the what I did to try to fix it:
Downloaded the EMM 1.1.0 zip from http://wso2.com/products/enterprise-mobility-manager/.
Downloaded the zip from https://github.com/wso2/product-emm and pasted the files from that into my EMM_HOME directory.
When that didn't work, I searched for patches and found I was only using patches 1-6. In the documentation I found I could download patches 7-12 here. Patches 9 and 10 didn't work right for some reason; causing me not to be able to reach the EMM dashboard or publisher. I could only access the Carbon manager. I was able to make patches 7, 8, 11, and 12 work though - with no change in behavior.
Here are the steps I take to reproduce the issue:
After setting a fresh copy of the EMM up, I log in to the EMM dashboard as Admin, set up a user account, and upload an app through the Publisher.
Register a device to the user account I set up. In this case, an Android device running Android 4.2.2.
From the dashboard, I go to App Management and click the app I uploaded. The list of devices loads, but from that point on, the database file starts growing and eventually, after several hours, becomes so large it the device list will never load.
Please help!
Found this happening also, from a quick look it's the WSO2EMM_DB.notifications table. Seems to keep a history of all notifications over time, and the info for app installs is taken from non-optimized queries, which degrade as the table grows. You 'could' delete all rows from the table, and it will re-populate as devices 'check back' and report their info.
But you'd probably want to write a query to just keep the latest notification of each type of each user (I'll leave that to someone else...) and as was mentioned, it is apparently fixed in the latest version.
Issue appears to be resolved in EMM 2.0, which can be found here.
I recently upgraded both Drupal and CiviCRM to the latest versions. Drupal works fine, and so does Civi except when I move to the Civi menu, I get a message that says "Database check failed - the database looks to have been partially upgraded. You may want to reload the database with the backup and try the upgrade process again." This happened earlier and reloading the most recent backup didn't help. We had to go back quite a ways before we found one that did, then had to reload a lot of data from .CSV files and by hand. I'd rather not go through with that again.
One thing we found when comparing the development site on my WAMP desktop (which was a new install that works well) with the one on my ISP's server is that the server version contained two MyISam-format files from, or generated by, CiviCase where Civi wants to see InnoDB-format files. My ISP, far more knowlegable than I am about MySQL, converted these two files two InnoDB and the problem remains. This leaves me with two questions:
could the MyISam files be the source of the "incomplete upgrade"? and
is there some way to reset a flag that tells Civi that the database is incomplete or to run the database check manually?
Thanks for any help. Civi seems to work OK as is, but the error message will be disturbing to my end users.
That message happens when you have begun the CiviCRM database upgrade but it hasn't finished. CiviCRM edits the version number in the civicrm_domain table to flag that you're in the middle of an upgrade, and when the upgrade completes, it should remove that.
The simple way to remove the message is to go edit that in the database, but it gets set there for a reason: your database upgrade never completed.
You should restore everything to the last version where it all was working--restore both the code and the database. Play around for a bit and make sure nothing funny is happening.
Run a normal CiviCRM upgrade, replacing the files and running the upgrade script. Take note of anything that seems funny when the upgrade script runs. You might try doing a minor upgrade--just a point release--simply to be sure that any upgrade is working fine.
At this point, you should either have no problems or a much more detailed problem.
Finally, please note that there is now a CiviCRM-specific StackExchange site, which is where you'll find the most CiviCRM experts to answer your questions.
I'm developing for GAE-Python 2.7 on Mac using Eclipse + PyDev and, since the SDK 1.7.6 (where the new dev_appserver was introduced), I'm having a "DuplicatePropertyError" 4 out of 5 times (on average) when executing the first request. Also, even if the first request goes fine, the error might appear in later requests.
This error is only happening in development (in production everything goes fine) and prior to 1.7.6 I never had this.
I didn't pay too much attention to this problem because, so far, I was using the old_dev_appserver in order to be able to continue debugging my app (Google broke support to pydevd by using stdin/stdout for ipc in the new dev server). However, since the old dev server will be dropped from July 1st, I think it's time to start using the new one :-).
Is anyone else experiencing this problem? Any solution/workaround?
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/ext/db/__init__.py", line 515, in __init__
_initialize_properties(cls, name, bases, dct)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/ext/db/__init__.py", line 430, in _initialize_properties
attr.__property_config__(model_class, attr_name)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/ext/db/__init__.py", line 3686, in __property_config__
self.collection_name))
DuplicatePropertyError: Class Organization already has property wagesheetrow_set
INFO 2013-06-07 15:13:54,864 server.py:585] default: "GET / HTTP/1.1" 500 -
Just figured it out! Apparently the error is coming when creating a ReferenceProperty without giving it an explicit collection_name.
For example, this might trigger the error:
class WageSheetRow(db.Model):
organization = db.ReferenceProperty(Organization)
and this is the correct way:
class WageSheetRow(db.Model):
organization = db.ReferenceProperty(Organization, collection_name='aName')
This never happened before with the old server but, apparently, the new server (1.7.6+) has changed the way of initialising instances.
It's also to mention that exactly the same code might trigger the error in one specific machine, but not in another one running exactly the same piece of code.
We have had multiple DNN sites running for quite a few months now without any issues. Twice in the last 3 days our sites have gone offline by the addition of the app_offline.htm file in the root dir.
There is only one developer with access to the sites at a coding / directory viewing level and the file is generated at weird times times when he is NOT accessing our network.
We are not publishing anything to the server ( and have not published any .net code in days ), upgrading, changing code, or even modifying content. Has anyone run into this issue?
It sounds like someone is messing with your server. Can you view the event logs to see who is accessing your server? Do you have the ability to change the passwords on the box?
Mark