Small width layout Medium width layout Maximum width layout Small text Medium text Large text
     Search
Downloads Downloads Directory Directory Forums Forums Forge Forge Blogs Blogs        Marketplace Marketplace Careers Program Careers
Products › Development › Forge › Group - Localization Register  |  

 

dnn_ct_localization_170x64.gif

 

  Quick Links  
 


  Team Leadership  

Vicenç Masanas

VicencMasanas.jpg

 


  DotNetNuke Projects  
The DotNetNuke Projects are a special category of platform extensions which are developed by volunteers to conform to the high professional standards mandated by DotNetNuke Corporation. The DotNetNuke Projects are distributed as a standard part of the DotNetNuke core application release offerings.

 


AppTheory specializes in solutions based on the DotNetNuke platform and has 2 employees on the DotNetNuke Core Team.
  Ads  
OnyakTech
 


  Sponsors  

Meet Our Sponsors

AspDotNetStoreFront - E-Commerce by Design - The Leading ASP.NET shopping cart platform for developers!
Click here to go to dev.live.com for Windows Live developer resources
SteadyRain
DataSprings - Great Ideas. Always Flowing.
R2integrated - formerly bi4ce
Jango Studios - Skins, Modules and Hosting for DotNetNuke
 


DotNetNuke® Project :: Localization

DotNetNuke is used internationally by web developers to quickly build professional web applications.  Given the International community that DNN serves, it is necessary to allow DNN to build systems that cater to the specific culture of both the hosting organization, and the individual end users/site visitors.  In some instances, these sites will serve a wide range of cultures while other sites target a specific culture.

Our goal is to provide a set of know procedures to simplify creation of multilingual web sites. This will include a common API for Core DotNetNuke as well as 3rd party modules, standard procedures to add new languages, resource management, built-in support for translating resource files, etc.

The initial release of Multilingual Translations includes only static translations.  This means that DotNetNuke framework will convert static strings, but will not convert "dynamic content" (i.e. content stored in the database).

We highly encourage everybody who's interested in this area to participate in our Forums and get involved in improving DotNetNuke ML support.

 


Localization Project Blog
Jan 26

Posted by: Vicenç Masanas
1/26/2008 10:59 AM

I've been fighthing for long with an issue we have on a quite big installation (75+ portals, 6500+ pages, 11000+ modules).
The issue only manifested when installing some modules and it would cause the application to die because of a timeout, so we were unable to install any new modules.

The problem turned out to be in the way the installer process the .dnn file and how it updates the module information.
Basically it went that way:
- Register the DesktopModules
- Register any ModuleDefintions for the modules
- Register all the ModuleControls for all definitions

So in a medium-large module this could be like 4-5 modules, 10-12 moduledefinitions, and 30-40 controls.
The problem is that in each of these updates the system did a clear on the host cache. So all the information that DNN uses to cache was cleared after each of these updates (so around 50 times). That caused that the same information was read again from the db after each call causing at the end the timeout.

The issue with this problem is that it would only appear in big sites and when installing big modules. This it's like and exponential issue: the bigger the site and the bigger the module the easier you'll get this error.

We changed the code so next version will include the fix for this but in the meantime you can patch your DNN installations by doing this easy fix (this applies to any DNN version up and including 4.8). To solve this issue you'll have to open the DotNetNuke solution in VS.NET and recompile the DotNetNuke.dll:

In PaDnnInstallerBase.vb, look for method:
Protected Overridable Sub RegisterModules(ByVal Folder As PaFolder, ByVal Modules As ArrayList, ByVal Controls As ArrayList)

change the following calls:
objDesktopModules.UpdateDesktopModule(objDesktopModule)
objModuleDefinitons.UpdateModuleDefinition(objModuleDefinition)
ModuleControlController.UpdateModuleControl(objModuleControl)

to:
objDesktopModules.UpdateDesktopModule(objDesktopModule, False)
objModuleDefinitons.UpdateModuleDefinition(objModuleDefinition, False)
ModuleControlController.UpdateModuleControl(objModuleControl, False)

and just before this line, at the end of the method code:
InstallerInfo.Log.EndJob(REGISTER_End)

add
DataCache.ClearHostCache(True)

In DesktopModuleController.vb change:
Public Sub UpdateDesktopModule(ByVal objDesktopModule As DesktopModuleInfo)
    DataProvider.Instance().UpdateDesktopModule(objDesktopModule.DesktopModuleID, objDesktopModule.ModuleName, objDesktopModule.FolderName, objDesktopModule.FriendlyName, objDesktopModule.Description, objDesktopModule.Version, objDesktopModule.IsPremium, objDesktopModule.IsAdmin, objDesktopModule.BusinessControllerClass, objDesktopModule.SupportedFeatures, objDesktopModule.CompatibleVersions, objDesktopModule.Dependencies, objDesktopModule.Permissions)
    DataCache.ClearHostCache(True)
End Sub

to:
Public Sub UpdateDesktopModule(ByVal objDesktopModule As DesktopModuleInfo)
 UpdateDesktopModule(objDesktopModule, True)
