From dev-return-84161-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Thu Jan 26 06:40:36 2006 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 2407 invoked from network); 26 Jan 2006 06:40:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 26 Jan 2006 06:40:35 -0000 Received: (qmail 78626 invoked by uid 500); 26 Jan 2006 06:40:32 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 78556 invoked by uid 500); 26 Jan 2006 06:40:31 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 78545 invoked by uid 99); 26 Jan 2006 06:40:31 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Jan 2006 22:40:31 -0800 Received: from ajax.apache.org (ajax.apache.org [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id 20F85CB for ; Thu, 26 Jan 2006 07:40:10 +0100 (CET) Message-ID: <642473996.1138257610133.JavaMail.jira@ajax.apache.org> Date: Thu, 26 Jan 2006 07:40:10 +0100 (CET) From: "Antonio Fiol (JIRA)" To: dev@cocoon.apache.org Subject: [jira] Commented: (COCOON-1681) Generator "directory": Caching too much In-Reply-To: <713003975.1131368240215.JavaMail.jira@ajax.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/COCOON-1681?page=comments#action_12364063 ] Antonio Fiol commented on COCOON-1681: -------------------------------------- No, I am not disabling the expiry check. This was a temporary workaround. The code in isValid says something like: if not yet expired (current time < expiry time) return VALID expiry time = current time <---- OFFENDING LINE check filesystem and return INVALID if it really is INVALID (as it is not invalid, and FS was already checked) expiry time = current time return VALID What happens is that if it is called twice on an expired directory, the first time will return INVALID, but will (incorrectly) update the expiry time. So the second call will incorrectly return VALID, because it is not expired. I agree that a single call to isValid() would be much better, but isValid should anyway be implemented in a secure (consistent) manner. With our patch, if the cached version is invalid, the FS is checked twice instead of the ideal "once". But if it is not expired, no FS check is done, so it's quite different from disabling the expiry checks. In any case, I liked your suggestion, and will try to provide the two stack frames, and I will also post the patch today (we finished testing yesterday, and it works like a charm). > Generator "directory": Caching too much > --------------------------------------- > > Key: COCOON-1681 > URL: http://issues.apache.org/jira/browse/COCOON-1681 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.8, 2.1.7 > Reporter: Antonio Fiol > Assignee: Jean-Baptiste Quenot > > In some cases, an update to the directory is not detected by the DirectoryGenerator. > Debugging the issue, I discovered that isValid() is called twice on the same DirValidity, but it returns different values (-1 the first time, 1 the second time). > Apparently, the reason for the inconsistency would be solved by removing the first of the two lines that update the expiry time in the isValid() method in DirValidity, but I am not sure whether this could cause problems in other places. > A possibility would be that a DirValidity stores the fact that it already detected it is invalid, and is changed so that it always return -1. But... Are DirValidity objects reused? Could this change cause problems? I have not tested, so I don't know. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira