cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: [2.1] AbstractCachingProcessingPipeline and cocoon CLI
Date Thu, 21 Aug 2008 23:40:06 GMT
On Aug 21, 2008, at 8:18 AM, Thorsten Scherler wrote:

> still updating forrest to use cocoon-2.1.x and I found a problem in  
> the
> AbstractCachingProcessingPipeline.
>
> I am not sure whether someone is using the cocoon cli ATM. Forrest is
> based around this component.
>
> https://issues.apache.org/jira/browse/FOR-955?focusedCommentId=12624340 
> #action_12624340
>
> I found that in
> org 
> .apache 
> .cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline  
> line 245
> Object lock =
> env.getObjectModel().get(HttpEnvironment.HTTP_REQUEST_OBJECT);
> the lock is null which causes the NPE in the end.
>
> I changed it the following way:
>                     Object lock =
> env.getObjectModel().get(HttpEnvironment.HTTP_REQUEST_OBJECT);
> +                    if (null==lock){
> +                      lock =
> env.getObjectModel().get(ObjectModelHelper.REQUEST_OBJECT);
> +                    }
>                     try {
>
> and now it is working as before.
>
> Can somebody verify that it is a bug? Should I commit the patch?

It is a bug, but with proposed change you can get a deadlock under  
some conditions (IIRC, when using parallels inclusion in the sitemap  
which ultimately pull from the same pipeline). The idea behind that  
lock is to synchronize on the main request (top most request), and not  
on any of sub-request object created during aggregation. Suitable  
alternative would be to lock against top most command line request.

Vadim

Mime
View raw message