cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imran Pariyani <>
Subject Re: multithreaded Content Aggregator migration from 2.1 to 2.2
Date Thu, 05 Jun 2008 13:21:15 GMT

we have come across this issue .. i posted it on user mailing list and 
some one from there suggested me to post it here since it seems to be 
bug in cocoon 2.2 .. its a very crucial issue for us.. we cant upgrade 
to 2.2  unless we  some how solve or find a work around for this issue ..

we have multithreaded Content Aggregator which is based on the 
CIncludeTransformer and it also implements CacheableProcessingComponent 
for caching .. it used to work fine for cocoon 2.1.x but with cocoon 2.2 
it gives strange error .. it is actually a generator and it gives error 
in the generate method ..

the code where it gives error

// generate...
           for (Part part : {
               if (this.manager.hasService(IncludeCacheManager.ROLE)) {
                   part.uri = this.cacheManager.load(part.uri, 
               } else {
                           "The ContentAggregator: aggregator cannot 
find the IncludeCacheManager");

           // aggregate...
           StreamPipe streamPipe = new StreamPipe(this.contentHandler);
           for (Part part : {
               streamPipe.firstElement(part.element, this.rootElement, 
               try {
                   System.out.println("ParallelContentAgg.part.uri:" + 
this.cachingSession, streamPipe);
               } finally {

it gives the following error

Caused by: org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 
'': Scope 
'request' is not active for the current thread; consider defining a 
scoped proxy for this bean if you intend to refer to it from a 
singleton; nested exception is java.lang.IllegalStateException: No 
thread-bound request found: Are you referring to request attributes 
outside of an actual web request? If you are actually operating within a 
web request and still receive this message,your code is probably running 
outside of DispatcherServlet/DispatcherPortlet: In this case, use 
RequestContextListener or RequestContextFilter to expose the current 




       at $Proxy2.cleanupLocalContext(Unknown Source)





EDU.oswego.cs.dl.util.concurrent.PooledExecutor$ Source)
       ... 1 more

Grzegorz Kossakowski wrote:
> Imran Pariyani pisze:
>> Hi
> Hi Imran,
>> last night i wasted 5 hrs overs this without any success .. i guess 
>> it has something to do with passing the RequestContextListener to the 
>> spring context .. i have initialized the listener in my web.xml and 
>> also added the config in applicationcontext.xml .. i checked 
>> everything on my end .. everything seems to be fine .. is something 
>> wrong with the cachemanager present in cocoon ?
>> any help will be greatly appreciated !! ..
> Unfortunately, it looks like you stumbled across rather complicated 
> (and obscure) bug. It's related to the fact how Spring's request scope 
> works (objects are tied to the thread). If you run multithreaded 
> aggregation then child threads don't have an access to beans defined 
> with 'request' scope because they are visible only in parent thread.
> More details below...
> <snip/>
>>> org.apache.cocoon.components.source.impl.SitemapSource.toSAX(

> The failing code is:
>             if (touchedOM) {
>                 //Because of complicated flow of this source it must 
> maintain the cleaness of OM on its own
>                 ObjectModel newObjectModel;
>                 try {
>                     newObjectModel = 
> (ObjectModel)manager.lookup(ObjectModel.ROLE);
>                 } catch (ServiceException e) {
>                     throw new SAXException("Couldn't look up Object 
> Model", e);
>                 }
>                 newObjectModel.cleanupLocalContext();
>                 touchedOM = false;
>             }
> Here, manager.lookup fails because ObjectModel is a bean with request 
> scope.
> To be honest, I don't have an idea how this should be fixed. I guess 
> it's a bug of CocoonRunnable class but I don't know how to give child 
> threads access to parent thread variables in a safe way.
> This would require more investigation that I have no time for at the 
> moment, unfortunately.
> I hope it helped you a little to understand the problem. Maybe you 
> will find someone on dev@ mailing list that has an idea how to fix it.

View raw message