cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Gianni (JIRA)" <>
Subject [jira] Created: (COCOON-1799) [PATCH] Threads waste when reading a not found resource.
Date Fri, 10 Mar 2006 00:10:39 GMT
[PATCH] Threads waste when reading a not found resource.

         Key: COCOON-1799
     Project: Cocoon
        Type: Bug
  Components: * Cocoon Core  
    Versions: 2.1.9-dev (current SVN)    
    Reporter: Simone Gianni
    Priority: Blocker
 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) {

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:
For more information on JIRA, see:

View raw message