End Sub

Friend Sub UpdateDesktopModule(ByVal objDesktopModule As DesktopModuleInfo, ByVal clearCache As Boolean)
 DataProvider.Instance().UpdateDesktopModule(objDesktopModule.DesktopModuleID, objDesktopModule.ModuleName, objDesktopModule.FolderName, objDesktopModule.FriendlyName, objDesktopModule.Description, objDesktopModule.Version, objDesktopModule.IsPremium, objDesktopModule.IsAdmin, objDesktopModule.BusinessControllerClass, objDesktopModule.SupportedFeatures, objDesktopModule.CompatibleVersions, objDesktopModule.Dependencies, objDesktopModule.Permissions)
 If clearCache Then DataCache.ClearHostCache(True)
End Sub

In ModuleDefinitionController.vb change:
Public Sub UpdateModuleDefinition(ByVal objModuleDefinition As ModuleDefinitionInfo)
    DataProvider.Instance().UpdateModuleDefinition(objModuleDefinition.ModuleDefID, objModuleDefinition.FriendlyName, objModuleDefinition.DefaultCacheTime)
    DataCache.ClearHostCache(True)
End Sub

to:
Public Sub UpdateModuleDefinition(ByVal objModuleDefinition As ModuleDefinitionInfo)
 UpdateModuleDefinition(objModuleDefinition, True)
End Sub

Public Sub UpdateModuleDefinition(ByVal objModuleDefinition As ModuleDefinitionInfo, ByVal clearCache As Boolean)
 DataProvider.Instance().UpdateModuleDefinition(objModuleDefinition.ModuleDefID, objModuleDefinition.FriendlyName, objModuleDefinition.DefaultCacheTime)
 If clearCache Then DataCache.ClearHostCache(True)
End Sub

And finally in ModuleControlController.vb change:
Public Shared Sub UpdateModuleControl(ByVal objModuleControl As ModuleControlInfo)
    provider.UpdateModuleControl(objModuleControl.ModuleControlID, objModuleControl.ModuleDefID, objModuleControl.ControlKey, objModuleControl.ControlTitle, objModuleControl.ControlSrc, objModuleControl.IconFile, CType(objModuleControl.ControlType, Integer), objModuleControl.ViewOrder, objModuleControl.HelpURL, objModuleControl.SupportsPartialRendering)
    DataCache.ClearHostCache(True)
End Sub

to:
Public Shared Sub UpdateModuleControl(ByVal objModuleControl As ModuleControlInfo)
 UpdateModuleControl(objModuleControl, True)
End Sub

Public Shared Sub UpdateModuleControl(ByVal objModuleControl As ModuleControlInfo, ByVal clearCache As Boolean)
 provider.UpdateModuleControl(objModuleControl.ModuleControlID, objModuleControl.ModuleDefID, objModuleControl.ControlKey, objModuleControl.ControlTitle, objModuleControl.ControlSrc, objModuleControl.IconFile, CType(objModuleControl.ControlType, Integer), objModuleControl.ViewOrder, objModuleControl.HelpURL, objModuleControl.SupportsPartialRendering)
 If clearCache Then DataCache.ClearHostCache(True)
End Sub

now recompile and just copy DotNetNuke.dll to your DNN installation.

As always remember to make a copy of your files before doing any upgrade and try it on a testing site.

Conclusion:
Caching is a very important thing since it can save your application from the most expensive db calls (and in DNN we have quite a few of those).
But it's also very important to understand how it is used and check that your code is working fine in different situations.

Tags:

Re: Big sites, big modules, big problems? Easy solution!

Vicenç, I've been struggling with the same thing when installing one of the CATALooK modules. My solution was to open the .dnn file of the PA, reduce the number of modules it was referencing, re-zip it, then upload. I would repeat this process until all of the modules were installed. It was a bit of effort (a pain, actually), but it worked.

I'm very glad to learn of the cause, and to see that this will be corrected in the next version of DNN. Thank you for blogging on this.

By YodaRocks on   1/26/2008 3:30 PM

Re: Big sites, big modules, big problems? Easy solution!

Nice catch!

By hismightiness on   1/30/2008 3:55 PM

Re: Big sites, big modules, big problems? Easy solution!

What version of DNN was it actually corrected in?

By djbaldwin on   3/2/2008 3:30 AM

Re: Big sites, big modules, big problems? Easy solution!

Are these the exact changes you made or are they slightly different in the actual bug fix? I have found making these changes causes issues. We use the installer (/install/install.aspx?mode=installresources) and it seems modules get installed, but changes aren't reflected. For example, a module has its Settings control changed (add new field) and when visiting the settings module it still shows the old one. Simply installing the updated module manually through Host -> Module Definitions fixes the problem. What is different between these two processes?

By msumerano on   3/12/2008 3:51 PM

Re: Big sites, big modules, big problems? Easy solution!

