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 Tue, 26 Aug 2008 00:23:44 GMT

On Aug 25, 2008, at 6:40 AM, Thorsten Scherler wrote:

> On Fri, 2008-08-22 at 10:34 -0400, Vadim Gritsenko wrote:
>> On Aug 22, 2008, at 8:57 AM, Thorsten Scherler wrote:
>>
>>> So which object you would suggest to lock?
>>>
>>> You wrote "Suitable  alternative would be to lock against top most
>>> command line request."
>>>
>>> To what you are referring with "top most command line request"?
>>
>> That would be CommandLineRequest.
>
> Hmm, did you see the above objectModel? There is no such an object in
> the map. There are exactly six objects in the model
>
> 1) response
> 2) link-collection
> 3) request
> 4) context
> 5) source-resolver
> 6) org.apache.cocoon.components.CocoonComponentManager

Yes, it currently does not exist.


>> Following HTTP environment analogy,
>> that would be CommandLineEnvironment.CLI_REQUEST_OBJECT.
>
> Which does not exist, right?

Correct. At the moment, it does not exist.


> I opened an issue COCOON-2241 around the issue.
>
> The proposed solution is now taken the  
> ObjectModelHelper.REQUEST_OBJECT
> if the request is from CLI, if not it is using the
> HttpEnvironment.HTTP_REQUEST_OBJECT.
>
> IMO it should not be a problem with deadlocks since the
> FileSavingEnvironment and LinkSamplingEnvironment (as only
> implementations for the Cli) have in the constructor:
>
> this.objectModel.put(ObjectModelHelper.REQUEST_OBJECT,
> new CommandLineRequest(this, null, uri, null, attributes, parameters,
> headers));
>
> which IMO makes it unique for each sub-request.

Yes, ObjectModelHelper.REQUEST_OBJECT object is always unique. It is  
actually unique in any environment. And since it is unique, it does  
not make sense to lock on it at all - lock on unique object serves no  
purpose :-)

You could, for example, have same effect with code:

     // Avoids NPE, does nothing
     if (lock == null) lock = new Object();


To get back to the problem... The original goal of pipeline locking  
was to prevent separate external requests to start generating cached  
response for the same resource-intensive resource. In other words, if  
too external requests both (directly or through aggregation) hit '/ 
slow/cached/foo' resource, only one request will trigger this  
pipeline, while another will wait for the first to complete.

This logic, in turn, had to be augmented to exclude single external  
request hitting the same slow resource twice due to aggregation (and  
parallel aggregation), hence locking against top level external  
request was implemented.

Now, in situation when CommandLineEnvironment is used from the, ahem,  
command line, two external requests will not happen. Which means that  
whole pipeline locking thing is irrelevant and can be omitted  
completely (like in 'lock = new Object()' snippet above). But, the  
same CommandLineEnvironment stuff can be used in multi threaded  
environment which uses the CocoonBean class. So, strictly speaking, in  
this scenario locking still should be performed against external  
request object, and not against any RequestWrapper which is unique for  
each sub-request.

Hope now it all makes more sense.

Regards,
Vadim


> In comparison the HttpEnvironment has in the constructor:
> this.objectModel.put(HTTP_REQUEST_OBJECT, req);
> where HttpServletRequest req.
>
> The uniqueness in both cases are, as I understand, the headers.
>
> salu2


Mime
View raw message