You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Simone Gianni (JIRA)" <ji...@apache.org> on 2006/03/10 01:10:39 UTC
[jira] Created: (COCOON-1799) [PATCH] Threads waste when reading a
not found resource.
[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
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) {
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
Re: [jira] Reopened: (COCOON-1799) [PATCH] Threads waste when reading
a not found resource.
Posted by Joerg Heinicke <jo...@gmx.de>.
On 11.03.2006 00:20, Antonio Gallardo wrote:
>> I'm reopening this issue just for trunk:
>> AbstractCachingProcessingPipeline locking feature *must* be ported to
>> trunk, and this bugfix as well.
>
> IMHO given the current code base, the bug has already been fixed
> everywhere. The bug was introduced with the newly "locking feature".
> Note the bug was only for 2.1.x-dev and since the code has not been
> merged in 2.2 yet, actually it does not apply for 2.2. When the trunk
> will be synchronized, this bug will be automatically fixed there too,
> hence the bug has never been nor will appear in 2.2.
> wdyt?
+1 I agree. There is another "to be synced" document somewhere.
Jörg
Re: [jira] Reopened: (COCOON-1799) [PATCH] Threads waste when reading
a not found resource.
Posted by Antonio Gallardo <ag...@agssa.net>.
Jean-Baptiste Quenot (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/COCOON-1799?page=all ]
>
>Jean-Baptiste Quenot reopened COCOON-1799:
>------------------------------------------
>
>
>I'm reopening this issue just for trunk: AbstractCachingProcessingPipeline locking feature *must* be ported to trunk, and this bugfix as well.
>
>
IMHO given the current code base, the bug has already been fixed
everywhere. The bug was introduced with the newly "locking feature".
Note the bug was only for 2.1.x-dev and since the code has not been
merged in 2.2 yet, actually it does not apply for 2.2. When the trunk
will be synchronized, this bug will be automatically fixed there too,
hence the bug has never been nor will appear in 2.2.
On the other side, if what we wanted to point out was a reminder that
the code needs to be marge for this class in 2.2, I think this bug
report is the worse place to put this kind of reminder. If a reminder is
necesary, then please open a new bug with the correct description:
"Merge 'AbstractCachingProcessingPipeline.java' code from 2.1 in 2.2" or
something like that.
BTW, We committers should merge our changes in branch to trunk to keep
both synchronized. I know this is a boring task, but an important one.
wdyt?
Best Regards,
Antonio Gallardo.
>
>
>>[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!!
>>
>>
>
>
>
[jira] Reopened: (COCOON-1799) [PATCH] Threads waste when reading a
not found resource.
Posted by "Jean-Baptiste Quenot (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/COCOON-1799?page=all ]
Jean-Baptiste Quenot reopened COCOON-1799:
------------------------------------------
I'm reopening this issue just for trunk: AbstractCachingProcessingPipeline locking feature *must* be ported to trunk, and this bugfix as well.
> [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
[jira] Assigned: (COCOON-1799) [PATCH] Threads waste when reading a
not found resource.
Posted by "Antonio Gallardo (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/COCOON-1799?page=all ]
Antonio Gallardo reassigned COCOON-1799:
----------------------------------------
Assign To: Antonio Gallardo
> [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
> 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
[jira] Geschlossen: (COCOON-1799) [PATCH] Threads waste when
reading a not found resource.
Posted by "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
[jira] Closed: (COCOON-1799) [PATCH] Threads waste when reading a
not found resource.
Posted by "Antonio Gallardo (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/COCOON-1799?page=all ]
Antonio Gallardo closed COCOON-1799:
------------------------------------
Fix Version: 2.1.9-dev (current SVN)
Resolution: Fixed
Thanks for the patch!
It was applied in 2.1.9-dev. The code in 2.2 for AbstractCachingProcessingPipeline.java is different and seems the patch is not needed there.
> [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
[jira] Commented: (COCOON-1799) [PATCH] Threads waste when reading
a not found resource.
Posted by "Jean-Baptiste Quenot (JIRA)" <ji...@apache.org>.
[ 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