Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <476308463.1142079726509.JavaMail.jira@ajax>
Date: Sat, 11 Mar 2006 12:22:06 +0000 (GMT)
From: =?UTF-8?Q?J=C3=B6rg_Heinicke_=28JIRA=29?= <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Geschlossen: (COCOON-1799) [PATCH] Threads waste when
 reading a not found resource.
In-Reply-To: <133219057.1141949439445.JavaMail.jira@ajax>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

     [ http://issues.apache.org/jira/browse/COCOON-1799?page=3Dall ]
    =20
J=C3=B6rg Heinicke closed COCOON-1799:
---------------------------------

    Resolution: Fixed

added comment to TO-SYNC-FROM-BRANCH.TXT

> [PATCH] Threads waste when reading a not found resource.
> --------------------------------------------------------
>
>          Key: COCOON-1799
>          URL: http://issues.apache.org/jira/browse/COCOON-1799
>      Project: Cocoon
>         Type: Bug
>   Components: * Cocoon Core
>     Versions: 2.1.9-dev (current SVN)
>     Reporter: Simone Gianni
>     Assignee: Antonio Gallardo
>     Priority: Blocker
>      Fix For: 2.1.9-dev (current SVN)
>  Attachments: pipeline.diff
>
> When setting up a pipeline with a reader on a not found file, the first t=
ime a 404 is reported, but following requests will hang up and the thread w=
ill never get released, causing a potential complete lock exausting threads=
.
> In the AbstractCachingProcessingPipeline class, in ProcessReader method, =
the following happens :
> - 774: a pcKey is created for caching content
> - 853: the method eventually waits if another thread is generating
> - 869: the method acquires a lock, to avoid other threads to generate twi=
ce
> - 886: if there is no need cache validity pcKey is setted to null
> - 918: if an exception occurrs while generating, the following code is in=
 a finally :
>             =09=09if (pcKey !=3D null) {
>             =09=09=09releaseLock(pcKey);
>             =09=09}
> This obviously brings to the following situation :
> - A non existing resource is being generated
> - A lock is acquired
> - The FileSource returns null if the file does not exist.
> - So pcKey is setted to null.
> - An exception is thrown, since the file is not found.
> - The finally block does not release the lock
> - Next requests on the same file will hang waiting on the lock, but the o=
ther thread will never release it.
> This can easily consume all threads, it's quite easy to have this kind of=
 errors on a missing gif, or css, or favicon.ico or something else.=20
> I modified this class so that it :
> - Does not set pckey to null when readerValidity =3D=3D null
> - Checks for pckey !=3D null && readerValidity !=3D null on line 907 so t=
hat content is not cached if readerValidity =3D=3D null
> - Since pckey is !=3D null the lock is released.
> I tested it and seems to work correctly, but this is core stuff, please d=
ouble check it!!

--=20
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