Can I have a compiled version of the DotNetNuk.dll for version 4.8.1, as I do not have the capabilities to do the above. Your assistance would be greatly appreciated. My email is marcus(at)nutri.co.uk

By mknaidoo on   3/17/2008 9:34 AM

Re: Big sites, big modules, big problems? Easy solution!

Ditto...Would you consider recompiling the DotNetNuke.dll for version 4.8.2 - and make it available for download somewhere? Very much obliged..

By cjepp on   3/27/2008 7:07 PM

Re: Big sites, big modules, big problems? Easy solution!

DNN 4.8.2 already includes this fix.

By vmasanas on   3/28/2008 8:51 AM

Re: Big sites, big modules, big problems? Easy solution!

I am having this same issue on a 4.8.0 sites that was upgraded to 4.8.2 and while before I did not run into the above issue, I now am running into it on nearly every module I try to install. Just to make sure I RDP to the server itself and install the PA locally and still same thing. I am seeing after a timeout this entry in the Application Log of the server:

Event Type: Warning
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1309
Date: 3/30/2008
Time: 10:57:13 AM
User: N/A
Computer: **********
Description:
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 3/30/2008 10:57:13 AM
Event time (UTC): 3/30/2008 5:57:13 PM
Event ID: b41dff882b6041178f7e8ee00da35479
Event sequence: 20
Event occurrence: 1
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/8751/ROOT-1-128513724647187500
Trust level: Full
Application Virtual Path: /
Application Path: C:\Inetpub\wwwroot\********\wwwroot\
Machine name: SV2279

Process information:
Process ID: 2804
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE

Exception information:
Exception type: ThreadAbortException
Exception message: Thread was being aborted.

Request information:
Request URL: http://********/Default.aspx?TabId=19&ctl=Edit&mid=323&ftype=Module&rtab=18&portalid=0
Request path: /Default.aspx
User host address: ********
User: host
Is authenticated: True
Authentication Type: Forms
Thread account name: NT AUTHORITY\NETWORK SERVICE

Thread information:
Thread ID: 1
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: False
Stack trace: at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error)
at System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)
at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)

By rward on   3/30/2008 7:10 PM

Re: Big sites, big modules, big problems? Easy solution!

Well I just tested this on a clean 4.8.2 install (new site + new db) and am not experiancing these issues.

I hate upgrading. Sometimes it seems that the only sure way of knowing that things work is to rebuild DNN with a clean install, but when you have 50 portals in a single instance, this is impossible.



By rward on   3/30/2008 7:20 PM

Re: Big sites, big modules, big problems? Easy solution!

I'm on 4.8.2 and I still have this issue. I have same kind of site you're talking about (~100 portals, ~10,000 modules). I can reproduce this issue reliably with the DNN Store module. I looked through the DNN file, and it has five elements. This means the during install, there is still a lot of cache clearing going on.

Would it make sense to move this line:

DataCache.ClearHostCache(True)

out of PaDnnInstallerBase.RegisterModules(), or add make the call conditional based on a Boolean parameter.

Then, in PaDnnInstallerBase.Install(), add the call to clear the cache after all folders are installed?

By DrewTheRat on   5/2/2008 8:15 PM

Re: Big sites, big modules, big problems? Easy solution!

Quick follow-up on my previous comment. I tried my idea, and it worked for me. No more module install timeout!

By DrewTheRat on   5/2/2008 8:56 PM

Re: Big sites, big modules, big problems? Easy solution!

A follow-up to my follow-up. ALthough I still like my idea, it wasn't enough. I started geting the ThreadAbortExceptions again. This was the issue - no matter what I did, the install would not complete before running threads were aborted as part of the application shutdown triggered by the file updates. After some reasearch and experimentation, I believe the answer is to add the shutdownTimeout attribute to the httpRuntime element of web.config. This timeout affects how long a thread can run after a shutdown event before it gets aborted. I set it to 300 (5 mintues) and that did the trick. Here's the httpRuntime line from my web.config file:

By DrewTheRat on   5/8/2008 10:28 PM

Problem still exists ...

We recently upgraded to 4.8.4 and we still have this problem without commenting out calls to clear the host cache in the places you mention.

By iujeff on   7/2/2008 9:46 PM
 


Where Every Home is an Investment
Where Every Home is an Investment
www.nestbrokers.com
Faculty of Graduate and Postdoctoral Studies
At the graduate level, the University of Ottawa offers more than 180 graduate certificates, master's degrees and PhDs, as well as interdisciplinary programs such as Women's Studies and Canadian Studies. Many postdoctoral opportunities are available in both the sciences and the humanities. For further information, please consult the site of the Faculty of Graduate and Postdoctoral Studies.
www.grad.uottawa.ca
Vekkin Solutions
Vekkin Solutions provides complete website solutions and custom module development to churches and small businesses.
www.vekkin.com

DotNetNuke Corporation   Terms Of Use  Privacy Statement
DotNetNuke®, DNN®, and the DotNetNuke logo are trademarks of DotNetNuke Corporation
Hosted by MaximumASP