[ http://issues.apache.org/jira/browse/COCOON-1799?page=comments#action_12439432 ] Jean-Baptiste Quenot commented on COCOON-1799: ----------------------------------------------
Done in trunk as well: Committed revision 452380. > [PATCH] Threads waste when reading a not found resource. > -------------------------------------------------------- > > Key: COCOON-1799 > URL: http://issues.apache.org/jira/browse/COCOON-1799 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core > Affects Versions: 2.1.9 > Reporter: Simone Gianni > Assigned To: Antonio Gallardo > Priority: Blocker > Fix For: 2.1.9 > > 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
