cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imran Pariyani <ipariy...@triplemind.com>
Subject Re: multithreaded Content Aggregator migration from 2.1 to 2.2
Date Thu, 05 Jun 2008 13:13:47 GMT
hello Grzegorz,

Thanks for the reply .. and for the clue .. i guess i was looking in the 
wrong direction ... i will try and look into the source and also post 
the same to dev at cocoon .. if u find anything else on this issue 
please do let me know .. we cant upgrade till we solve this issue .. its 
quite crucial ..


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(SitemapSource.java:382)

>>
>
> 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.
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message