[pLog-svn] r5964 - plog/branches/lifetype-1.2/class/dao
Jon Daley
plogworld at jon.limedaley.com
Tue Dec 18 23:01:42 EST 2007
Hrm, these URLs look suspicious to anyone?
crawl-66-249-72-180.googlebot.com - - "GET /archives/2091/03/
crawl-66-249-72-180.googlebot.com - - "GET /archives/1922/06/
It'd be nice to make the calendar so it wouldn't generate next and
previous links - google wastes all its time searching through a million
links.
These accesses happened directly before the crash, so it is a very
similar sort of problem as before. I am actually surprised that it is
still there, ie. that my fixes the other day didn't get it. But, we'll
see.
On Tue, 18 Dec 2007, Jon Daley wrote:
> It is definitely much better than it was. I thought it was
> completely fixed, but I see one of my installations is still broken. I'll
> have to poke around and find out where it is. It will probably be a
> similar sort of bug - it is really easy to mess up the cache with those
> get() and getMany() calls if the inputs aren't completely sanitized.
>
> On Tue, 18 Dec 2007, Oscar Renalias wrote:
>> So do you really think that it is finally fixed? I noticed at least
>> one check-in reverting a previous one... :) Did that have anything to
>> do with this?
>>
>> Oscar
>>
>> On Dec 17, 2007, at 9:02 PM, Jon Daley wrote:
>>
>>> woohoo! I found it. The trouble is the "new" functions for
>>> setting things based on article title. We weren't checking if the
>>> title
>>> actually existed or not, prior to setting the cache object (and other
>>> things, but less critical).
>>> I am looking over the changes now - it would be great if other
>>> folks, particularly those who are using custom URLs, but anyone for a
>>> sanity check to make sure that the checked in code is better than
>>> what you
>>> have, where "better" is defined as:
>>>
>>> 1. Doesn't crash
>>> 2. Lighter CPU load
>>> 3. Doesn't have random problems
>>>
>>>
>>> Areas that are interesting to look at:
>>> Referrer counting, particularly with custom URLs,
>>> and the preference that updates even when caching is turned on
>>> Updating the "read" count in the same above situation
>>> Searches: I originally thought the bug had to do with searches,
>>> and while I am pretty sure that isn't the case, it would be
>>> good to run a bunch of searches, and then view individual
>>> articles, and make sure everything still views properly.
>>>
>>>
>>>
>>>
>>> On Sat, 15 Dec 2007, Jon Daley wrote:
>>>
>>>> I have a handful of installations that are running my latest
>>>> filter order change. It has been working excellently (ie. all
>>>> spams have
>>>> been caught by badbehavior (and/or hiddeninput) and thrown away, so
>>>> the comments are not being saved to the database), BUT...
>>>>
>>>> I think the below bug is more visible now, probably because since
>>>> there are less comments, the cache doesn't get cleaned as often,
>>>> and so
>>>> the bad cache values are sticking around for folks to see.
>>>> The good news is that assuming I/we can find the cache bug, the
>>>> cpu load going forward will be much less, since I can see the cache
>>>> not
>>>> being reset so often.
>>>> The bad news is that I have looked for this bug before, and have
>>>> not been able to find it as of yet. I'll probably need to write a
>>>> cache
>>>> test that runs through the various actions and see which one is
>>>> putting
>>>> corrupt data in the cache.
>>>>
>>>> On Fri, 5 Oct 2007, Jon Daley wrote:
>>>>
>>>>> I am happy with this change for now. More work needs to be done
>>>>> to see why this happened in the first place, but this fix fixes the
>>>>> problem, and shouldn't cause any downsides. I guess the only
>>>>> thing is
>>>>> that there might be a related bug somewhere, but I haven't seen it.
>>>>>
>>>>> On Sat, 6 Oct 2007, Oscar Renalias wrote:
>>>>>> Well, I don't mind delaying 1.2.5 for a few more days to see if
>>>>>> this
>>>>>> really makes any (positive) difference... Just keep us updated.
>>>>>>
>>>>>> Oscar
>>>>>>
>>>>>> On 4 Oct 2007, at 05:24, Jon Daley wrote:
>>>>>>
>>>>>>> Yeah, I agree. I don't see how my fix can break anything else,
>>>>>>> since it just postpones the article getting into the cache for
>>>>>>> some
>>>>>>> other
>>>>>>> operation, but I don't really know why it fixes it either.
>>>>>>> I made this change probably last Saturday or so on the two sites
>>>>>>> that were having this issue, and they have been fine since then.
>>>>>>> Where,
>>>>>>> usually, they would have gotten a messed up cache file in one or
>>>>>>> two days.
>>>>>>>
>>>>>>> On Wed, 3 Oct 2007, Oscar Renalias wrote:
>>>>>>>> I'm not so sure... There's nothing wrong with the fix, it's
>>>>>>>> just that
>>>>>>>> I don't understand it :)
>>>>>>>>
>>>>>>>> On 10/3/07, jondaley at devel.lifetype.net
>>>>>>>> <jondaley at devel.lifetype.net> wrote:
>>>>>>>>> Author: jondaley
>>>>>>>>> Date: 2007-10-03 14:15:27 -0400 (Wed, 03 Oct 2007)
>>>>>>>>> New Revision: 5964
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>> plog/branches/lifetype-1.2/class/dao/articles.class.php
>>>>>>>>> Log:
>>>>>>>>> This fixes the corrupt cache problem.
>>>>>>>>>
>>>>>>>>> I don't think this is the real fix, as I think this code was
>>>>>>>>> probably okay,
>>>>>>>>> but I couldn't figure out where $article was being set to an
>>>>>>>>> array()
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Modified: plog/branches/lifetype-1.2/class/dao/
>>>>>>>>> articles.class.php
>>>>>>>>> =
>>>>>>>>> =
>>>>>>>>> =
>>>>>>>>> ================================================================
>>>>>>>>> --- plog/branches/lifetype-1.2/class/dao/articles.class.php
>>>>>>>>> 2007-10-02 18:55:05 UTC (rev 5963)
>>>>>>>>> +++ plog/branches/lifetype-1.2/class/dao/articles.class.php
>>>>>>>>> 2007-10-03 18:15:27 UTC (rev 5964)
>>>>>>>>> @@ -991,7 +991,8 @@
>>>>>>>>> RecentArticles::resetRecentArticlesCache
>>>>>>>>> ( $article->getBlogId());
>>>>>>>>> $this->_cache->removeData( $article->getBlogId(),
>>>>>>>>> CACHE_ARTICLESPERMONTH );
>>>>>>>>> $this->_cache->removeData( $article-
>>>>>>>>>> getId
>>>>>>>>> (), CACHE_ARTICLETEXT );
>>>>>>>>> - $this->_cache->setData( $article->getId(),
>>>>>>>>> CACHE_ARTICLES, $article );
>>>>>>>>> + $this->_cache->removeData( $article->getId(),
>>>>>>>>> CACHE_ARTICLES );
>>>>>>>>> +// $this->_cache->setData( $article->getId(),
>>>>>>>>> CACHE_ARTICLES, $article );
>>>>>>>>> $this->_cache->removeData( $article-
>>>>>>>>>> getPostSlug(), CACHE_ARTICLES_BYNAME );
>>>>>>>>>
>>>>>>>>> return true;
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> pLog-svn mailing list
>>>>>>>>> pLog-svn at devel.lifetype.net
>>>>>>>>> http://limedaley.com/mailman/listinfo/plog-svn
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> pLog-svn mailing list
>>>>>>>> pLog-svn at devel.lifetype.net
>>>>>>>> http://limedaley.com/mailman/listinfo/plog-svn
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jon Daley
>>>>>>> http://jon.limedaley.com/
>>>>>>>
>>>>>>> Never mess up an apology with an excuse.
>>>>>>> _______________________________________________
>>>>>>> pLog-svn mailing list
>>>>>>> pLog-svn at devel.lifetype.net
>>>>>>> http://limedaley.com/mailman/listinfo/plog-svn
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> pLog-svn mailing list
>>>>>> pLog-svn at devel.lifetype.net
>>>>>> http://limedaley.com/mailman/listinfo/plog-svn
>>>>>>
>>>>>
>>>>> --
>>>>> Jon Daley
>>>>> http://jon.limedaley.com/
>>>>>
>>>>> The sooner you fall behind, the more time you'll have to catch up.
>>>>> _______________________________________________
>>>>> pLog-svn mailing list
>>>>> pLog-svn at devel.lifetype.net
>>>>> http://limedaley.com/mailman/listinfo/plog-svn
>>>>>
>>>>
>>>> --
>>>> Jon Daley
>>>> http://jon.limedaley.com/
>>>>
>>>> If you perceive that there are four possible ways in which
>>>> a procedure can go wrong and circumvent these, then a fifth way,
>>>> unprepared for, will promptly develop.
>>>> -- Murphy's Sixth Law
>>>> _______________________________________________
>>>> pLog-svn mailing list
>>>> pLog-svn at devel.lifetype.net
>>>> http://limedaley.com/mailman/listinfo/plog-svn
>>>>
>>>
>>> --
>>> Jon Daley
>>> http://jon.limedaley.com/
>>>
>>> I haven't lost my mind; I have a tape backup somewhere.
>>> _______________________________________________
>>> pLog-svn mailing list
>>> pLog-svn at devel.lifetype.net
>>> http://limedaley.com/mailman/listinfo/plog-svn
>>
>> _______________________________________________
>> pLog-svn mailing list
>> pLog-svn at devel.lifetype.net
>> http://limedaley.com/mailman/listinfo/plog-svn
>>
>
> --
> Jon Daley
> http://jon.limedaley.com/
>
> Whining is anger through a small opening.
> -- Stuart Smalley
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn
>
--
Jon Daley
http://jon.limedaley.com/
What is originality? Undetected plagiarism.
-- Dean William R. Inge
More information about the pLog-svn
mailing list