Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDevelopment and...Development and...DNN Platform (o...DNN Platform (o...Very bad Bug in the new Caching providerVery bad Bug in the new Caching provider
Previous
 
Next
New Post
10/8/2009 9:43 AM
 

I just reported it on Gemini : http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=10862&PROJID=23

Yet I think it's bad enough to require direct action, thus that redundant post.

To make it quick: the new caching system prefixes all cache keys with "DNN_", yet the dependency keys are left untouched.

As a consequence, any item set with a dependency is discarded and doesn't get into the cache.

 

Edit: While I'm here dealing with performance issues, and since the forum won't let me add a new thread, I'd love to see the following issue finally taken into account:

http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=4710&PROJID=2


Jesse
CTO - Aricie
 
New Post
10/12/2009 9:56 PM
 
Sorry to hijack my own thread again, but I still cannot create any new thread in the forum
(feel free to move that post to the appropriate location, see http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/7/threadid/334873/scope/posts/Default.aspx for the corresponding bug report)
 
I've been struggling with accessing the proper current locale from a HttpModule handling the PostRequestHandlerExecute event.
 
Here is what I'm stuck with:
  • As a reminder, the Dnn Locale is set during the DotNetNuke.Framework.PageBase.OnInit method call

    • the PageCulture Property getter figures out the proper culture to apply according to the various fallback strategies (query/cookie, profile, browser…)
    • Along the way, a cookie is set with the corresponding locale through Localization.SetLanguage(strValue)
    • The culture is then applied to the Thread.CurrentThread.CurrentCulture and Thread.CurrentThread.CurrentUICulture
    • New Localization().CurrentCulture is really a shortcut to Thread.CurrentThread.CurrentCulture, which returns the expected value anywhere during the Handler execution
       
  • There are two layers of .Net code that prevent accessing such a value after the handler execution (i.e in a HttpModule or a ResponseFilter for instance):

    • The System.Web.UI.Page.ProcessRequest() method retrieves the current thread culture before processing and calls RestoreCultures(ByVal currentThread As Thread, ByVal prevCulture As CultureInfo, ByVal prevUICulture As CultureInfo) after processing, thus undoing any change made during the page life cycle
       
    • Both ApplicationStepManager and PipelineStateManager from System.Web.HttpApplication do wrap  any async call to ResumeSteps with calls to HttpApplication.ThreadContext.Enter and HttpApplication.ThreadContext.Leave which involve calls to ThreadContext.SetRequestLevelCulture and ThreadContext.RestoreRequestLevelCulture.
      Similarly to the Page.ProcessRequest method, those calls result in the current thread culture being saved and restored on each asynchronous step call
       
  • I hoped I could get some help from the following:

    • The System.Web.Page class offers an Overridable Sub InitializeCulture() as an alternative to deal with the current culture, a call to that method is dynamically inserted by the System.Web.Compilation.BaseTemplateCodeDomTreeGenerator.BuildBuildMethodInternal when the IHttpHandler for the aspx is built.
       
    • The ThreadContext.SetRequestLevelCulture method alternatively relies on the Page.DynamicCulture and DynamicUICulture properties if available, which in turns are affected by the System.Web.Page.Culture and System.Web.Page.UICulture properties
       
  • Accordingly, I thought I could get away with updating the DotNetNuke.Framework.PageBase class such that:

    • The locale init logic is place in the InitializeCulture rather than OnInit
    • The Page.Culture and Page.UICulture are both set, rather than simply the Thread.CurrentThread.CurrentCulture and UI counter part
 
Unfortunately, that did not solve my issue. Immediately after Handler completion, the thread culture still resets to en-Us (as defined in my web.config file, probably because in classic mode as well as in integrated mode, the steps are executed synchronously).
I guess I will have to rely on the response cookie for now (defined during PageBase Init by Localization.SetLocale), which should be ok although I don’t like that idea so much.
 
 
Does anyone have a better idea?
 
 
In the mean time, I reckon that what I’m experiencing was not the expected behavior when relying on the thread culture in the first place, and it should not be difficult to provide a reliable location for the culture, for instance in the PortalSettings.
 
One might argue that since there is a fallback based on the User Profile, its value must be defined after authentication, rather than on the BeginRequest event as the PortalSettings. However I think that can be mitigated:
  • Since the cookie value has priority over the profile value, I guess there are only very rare cases when the profile value is actually taken into account (AD authentication is one I can think of)
  • I don’t see any problem redefining the value on PostAuthenticate or PageInit event if needed, since for now we don’t have access to the proper culture beforehand anyway.
Thanks for reading so far, and for any further advices. 

Jesse
CTO - Aricie
 
New Post
11/13/2009 6:51 AM
 

Do you have any new concerning the caching issue?

Since 5.2 is to be published very soon, it would be nice to have that fixed.

Just as a reminder, for now any legacy use of a cache based dependencies invalidates the cache item, which could cause critical performance issues in quite a few DNN instances.

I guess I could have posted on the beta forum, which seems a better place, but again I can't create any new thread.


Jesse
CTO - Aricie
 
Previous
 
Next
HomeHomeDevelopment and...Development and...DNN Platform (o...DNN Platform (o...Very bad Bug in the new Caching providerVery bad Bug in the new Caching provider


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out