bug with cache in Profiles 1.03 is causing performance issues (for us anyway)

8 views
Skip to first unread message

Meeks, Eric

unread,
May 7, 2013, 3:52:24 PM5/7/13
to profi...@googlegroups.com

If you look at the Cache.cs file, you can see that one of the methods takes 3 arguments:

 

static public void Set(string key, Object data, Int64 dependencykey)

 

This does some stuff and then calls into a 4 argument Set method that has the timeout as well.  Here’s the thing.  It looks like some of the code calls this 3 argument Set method correctly, with the 3rd argument being the nodeid of some dependent items.  But many places in the code call this thinking that the 3rd argument should be the timeout:

                    //Defaulted this to be one hour

                    Framework.Utilities.Cache.Set("GetDivisions", divisions, 3600);

 

When this happens, the item is never even added to the cache because of the confusion with the dependency key.  We use the cache heavily with our OpenSocial ORNG work so that’s how we noticed. 

 

Can someone confirm?

 

Thanks

Eric

James Norman

unread,
May 7, 2013, 4:09:46 PM5/7/13
to profi...@googlegroups.com
wow, thats a pretty good catch. I need to fix that. Let me look it
over before I can make a recommendation.

j
> --
> You received this message because you are subscribed to the Google Groups
> "ProfilesRNS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to profilesrns...@googlegroups.com.
> To post to this group, send email to profi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/profilesrns?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

Nick Brown

unread,
May 8, 2013, 3:59:09 AM5/8/13
to profi...@googlegroups.com
Eric / James

We had seen the same issue, I have a fix that I have been testing that I will send to you. I haven't committed it back to GitHub yet.

Nick

Meeks, Eric

unread,
May 8, 2013, 12:22:02 PM5/8/13
to profi...@googlegroups.com

Thanks, we made a fix as well.

 

I also noticed something else where I could use some verification, and this one had big implications for us:

 

It seems that .NET will mark any CacheDependency object as HasChanged=TRUE whenever a matching key is added or removed from the cache.

So… on line 50 of Cache.cs we call a method to create a CacheDependency object immediately prior to adding an object to the cache.  The CreateDependency method first creates the CacheDependency object, then it adds an appropriate key (and placeholder dummy value) into the cache.  When this happens, the CacheDependency object goes from HasChanged=FALSE to HasChanged=TRUE.  When the call returns to line 50 in Cache.cs, the HttpRuntime.Cache.Insert method is called but the object is immediately rejected from the cache because of the HasChanged value. So in other words, caching is completely disabled for any item with a dependency.

 

Fixing the bug might just be a matter of swapping lines 151 and 152 in Cache.cs so that you first add the key, and then create the object.  To be safe we did more and also added a check to see if the key is already in the cache:

        static public CacheDependency CreateDependency(string key)

        {

            String[] dependencyKey = new String[1];

            dependencyKey[0] = "Node Dependency " + key;

            CacheDependency dependency = null;

 

            if (key != "0")

            {

                if (HttpRuntime.Cache[dependencyKey[0]] == null)

                {

                    HttpRuntime.Cache.Insert(dependencyKey[0], Guid.NewGuid().ToString());

                }

               dependency = new CacheDependency(null, dependencyKey);

            }

 

            return dependency;

        }

 

Eric

James Norman

unread,
May 8, 2013, 12:32:12 PM5/8/13
to profi...@googlegroups.com
what did you guys do to fix the first issue with Cache? It looks like
there are 7 references to the call where I passed in a hard coded
value for a timeout and its accepted as the dependency key. The idea
was the Subject would be the dependency key so if any edit takes place
for that Subject nodeid the cache would cleaned out and then reloaded
the next time the profile data is retrieved for that Subject nodeid.




On 5/8/13, Meeks, Eric <eric....@ucsf.edu> wrote:
> Thanks, we made a fix as well.
>
> I also noticed something else where I could use some verification, and this
> one had big implications for us:
>
> It seems that .NET will mark any CacheDependency object as HasChanged=TRUE
> whenever a matching key is added or removed from the cache.
> So... on line 50 of Cache.cs we call a method to create a CacheDependency
> On 5/7/13, Meeks, Eric <eric....@ucsf.edu<mailto:eric....@ucsf.edu>>
>> profilesrns...@googlegroups.com<mailto:profilesrns%2Bunsu...@googlegroups.com>.
>> To post to this group, send email to
>> profi...@googlegroups.com<mailto:profi...@googlegroups.com>.
>> Visit this group at http://groups.google.com/group/profilesrns?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ProfilesRNS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
> profilesrns...@googlegroups.com<mailto:profilesrns%2Bunsu...@googlegroups.com>.
> To post to this group, send email to
> profi...@googlegroups.com<mailto:profi...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/profilesrns?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ProfilesRNS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
> profilesrns...@googlegroups.com<mailto:profilesrns...@googlegroups.com>.
> To post to this group, send email to
> profi...@googlegroups.com<mailto:profi...@googlegroups.com>.

Meeks, Eric

unread,
May 8, 2013, 12:55:48 PM5/8/13
to profi...@googlegroups.com
I just created a new method in Cache.cs and called it when appropriate:

static public void SetNoDependency(string key, Object data, int timeout)
{
Set(key, data, timeout, 0);
}

I also noticed that the static timeout was being redundantly set all the time and could even be set to false values in the 4 arg Set call, so I changed that. I'll include the Cache.cs we ended up with in this email.
Eric
Cache.cs

James Norman

unread,
May 8, 2013, 1:02:32 PM5/8/13
to profi...@googlegroups.com
I was thinking along the same lines. The issue with the random
timeout values started out as one thing then never turned into what
should have been a better solution. We needed some way to have long
term cache storage for drop down values that are populated from the
DB.
Reply all
Reply to author
Forward
0 new messages