[jira] Geschlossen: (COCOON-1799) [PATCH] Threads waste when reading a not found resource.

["Jörg Heinicke (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/COCOON-1799?page=all ]
     
Jörg 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 time a 404 is reported, but following requests will hang up and the thread will 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 twice
> - 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 :
>             		if (pcKey != null) {
>             			releaseLock(pcKey);
>             		}
> 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 other 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. 
> I modified this class so that it :
> - Does not set pckey to null when readerValidity == null
> - Checks for pckey != null && readerValidity != null on line 907 so that content is not cached if readerValidity == null
> - Since pckey is != null the lock is released.
> I tested it and seems to work correctly, but this is core stuff, please double check it!!

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